Maven 2 & 3

adding a phase called prepare-package

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.2
  • Fix Version/s: 2.1.0, 3.0-alpha-1
  • Component/s: Plugins and Lifecycle
  • Labels:
    None
  • Environment:
    all
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

Hi,
I have an artifact (packaging war).
I have some jobs to do (xdoclet-maven-plugin others internal plugin) which are only needed for included materials in the war :

  • web.xml
  • automatic generated pages (about page etc..)
    Actually I attached it tho the phase process-classes or test.
    But when I just want to try a simple the simple : mvn -Dtest=something clean test.
    All of my .java are parsed by the plugin and all other jobs made whereas this should be done in a phase just before packaging.
    I really need a phase just before package to place all this jobs.
    Probably this can be extends to phase deploy.
    Olivier

Issue Links

Activity

Hide
Thomas Will added a comment -

I've got a similar situation. Need to perform some work prior to 'package', but only when 'package' is to be executed after.
A prepare-package phase would be a clean solution and avoid any dirty workarounds.
Tom.

Show
Thomas Will added a comment - I've got a similar situation. Need to perform some work prior to 'package', but only when 'package' is to be executed after. A prepare-package phase would be a clean solution and avoid any dirty workarounds. Tom.
Hide
Olivier Lamy added a comment -

attached the very very simple patch.
Is there any chance to have this ?

  • Olivier
Show
Olivier Lamy added a comment - attached the very very simple patch. Is there any chance to have this ?
  • Olivier
Hide
Felipe Leme added a comment -

Olivier,

I agree with you that such phase is necessary, but that might be situations where you need to use the same package on the integration-test phase and only change it right before install. So, it might be better to add 2 new phases, 'prepare-package' (or 'pre-package') as proposed and 'pre-install'.

Also, it's necessary a tool (probably a plugin) to facilitate this preparation; something like a maven-package-tuner-plugin which takes as configuration the files to be included/excluded from the package. Something like:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-package-tuner-plugin</artifactId>
<configuration>
<excludes>/classes/*Mock.class</excludes>
<excludes>/test.jsp</excludes>
<includes>
<dir>src/it/resources</dir>
<files>*.xml</files>
</includes>
</configuration>
</plugin>

Of course, this is just an example - the real plugin should use a familiar includes/excludes syntax (like the Ant way).

– Felipe

Show
Felipe Leme added a comment - Olivier, I agree with you that such phase is necessary, but that might be situations where you need to use the same package on the integration-test phase and only change it right before install. So, it might be better to add 2 new phases, 'prepare-package' (or 'pre-package') as proposed and 'pre-install'. Also, it's necessary a tool (probably a plugin) to facilitate this preparation; something like a maven-package-tuner-plugin which takes as configuration the files to be included/excluded from the package. Something like: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-package-tuner-plugin</artifactId> <configuration> <excludes>/classes/*Mock.class</excludes> <excludes>/test.jsp</excludes> <includes> <dir>src/it/resources</dir> <files>*.xml</files> </includes> </configuration> </plugin> Of course, this is just an example - the real plugin should use a familiar includes/excludes syntax (like the Ant way). – Felipe
Hide
Al Robertson added a comment -

Oliver,
I made the change you suggested - and now have a new phase in my environment.
Using a profile, my ant tasks get fired correctly on the pre-package phase.

My issue now is that I need to bind the WAR plugin exploded goal to the 'pre-package' phase - not the 'package' phase.
It is not getting fired in the new pre-package phase as I expect.
I have locally installed a snapshot version of the WAR plugin with the annotation phase changed and I can see the change in the plugin.xml.

<mojo>
<goal>exploded</goal>
<description>Generate the exploded webapp</description>
......
<phase>pre-package</phase>
<implementation>org.apache.maven.plugin.war.WarExplodedMojo</implementation>
<language>java</language>
.....

I've configured the WAR plugin in my project pom to use the local snapshot and I have the debug line
[DEBUG] maven-war-plugin: using locally installed snapshot
produced when I execute >mvn pre-package
but it's not running the war:exploded goal!

Any ideas. Is there a configuration cache I need to reset? Do the plugin phase bindings get evaluated at runtime every time?
Any help appreciated.

Show
Al Robertson added a comment - Oliver, I made the change you suggested - and now have a new phase in my environment. Using a profile, my ant tasks get fired correctly on the pre-package phase. My issue now is that I need to bind the WAR plugin exploded goal to the 'pre-package' phase - not the 'package' phase. It is not getting fired in the new pre-package phase as I expect. I have locally installed a snapshot version of the WAR plugin with the annotation phase changed and I can see the change in the plugin.xml. <mojo> <goal>exploded</goal> <description>Generate the exploded webapp</description> ...... <phase>pre-package</phase> <implementation>org.apache.maven.plugin.war.WarExplodedMojo</implementation> <language>java</language> ..... I've configured the WAR plugin in my project pom to use the local snapshot and I have the debug line [DEBUG] maven-war-plugin: using locally installed snapshot produced when I execute >mvn pre-package but it's not running the war:exploded goal! Any ideas. Is there a configuration cache I need to reset? Do the plugin phase bindings get evaluated at runtime every time? Any help appreciated.

People

Vote (6)
Watch (10)

Dates

  • Created:
    Updated:
    Resolved: