[jira] Commented: (MNG-1950) Ability to introduce new lifecycles phases
[ http://jira.codehaus.org/browse/MNG-1950?page=comments#action_68865 ] Al Robertson commented on MNG-1950: --- Can I add my related issue to this one! http://jira.codehaus.org/browse/MNG-2415 Ability to introduce new lifecycles phases -- Key: MNG-1950 URL: http://jira.codehaus.org/browse/MNG-1950 Project: Maven 2 Type: Wish Components: Design, Patterns Best Practices, Plugins and Lifecycle Versions: 2.0.1 Reporter: Chris Hagmann Assignee: Brett Porter Fix For: 2.1 I have simple use case which I cannot resolve with Maven 2 as it is right now. I have a project (actually many), where I need to do the following: - Create an JAR artifact (standard stuff, easily possible) - Create a source code artifact (standard stuff, easily possible) - Create Javadoc and a JAR archive of it (not possible, I explain why). - Create a distribution package with release notes, customized reports, Javadoc, JAR, dependencies, documentation, filtered files, etc. (not possible, I explain why and will file another JIRA issue for this) The constraint is that I need to create all 4 artifacts and have them installed them in the repository when using mvn install. As there are no other appropriate lifecycle phases in the default lifecycle, I attach the generation of all 4 artifacts to the phase package. That is very messy, and won't provide me with what I need. It should be possible to define a new lifecycle and have new phases attached to it. E.g.: - ... (standard lifecycle phases) - test - jar - javadoc - source-archive - javadoc-archive - package - ... (standard lifecycle phases) The reason why it is mandatory at this point to have new lifecycle phases, is that there is a constraint that a plugin can have only one unique configuration per lifecycle phase. So if I need to use the same plugin, but e.g. using different goals which require different plugin configurations, then that's not possible. The only way this can be achieved is by using new lifecycle phases, which is also not possible at this point. Meaning, I cannot create a solution for my simple use case in Maven 2 and hence it blocks me for moving to Maven 2 (I really hate to file blockers, but I'm at a dead-end). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1950) Ability to introduce new lifecycles phases
[ http://jira.codehaus.org/browse/MNG-1950?page=comments#action_68868 ] Olivier Lamy commented on MNG-1950: --- or this http://jira.codehaus.org/browse/MNG-2097 ? Ability to introduce new lifecycles phases -- Key: MNG-1950 URL: http://jira.codehaus.org/browse/MNG-1950 Project: Maven 2 Type: Wish Components: Design, Patterns Best Practices, Plugins and Lifecycle Versions: 2.0.1 Reporter: Chris Hagmann Assignee: Brett Porter Fix For: 2.1 I have simple use case which I cannot resolve with Maven 2 as it is right now. I have a project (actually many), where I need to do the following: - Create an JAR artifact (standard stuff, easily possible) - Create a source code artifact (standard stuff, easily possible) - Create Javadoc and a JAR archive of it (not possible, I explain why). - Create a distribution package with release notes, customized reports, Javadoc, JAR, dependencies, documentation, filtered files, etc. (not possible, I explain why and will file another JIRA issue for this) The constraint is that I need to create all 4 artifacts and have them installed them in the repository when using mvn install. As there are no other appropriate lifecycle phases in the default lifecycle, I attach the generation of all 4 artifacts to the phase package. That is very messy, and won't provide me with what I need. It should be possible to define a new lifecycle and have new phases attached to it. E.g.: - ... (standard lifecycle phases) - test - jar - javadoc - source-archive - javadoc-archive - package - ... (standard lifecycle phases) The reason why it is mandatory at this point to have new lifecycle phases, is that there is a constraint that a plugin can have only one unique configuration per lifecycle phase. So if I need to use the same plugin, but e.g. using different goals which require different plugin configurations, then that's not possible. The only way this can be achieved is by using new lifecycle phases, which is also not possible at this point. Meaning, I cannot create a solution for my simple use case in Maven 2 and hence it blocks me for moving to Maven 2 (I really hate to file blockers, but I'm at a dead-end). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1950) Ability to introduce new lifecycles phases
[ http://jira.codehaus.org/browse/MNG-1950?page=comments#action_61196 ]
Chris Hagmann commented on MNG-1950:
I have another use case which indicates that Maven needs more flexibility in
the configuring lifecycles:
Problem: We need to do a couple of things which are not part of the build
process. As an example, during the development phase engineers need to deploy
the application on an application server every so often (e.g. to test bug
fixes, etc.). But of course we don't want to perform such a deployment every
time we create a release of the application.
Current workaround: We are using the antrun plugin to execute a target in ANT
which performs the actual application deployment on the application server.
However, by default the antrun plugin has a configuration per lifecycle
phase, and a global configuration. As we don't want to tie the application
deployment onto the app server to any lifecycle phase, we configure the antrun
plugin using a global configuration:
...
plugin
artifactIdmaven-antrun-plugin/artifactId
configuration
tasks
ant antfile=${basedir}/deploy.xml inheritRefs=true
!-- specify properties for passing to deploy.xml--
property name=product.name value=${pom.artifactId}/
property name=product.version value=${pom.version}/
...
target name=deploy/
It looks as if we can now simply execute mvn antrun:run to execute the task
deploy. However, this only works if we don't have multiple ANT targets to be
exeucted for different purposes (e.g. deploy to deploy application on app
server, restart to restart application server, etc.).
Expectation: I think it is a reasonable expectation that Maven is not only a
simple (but powerful) build tool, but that it can be used for other tasks as
well. Hence I think it should really be possible to define custom lifecycle
phases, and that they may be plugged into the default lifecycle execution
process. On my wishlist would even be that a user can define different
lifecycles for different purposes (e.g. one lifecycle with x phases for
building a release, one lifecycle for deploying the application on an app
server, etc.)
P.S: I know that JIRA is not the best place to have discussions like this.
Please indicate a better place (e.g. WIKI) if there is any.
Ability to introduce new lifecycles phases
--
Key: MNG-1950
URL: http://jira.codehaus.org/browse/MNG-1950
Project: Maven 2
Type: Wish
Components: Design, Patterns Best Practices, Plugins and Lifecycle
Versions: 2.0.1
Reporter: Chris Hagmann
Assignee: Brett Porter
Fix For: 2.1
I have simple use case which I cannot resolve with Maven 2 as it is right
now. I have a project (actually many), where I need to do the following:
- Create an JAR artifact (standard stuff, easily possible)
- Create a source code artifact (standard stuff, easily possible)
- Create Javadoc and a JAR archive of it (not possible, I explain why).
- Create a distribution package with release notes, customized reports,
Javadoc, JAR, dependencies, documentation, filtered files, etc. (not
possible, I explain why and will file another JIRA issue for this)
The constraint is that I need to create all 4 artifacts and have them
installed them in the repository when using mvn install.
As there are no other appropriate lifecycle phases in the default lifecycle,
I attach the generation of all 4 artifacts to the phase package. That is
very messy, and won't provide me with what I need. It should be possible to
define a new lifecycle and have new phases attached to it. E.g.:
- ... (standard lifecycle phases)
- test
- jar
- javadoc
- source-archive
- javadoc-archive
- package
- ... (standard lifecycle phases)
The reason why it is mandatory at this point to have new lifecycle phases, is
that there is a constraint that a plugin can have only one unique
configuration per lifecycle phase. So if I need to use the same plugin, but
e.g. using different goals which require different plugin configurations,
then that's not possible. The only way this can be achieved is by using new
lifecycle phases, which is also not possible at this point. Meaning, I cannot
create a solution for my simple use case in Maven 2 and hence it blocks me
for moving to Maven 2 (I really hate to file blockers, but I'm at a dead-end).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
