[news.eclipse.technology.m2e] Re: multiple maven modules in one eclipse

[Igor Fedorenko <igor@xxxxxxxxxxxxxx>]

Thank you, Nick, for detailed description of your project layout. I 
think code generation is relatively common problem and we are looking to 
provide better support for this workflow. Unfortunately, given how 
drastically different code generation tools are I am not sure we will 
have perfect solution that will work for everyone from the first try ;-).

For modello (a code generation framework used by maven and nexus), for 
example, I plan to implement custom m2e project configuration that will 
take care of initial project classpath configuration and subsequent 
source code re/generation. Modello has been updated to use 
plexus-build-api couple of months ago, so we can provide really nice 
incremental build integration.

As far as I understand, AndroMDA UML model and generated 
classes/resources are located in different projects. This makes things 
little more complicated, but I still think it should be relatively 
straightforward to implement something similar for AndroMDA.

Hope this helps.

--
Regards,
Igor

Nick Sorokin wrote:
> Well, the elaboration may be a little bit lengthy. The use case is based 
> on the project structure generated by androMDA Maven plugins. The 
> example of the project structure is presented below (it is generated by 
> andromdapp-maven-plugin:generate see [1] for instructions)
>
>    /timetracker J2EE project
>         |    The root of the project contains a few files that control 
> the overall
>         |    build process and common properties (in the pom.xml).
>         |
>         |-- pom.xml
>         |        contains information about this project, you may add 
> more information
>         |        as long as you do not violate the Maven POM schema, see
>         |        http://maven.apache.org/reference/project-descriptor.htmlt
>         |
>         +-- /mda
>         |     |
>         |     |    The MDA module is the heart of this project, this is 
> where
>         |     |    AndroMDA is configured to generate the files needed to
>         |     |    assemble the application
>         |     |
>         |     +-- pom.xml
>         |     |        contains the AndroMDA dependencies and 
> configuration (cartridges, translation-libraries, etc)
>         |     +-- /src
>         |     |        additional sources such as merge-mappings can be
>         |     |        placed here, check out the /main/uml directory, 
> it contains
>         |     |        the UML model from which AndroMDA will generate code
>         |     +-- /src/main/config/andromda.xml
>         |              configures AndroMDA and its components, most
>         |              importantly the cartridges which are listed in
>         |              their own namespace; global settings are done in the
>         |              'default' namespace
>         |
>         +-- /common
>         |     |
>         |     |    The COMMON module collects those resources and classes
>         |     |    that are shared between the other modules.
>         |     |
>         |     +-- pom.xml
>         |     |        lists common dependencies
>         |     +-- /target
>         |              shared resources and java classes are generated 
> here,
>         |              such as value objects and exceptions
>         |
>         +-- /core
>         |     |
>         |     |    The CORE module collects those resources and classes
>         |     |    that use the Spring framework, optionally making
>         |     |    use of Hibernate and/or EJB under the hood.
>         |     |
>         |     +-- pom.xml
>         |     |        lists Spring dependencies
>         |     +-- /src/main/java
>         |     |        Spring classes that need manual implementation are
>         |     |        generated here, they will not be overwritten upon
>         |     |        regeneration; this includes the service, DAO and
>         |     |        entity implementations
>         |     +-- /target
>         |              the Spring resources and classes here will be
>         |              overwriten each time AndroMDA generates new code
>         |              using the Spring cartridge; this includes both
>         |              the Hibernate entities and the correponding
>         |              *.hbm.xml mapping files as well as the service
>         |              and DAO base classes. You'll also find the DDL
>         |              for creating and dropping your schema within this
>         |              directory.
>         |
>         +-- /web
>         |     |
>         |     |    The WEB module collects those resources and classes
>         |     |    that make up the presentation layer.
>         |     |
>         |     +-- pom.xml
>         |     |        lists WebApp dependencies
>         |     +-- /src/main/java
>         |     |        controller implementations and editable resource 
> bundles
>         |     |        will be generated here,
>         |     |        you might consider putting your own JSPs here to
>         |     |        be copied over the generated ones when bundling the
>         |     |        .war file
>         |     +-- /target
>         |              any Struts classes, JSPs, resource bundles and
>         |              configuration files are generated here
>         |
>         +-- /app
>               |
>               |    The APP module collects those resources and classes
>               |    that are required to actually build the .ear bundle
>               |
>               +-- pom.xml
>               |        lists dependencies to be bundles into the
>               |        root of the .ear
>               +-- /src
>               |        any custom resources that should be deployed
>               |        together with the application
>               |        (eg. server deployment descriptors)
>               +-- /target
>                        a deployable application is bundled here
>
> The generated project is a multi-module Maven project. I would like to 
> note again that there is no problems when maven is called from command 
> line. So, the rest will assume that Eclipse is used to perform 
> development including execution of the Maven builds.
>
> Let assume that this project is stored in source code repository without 
> generated code. There are two main roots: 1) checkout code outside of 
> Eclipse, run maven install and then import whole project or individual 
> modules as existing project and 2) preform all tasks within Eclipse. The 
> final result of initial steps should be the same for any root - 1) or 2).
>
> Goals associated with /mda module need to be executed only when UML 
> model is changed - that means that some /common/target and /core/target 
> source files are not changed by developer and can be left untouched by 
> clean operation requested for common and core module (if developer 
> selects to import as maven project and create separate Eclipse project 
> per module). If clean will delete these generated source files, then 
> andromdaapp:run needs to be executed again for every module that contain 
> generated sources. What I was suggesting is controlled by additional 
> property the modification of the  m2eclipse/maven:clean execution within 
> Eclipse. Probably, this can be achieved with additional profile but at 
> the moment of my previous message I didn't have suitable soultion that 
> didn't require modifications.
> During last couple of days I was looking into details how AndroMDA 
> projects are structured and how they can be processed within Eclipse in 
> the best possible way - your advises will be greatly appreciated.
>
> Regards,
> Nick
>
> [1] 
> http://galaxy.andromda.org/index.php?option=com_content&task=view&id=107&Itemid=89