Home » Archived » Maven Integration (M2E) » multiple maven modules in one eclipse project
| multiple maven modules in one eclipse project [message #26483] |
Thu, 14 May 2009 14:47  |
Eclipse User |
|
|
|
Originally posted by: igor.ifedorenko.com
It is currently possible to import multi-module maven project as single
Eclipse workspace project. As far as I can tell, such projects are only
good for casual source code browsing and have a number of limitations
that make them more or less useless for any real development. Here are
some of more serious limitations
* Lack of project configurators support. WAR modules will not be
configured as WTP Dynamic Webapp projects, for example.
* Single classpath for all modules.
* No (working) integration with Maven build.
* Probably the least tested m2e core feature
Also, based on questions and feedback we receive, many users find this
feature confusing and frustrating. And This is despite the fact the it
is hidden under Advanced section of import wizard and disabled by default.
All in all, this seems like one of those features that have significant
overhead in terms of development and support but provide very limited
benefits. I think we should remove support for importing multi-module
maven projects as single eclipse workspace project.
Is anyone using multi-module workspace projects at all? What are
usecases and development workflows for such projects?
--
Regards,
Igor
|
|
| | |
| Re: multiple maven modules in one eclipse project [message #26672 is a reply to message #26630] |
Tue, 19 May 2009 06:06  |
| Eclipse User |
|
|
|
Igor,
I didn't intend initially to list my (or company') problems because I've
thought that initial purpose of this discussion was to find out what is
going on in the world of Maven, Eclipse and m2eclipse.
Here is more detail information about one of the application that I need
to find a reasonable solution without disruption of the development
process.
The application in question has 17 top level projects in the Subversion
based repository. Currently two of them are multi-module (in sense of
Maven module)UML based that use AndroMDA to generate source code from the
model. All projects can become a projects in the Eclipse workspace and
currently I've tried to checkout them as multi-module Maven projects using
the available functionality of m2eclipse plugin. Projects then became
Maven-dependant.
The initial problem started when Maven (m2eclipse) starts buyilding
projects in the workspace: AndroMDA Maven2 plugin for its execution
requires JVM different from the JVM used by the application and made
default to the Eclipse. Another problem with AndroMDA lies in fact that it
generates the default implementors for the interfaces defind by the model
and places them as additional source for implementation module of the
project effectively into /target folder of Eclipse project (the location
is configurable but it was chosen to be located in the sibling module of
the MDA project - the decision can be argued but I can't change it by
now). AndroMDA generator is smart enough to underestand the case when
developer had replaced default generated implementor with its own - in
this case the default implementor is not included.
Second problem appeared later when developer begin to change the code:
m2eclipse perfroms its own build of the application and most of times
calls the AndroMDA plugin for the second time, again with requirement of
different JVM. Effectively, the project requires twice the time to build
and during build the developer has nothing to do but wait. I reckon that
this behaviour can be changed by not using functionality of the m2eclipse
plugin to resolve the Maven dependencies with the Eclipse workspace - I
think that was not the idea.
There are also minor problems with Web related projects - it took quite a
lot of time to make them runnable with Tomcat within Eclipse.
I had lengthy discussions with the Application architect about these
problems and possible ways to resolve them and he wrote: "I do not like
the idea that the Eclipse Maven plug-in is dictating the way our projects
are structured. I also explained that the core technologies (ergo Java,
J2EE, Spring, Maven, AndroMDA, Subversion etc) are what we are working to
and that workarounds (like running Maven tasks from the command line) are
acceptable." At the moment I do not have feasible solution(s) to all
these issues mentioned above. I'll have in a short time another project
that uses the similar structuring but currently is based on Maven1. There
will be the migartion to Maven2 and it may be possible to find and
validate the solution that can be implemented by other applications as
well.
Sorry, message appeared to be wordy and, probably not interested to the
community. If so, I'll still be interesting in finding solutions and will
be happy communicate out of the news portal.
Regards,
Nick
|
|
|
| Re: multiple maven modules in one eclipse project [message #26751 is a reply to message #26672] |
Wed, 20 May 2009 17:16 |
| Eclipse User |
|
|
|
Originally posted by: igor.ifedorenko.com
Nick,
First, thank you for taking the trouble to write about the problems you
have using m2e. This is very important feedback and we are taking it
seriously.
I will have to have a closer look at AndroMDA, but I believe the work
we're doing for 0.9.9 will enable solution for all/most of the problems
that you see. Would you be able to provide a small sample project that
we can use to test interaction between m2e and AndroMDA? You can either
submit it via m2e JIRA [1] or email me directly.
[1] https://issues.sonatype.org/browse/MNGECLIPSE
--
Regards,
Igor
Nick Sorokin wrote:
> Igor,
>
> I didn't intend initially to list my (or company') problems because I've
> thought that initial purpose of this discussion was to find out what is
> going on in the world of Maven, Eclipse and m2eclipse.
> Here is more detail information about one of the application that I need
> to find a reasonable solution without disruption of the development
> process.
>
> The application in question has 17 top level projects in the Subversion
> based repository. Currently two of them are multi-module (in sense of
> Maven module)UML based that use AndroMDA to generate source code from
> the model. All projects can become a projects in the Eclipse workspace
> and currently I've tried to checkout them as multi-module Maven projects
> using the available functionality of m2eclipse plugin. Projects then
> became Maven-dependant.
>
> The initial problem started when Maven (m2eclipse) starts buyilding
> projects in the workspace: AndroMDA Maven2 plugin for its execution
> requires JVM different from the JVM used by the application and made
> default to the Eclipse. Another problem with AndroMDA lies in fact that
> it generates the default implementors for the interfaces defind by the
> model and places them as additional source for implementation module of
> the project effectively into /target folder of Eclipse project (the
> location is configurable but it was chosen to be located in the sibling
> module of the MDA project - the decision can be argued but I can't
> change it by now). AndroMDA generator is smart enough to underestand the
> case when developer had replaced default generated implementor with its
> own - in this case the default implementor is not included.
>
> Second problem appeared later when developer begin to change the code:
> m2eclipse perfroms its own build of the application and most of times
> calls the AndroMDA plugin for the second time, again with requirement of
> different JVM. Effectively, the project requires twice the time to build
> and during build the developer has nothing to do but wait. I reckon that
> this behaviour can be changed by not using functionality of the
> m2eclipse plugin to resolve the Maven dependencies with the Eclipse
> workspace - I think that was not the idea.
>
> There are also minor problems with Web related projects - it took quite
> a lot of time to make them runnable with Tomcat within Eclipse.
>
> I had lengthy discussions with the Application architect about these
> problems and possible ways to resolve them and he wrote: "I do not like
> the idea that the Eclipse Maven plug-in is dictating the way our
> projects are structured. I also explained that the core technologies
> (ergo Java, J2EE, Spring, Maven, AndroMDA, Subversion etc) are what we
> are working to and that workarounds (like running Maven tasks from the
> command line) are acceptable." At the moment I do not have feasible
> solution(s) to all these issues mentioned above. I'll have in a short
> time another project that uses the similar structuring but currently is
> based on Maven1. There will be the migartion to Maven2 and it may be
> possible to find and validate the solution that can be implemented by
> other applications as well.
>
> Sorry, message appeared to be wordy and, probably not interested to the
> community. If so, I'll still be interesting in finding solutions and
> will be happy communicate out of the news portal.
>
> Regards,
> Nick
>
|
|
|
| Re: multiple maven modules in one eclipse project [message #26835 is a reply to message #26751] |
Thu, 21 May 2009 05:39 |
| Eclipse User |
|
|
|
Igor,
I would to say my thanks as well for time spent on answering y questions.
In my view, there is a wider problem associated with all maven2 plugins
that generate source code that later need to be integrated with hand-made
code. AndroMDA is just one of, other include generation of SOA
applications using WSDL definitions (I do not have the names of the
plugins out of my head :-( ). What I can say - there is a generic use case
of multi-module maven project where some maven plugins generate code that
will be added to other modules as part of the source code. In general, the
generated code will consists of non-changeable by the developer code, i.e.
this code will always regenerated by the plugin (AndroMDA names it
'core'), and code that developer potentially can change (AndroMDA names it
'common') - the good example are the implementors of the interfaces. If
developer decides to code its own implementation, then plugin will not
replace it at code generation time.
For this use case there is no problem with maven execution from the
command line: folders can be deleted and recreated again and later
imported (refreshed) by Eclipse. The problems started when maven builds
are initiated by m2eclipse Eclipse plugin: when target folder is cleaned
the required sources need to be generated again, even if there was no
changes to the underlying definitions (UML model, WSDL descriptions, etc.)
AS one of possible solutions I can see the modification of the execution
of the clean goal: when in Eclipse only sources that are kept in the /src
folder need to be cleaned from the /target. This will keep generated code
within /target untouched and there will be no need to execute again the
code generation phase.
Second very important requirement is to use maven code that is not
embedder: my architect set a requirement of using maven 2.0.7 because
some other maven plugins used to build the application do not work
properly for the application (don't ask me about details - he is the boss
for the application :-) ). This maven version can be set as a standard for
project, m2eclipse can use forking to call this defined version, this
forking facility can be made configurable at the Eclipse project level.
As to AndroMDA test project that can be used for analysis: I can't chop it
from the actual project, however there is a AndroMDA sample that I'll try
to convert into something useable (but it may not be soon). AndroMDA maven
plugin is itself a mini-maven with its own project and folder structure
that was selected long ago. It can generate a new multi-module maven
project with all required structures and folders that support the AndroMDA
activities. There is no AndroMDA Eclipse plugin and I reckon the AndroMDA
guys do not recognised yet the potential problems. There are two AndroMDA
forums [1] and [2] where there are some topics with explanations and
questions.
I'll be happy to have a go with 0.9.9 when it will be ready.
Thanks in advance. With best regards,
Nick
nsorokin<at>whiteclarkegroup<dot>com
Nick<dot>Sorokin<at>googlemail<dot>com
[1] Project generator http://galaxy.andromda.org/forum/viewforum.php?f=20
[2] Installation & Configuration
http://galaxy.andromda.org/forum/viewforum.php?f=10
|
|
|
| Re: multiple maven modules in one eclipse project [message #27230 is a reply to message #26835] |
Fri, 29 May 2009 00:07 |
| Eclipse User |
|
|
|
Nick Sorokin wrote:
> For this use case there is no problem with maven execution from the
> command line: folders can be deleted and recreated again and later
> imported (refreshed) by Eclipse. The problems started when maven
> builds are initiated by m2eclipse Eclipse plugin: when target folder
> is cleaned the required sources need to be generated again, even if
> there was no changes to the underlying definitions (UML model, WSDL
> descriptions, etc.) AS one of possible solutions I can see the
> modification of the execution of the clean goal: when in Eclipse only
> sources that are kept in the /src folder need to be cleaned from the
> /target. This will keep generated code within /target untouched and
> there will be no need to execute again the code generation phase.
Nick, can you please elaborate how this scenario is different from,
say, "Project / Clean..." action, which cleans all the classes and
resources, regardless if they had changed or not and basically does the
full build.
regards,
Eugene
|
|
|
| Re: multiple maven modules in one eclipse project [message #27335 is a reply to message #27230] |
Sat, 30 May 2009 17:52 |
| Eclipse User |
|
|
|
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
|
|
|
| Re: multiple maven modules in one eclipse project [message #27817 is a reply to message #27335] |
Mon, 01 June 2009 12:58 |
| Eclipse User |
|
|
|
Originally posted by: igor.ifedorenko.com
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
>
>
>
|
|
|
| Re: multiple maven modules in one eclipse project [message #27898 is a reply to message #27817] |
Tue, 02 June 2009 11:29 |
| Eclipse User |
|
|
|
Hi,
I'll be looking forward for the support of the generating frameworks.
However, the AndroMDA as part of the project generation effectively
prepares most of settings required for Eclipse including .project and
classpath files. I was looking deeply into AndroMDA generated projects,
specifically their sample application timetracker (I've used completed
sample from the AndroMDA site) trying to find out the best possible
options for further development with Maven (m2eclipse) and I found the
m2eclipse for the same initial project state generates two very different
Eclipse projects depending on how the project was brought into Eclipse.
I followed the AndroMDA sequence
- checkout source (I've unzipped the timetracker-complete sample .zip file)
- run 'mvn install' from CLI
By AndroMDA the project after install is ready for further development and
testing with Eclipse.
I've tried two different approaches: 1) import as existing Java project
and allow m2eclipse control the dependencies, and 2) import as Maven
project. The results were success for approach 1) and 190 errors for
m2eclipse build. I was using Eclipse 3.4 (2008.06), m2eclipse
0.9.8.200905041414, maven 2.1.0 and AndroMDA 3.3.
Effectively, this means that m2eclipse cannot import multi-module projects
prepared using AndroMDA. Probably, this needs to be registered as
m2eclipse problem. The problem I'm facing now is how I can prevent
execution of maven goals for some of modules in the project and how I can
prevent the cleanup of some resources under /target folder - advices are
greatly appreciated.
Regards,
Nick
PS If necessary, I can provide all samples used during my investigation
and relevant build reports.
|
|
|
Goto Forum:
Current Time: Sat Jul 05 16:39:07 EDT 2025
Powered by FUDForum. Page generated in 0.06585 seconds |
Home