Generate into subdirectory ..

Hi Dan,

you can use another root mapping rule and then set the virtualPackage of the output node to a subpackage. That should work.
You can change the virtualPackage in the code of a macro, i guess.
But i'm not really sure how to access the output-node.

Hi Michael,

do you suggest a virtual folder? I tried that - but that doesnt work ...

Dan

Unfortunately, there's no way currently to create generated files in a package other than the one corresponding to the source model's name. We're planning to have an ability to copy generated files to an arbitrary location as a part of the make process (most probably with Ant's copy task). Another possibility would be to create another _model_ from your source model (m2m style), but that isn't supported either.

Sorry Dan,

I was wrong. virtualPackages aren't respected when as "java-packages" when generating...
How could I forget that... ( http://youtrack.jetbrains.net/issue/MPS-5962?projectKey=MPS )

This is all really stupid. I hope it will be improved soon...

It doesn't look like any progress has been made on this essential feature, but I really need this, so I wanted to check on how I might best implement this.  My initial goal is to be able to integrate MPS generated code into a larger existing project structure (Maven based).  Long term goal would be to manage the whole project structure through a language in MPS, and let it generate the Maven POMs, Guice modules, OSGi manifests, etc.

Forgetting Maven for the moment, the first thing I would like to do is extend BaseLanguage and add concepts for Modules and Packages.  A module would contain 0..n packages, and a package would contain 0..n classes, interfaces, etc.  To keep it simple at first, let's also forget about Modules and assume each solution model = a module, so the rootable concept would be Package.

Now, I can see 3 ways to potentially handle this, and would like to get feedback on which are possible now and/or the safest approach for easy migration to 3.0 and beyond.  Also, I'm not sure how if at all these approaches would affect IntelliJ integration, so comments on that would be appreciated as well.

1. It looks like I have access to the generation output directory from a make facet, so one approach would be to modify that to the appropriate directory during generation.  Ideally I would just hook in before textgen, but I think I remember seeing that the package structure is hardcoded in the textgen component, so I might have to override that whole facet and/or the baseLanguage textgen.  That's a little messy, but might be the "cleanest" solution going forward, not sure.

2. Have a make facet run AFTER textgen, and basically move everything around post-generation.  In the Maven case, I could even go ahead and run the Maven compiler at that point, similar to how they run MAKE post-generation in the mbeddr project.  This would probably be a much easier implementation than #1, but I'm wondering if MPS will get confused (and in particular the IntelliJ plugin) if I start moving around its generated files?

3. Similar to #2, but have the post-textgen make facet COPY the generated code to another location in the proper structure.  Probably the safest approach, and likely my starting point unless I get some new insights regarding the above approaches.  For integrating with an existing project, this would probably be a good approach and then could be refactored as MPS's capabilities improve in this area.

BTW, I am willing to share this work, and will put it up on Github as soon as I get some feedback on the approaches listed above.  Any collaborations or other feedback would be welcome.  I am also in the process of setting up a blog on DSL development with a focus on MPS (maybe with some Xtext sprinkled in), so this might be a good topic for some blog posts as well.

You're right, this is a long standing issue without progress. I've also experimented with similar approaches to yours without really success. Currently I'm using this workaround:

• generate all artifacts in the same directory
  
• use a hand-crafted ant build file to select the right files for the jars and wars

At least is it possible to completely generate a JEE webapp with JSF, EJB, CDI, and JPA.

Best regards,
Jens

This is very frustrating.  I don't see any reason why the package should be hardcoded to the model name.  Especially since cross-model references don't work (in the generator).

There are many use cases where this limitation has an impact.  Consider something as simple as separating interfaces from implementation, e.g. from some entity model, you want to generate an interface to com.some.package and the implementation to com.some.package.impl.  I can't even think of how to do that using 2 models, come to think of it, whereas it would be so simple if I could just set the output package in the generator on a per-class basis.

Another use case would be to support Maven projects.  I can get around this somewhat by setting the output directory to src/main/java, but then if I want to generate my tests I need a completely separate module, not even just a new model, since the output directory is set on the module level.  I would love to be able to create another model that manages a multi-module project in Maven, generates the poms for me, etc., but that's just right out.  Oh, and I thought I might have better luck by using the plugin in IntelliJ with a Maven module, but that didn't work at all for me.

I guess I'll have to go the Ant route too.  I thought about trying to extend the build dsl so that maybe I could generate my build models along with the rest of my code, and then let the build language generate my ant script.  But the documentation is pretty sparse and I really haven't had time to look into it too much.

Hi,

I am facing the same problem.

Would be nice to have indeed.

Thanks.

I guess I'll have to go the Ant route too. I thought about trying to extend the build dsl so that maybe I could generate my build models along with the rest of my code, and then let the build language generate my ant script. But the documentation is pretty sparse and I really haven't had time to look into it too much.

hello am quite late in the scene, but i did go extending the baseLang way to solve the issue:

though mine is quite a small DSL  , i extended TextGen and Make facet and also extended ClassConcept and hence it's TextGen node.It somehow worked for me without the anting it but.

But certainly the ant idea was my first approach and i succeeded in it first for i wanted to get the job done first.