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 18: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 #26630 is a reply to message #26594] |
Mon, 18 May 2009 19:33  |
| Eclipse User |
|
|
|
Originally posted by: igor.ifedorenko.com
Nick,
This is rather generic description of your project structure. Can you
list specific problems that you face when using m2e to work on your
projects? I understand m2e does not pick JDK you need, but what else?
Also, how do you import your multi-module projects in Eclipse workspace,
as multiple workspace projects or as one workspace project?
--
Regards,
Igor
Nick Sorokin wrote:
> Hello!
>
> I'm working in the company that developes and delivers financial J2EE
> applications that consist of dozen separate parts developed sometimes in
> different locations.
>
> The most of applications use AndroMDA to generate Java source code from
> UML and use Maven to perform the build. The average application consists
> of 10-15 separate Maven multi-module projects where individual module is
> used to generate single artefact that later will be used as a
> dependancy. For the developer is not unusual to checkout more than one
> multi-module project from the repository and sometimes perform the maven
> builds both from the command line and from the Eclipse.
>
> The individual projects may vary from simple user interface (basically
> HTML or JSPs) to the projects that implement the data access and
> business logic both as online application and Web service. All these
> projects usually are stored as individual entity in the source
> repository and checked out as a whole Eclipse project. They also have
> their own release activity.
>
> Projects that use AndroMDA to create the code from UML usually consist
> of threeparts: 1) code that implement data access to the underlying data
> base (Hibernate was selected as basic framework and is extended with
> company' specific features) - this code is never changed by developer;
> 2) DAO interface layer that provides the implementation of the abstracts
> of the data access layer - source code for this module consists of code
> generated by AndroMDA and code added by developer to implement
> application specifics; 3) it may be one or more additional modules that
> contain developed code that implements required functionality. Some of
> challenges we have have been discussed earlier [1] but I'm still looking
> for better solutions for the intergration of Maven and Eclipse.
>
> This structure is fully supported by Maven in batch mode and our
> developers would like to more support of the straightforward Maven
> functions in the Eclipse environment. The developer team uses outdated
> version of the m2eclipse for which they developed some workouts around
> Maven-Eclipse integration problems. Functionality implemented in
> m2eclipse 0.9.x does not bring a lot of help because it does not fully
> follows the Maven phlosophy of the builds. At the moment m2eclipse is
> used only as Eclipse classpath builder.
>
> I would like to see the further steps for the successful integration of
> the Maven into Eclipse in such a way that main Maven principles will
> stay unchanged.
> I hope that my input will help m2eclipse developers to understand better
> the structure of the possible projects and challenges that companies have.
>
> Regards,
> Nick Sorokin
>
> PS. I'll be happy to discuss further the problems of m2eclipse in real
> development.
>
> N.
>
> [1]
> http://www.eclipse.org/newsportal/article.php?id=298&gro up=eclipse.technology.m2e#298
>
>
|
|
|
| Re: multiple maven modules in one eclipse project [message #26672 is a reply to message #26630] |
Tue, 19 May 2009 10:06 |
 Nick Sorokin
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
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 21: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 09:39 |
Nick Sorokin
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
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 04:07 |
Eugene Kuleshov
Messages: 505
Registered: July 2009 |
Senior Member |
|
|
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 21:52 |
Nick Sorokin
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
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 16: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 15:29 |
Nick Sorokin
Messages: 9
Registered: July 2009 |
Junior Member |
|
|
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: Mon Sep 23 10:58:24 GMT 2019
Powered by FUDForum. Page generated in 0.02295 seconds |
Search
Help
Register
Login
Home
