[jira] Commented: (MNG-1950) Ability to introduce new lifecycles phases

["Chris Hagmann (JIRA)" <ji...@codehaus.org>]

    [ 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>
    <artifactId>maven-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