[
https://jira.codehaus.org/browse/MPMULTIPROJECT-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MPMULTIPROJECT-55.
----------------------------------------
Resolution: Won't Fix
Please refer to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
if you're wondering why this issue was closed out.
> Example more generic usage multiproject goals.
> ----------------------------------------------
>
> Key: MPMULTIPROJECT-55
> URL: https://jira.codehaus.org/browse/MPMULTIPROJECT-55
> Project: Maven 1.x Multi-Project Plugin
> Issue Type: Improvement
> Affects Versions: 1.4.1
> Environment: Not of importance.
> Reporter: Davy Toch
>
> One of the problems I have with Maven 1 (currently using maven-1.1-beta-1) is
> knowing which goals can be executed on a certain project depends on the
> project type. For example if the project is of type 'jar', then jar:install
> should be called, while for a project of type 'ejb', ejb:install should be
> called. To avoid that the developer needs to know this, it is possible to
> create a custom maven.xml file. This could then include a goal 'install' that
> calls 'jar:install' for projects of type 'jar' and 'ejb:install' for projects
> of type 'ejb'. This way the developer could always call 'install',
> independent of the current project type. This is also more consistent with
> the approach of most IDE's (Eclipse, JBuilder, ...) where independent of
> project type, the tasks to call are build, rebuild, clean, ....
> However, the above approach would need a custom maven.xml file. In order to
> avoid this, I had a look at the multiproject plugin that already has generic
> goals (e.g. multiproject:artifact, multiproject:install, ...).
> On the website of the multiproject plugin they propose e.g.
> A. create a kind of 'master' project from which subprojects can inherit the
> POM configuration
> This master project has the following properties:
> maven.multiproject.basedir=..
> maven.multiproject.includes=*/project.xml
> maven.multiproject.excludes=master/project.xml
> Remark that with the above configuration the 'master' project has to be
> present in a folder 'master' that is on the same level as its subprojects.
> This flat project structure approach is chosen to avoid problems with the
> Eclipse IDE.
> B. different subprojects are defined on the same level as the 'master'
> project with the following property:
> maven.multiproject.type=jar (or ejb, war, ear, ...)
> This way you can e.g. call multiproject:artifact in the master project that
> will automatically call the necessary goal in the subprojects (jar:jar,
> ejb:ejb). However, if you only want to create the artifact for one
> subproject, you should go to the subproject and call jar:jar, ejb:ejb, ....
> Therefore the name of the goal to call is again different.
> A solution for this I have thought of is : define each Maven project as a
> multiproject, meaning that for the subprojects in B., the following
> properties are also defined (but with different values then in A.):
> maven.multiproject.basedir=${basedir}
> maven.multiproject.includes=project.xml
> maven.multiproject.excludes=
> On the other hand it is also useful to define the following in the master
> project:
> maven.multiproject.type=master
> With the above configuration you can:
> - call multiproject:artifact in the 'master' project : will generate all
> artifacts of the subprojects
> - call multiproject:artifact in a subproject : will generate the artifact for
> the subproject
> - ...
> Unfortunately, on
> http://maven.apache.org/reference/plugins/multiproject/properties.html the
> following is stated about the property maven.multiproject.includes:
> "The 'top-level' project that you use to run maven multiproject must not be
> included in the set of projects to be processed."
> Question : why this restriction?
> Remarks :
> 1. My multiproject approach has the following restrictions/problems:
> - only subprojects of the 'master' project should create artifacts, not the
> 'master' project itself (the master project is only used to avoid POM
> configuration duplication)
> - the master project can't inherit from another project itself
> - the subprojects are the base leaves in the inheritance tree, meaning that
> no other projects can inherit from the subprojects
> - reactor is always called
> - not fully tested when calling the goals to create the website
> - other problems?
> 2. Having maven.multiproject.type=master defined in the 'master' project is
> e.g. useful when working in Eclipse, because calling the generic goal
> multiproject:goal on the master project only calls the goal on the
> subprojects. However, if you want to work with your projects in Eclipse, you
> should also be able to generate the Eclipse project files (.classpath, ...)
> for the master project because otherwise you won't be able to call Maven
> goals on the master project from the Eclipse IDE. With
> maven.multiproject.type=master, you can have a custom goal
> 'generate-eclipse-files' (or similar) in a script maven.xml:
> <goal name="generate-eclipse-files">
> <j:set var="type"
> value="${context.getVariable('maven.multiproject.type')}"/>
> <attainGoal name="eclipse"/>
> <!--
> If the current project type is 'master', then the eclipse goal should
> also be called on the subprojects.
> -->
> <j:if test="${type == 'master'}">
> <attainGoal name="multiproject:goal">
> <j:set var="goal" value="eclipse"/>
> </attainGoal>
> </j:if>
> </goal>
> This goal is generic and can thus be put in 'master' projects or subprojects,
> so my intent is satisfied: minimize custom scripting in maven.xml and if
> scripting is really necessary, make it as generic as possible. On the other
> hand, I think it would be easy to create a goal multiproject:run-goal-on-all
> in the maven multiproject plugin that is similar to multiproject:goal but
> that can run the goal on the parent project as well. This would avoid having
> to write a custom script maven.xml.
> Regards,
> Davy Toch
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
