type zip for packaging ?

Hi,
If you are interested, I can provide a maven-zip-plugin.
For the moment, I provided his own lifecycle defined in his own META-INF/plexus/components.xml.
Then I will provided a patch for maven-war-plugin (http://jira.codehaus.org/browse/MNG-1669).
To add in plugin configuration something as :
<resource>
<directory>$

/webappdir/OTAStats</targetPath>
<filtering>true</filtering>
<excludes>
<exclude>subhtml/**</exclude>
</excludes>
<includes>
<include>**</include>
</includes>
<dependecies>
<dependency>
<groupId>groupId</groupId>
<artifactId>artifact</artifactId>
<version>version</version>
<unpack>true</unpack>
</dependency>
</dependencies>
</resource>
With this all resources contains in the dependency will unpack or not in the targetPath.
Just let me know if it sounds good or not (a private feature or a community shared feature).
And if it include some trouble with the issue http://jira.codehaus.org/browse/MNG-1507
Thanks

Sorry now I'm at work and for security reasons I can't provide svn diff.
I provid three files :

• maven-zip-plugin.tar.gz (simple plugin to enabled packaging zip)
• maven-war-plugin.tar.gz (simple rewrite to enable other inclusions look at configuration.apt)
• MNG-1683.tar.gz a simple applications to illustrate the use case.
  Install the two plugins.
  After In the MNG-1683 , try :
• mvn install
• mvn -P dev install
  Note the different war content ./MNG-1683-webapp1/target/MNG-1683-webapp1-1.0-SNAPSHOT.war

Just let me know if this kind of feature can be integrated in the maven core, or if I need just to made this feature only in corporate war plugin (;-()

• Olivier

Concerning war feature certainly duplicate with http://jira.codehaus.org/browse/MNG-791 ()

Hi Oliver,

seems to be a usefiul addition. We have some webapps, where we use the same javascript framework. Currently it is stored multiple times ... once for each webapp :-/

This addition would eliminate that need.

I think http://jira.codehaus.org/browse/MWAR-8 will help to solve.
Html/javascript/images content could be included in a war packaging.
Others agree to close it ?

Olivier

Hi Olivier,

The War Plugin code you supplied works very well thank you.

Any chance of the modifications you made to the War Plugin as a Patch, So I can work out the individual changes.

I need to apply it to the latest version (2.2-SNAPSHOT) as I am up against another issue (MWAR-54).

Thanks and Regards

Peter

The situation described throughout this issue describes a very specific use case that may have been able to be resolved through another means, but there are other situations where a zip file is the only desired artifact to be packaged. The assembly plugin can be used to generate ZIP files, but in such cases, this requires the project to specify an arbitrary packaging type (jar, ear, etc), producing an unnecessary main artifact. It would be beneficial to include a zip packaging type in the maven core using a standard maven-zip-plugin.

Define your main artifact as "pom", then use assembly:attached to create your zip. I had once atttempted to introduce a compression plugin but withdrew due to assembly can do the same work. There is no need to introduce 2 similar works.

I also use the method Dan described. However, it isn't an uncommon use case if you want to share things around in Maven. It's a fact of life that compressed artifacts need to get into the repository. I think a new lifecycle type should be added that uses the assembly plugin to do the packaging. In this case, we should declare that the contents of folder x (like src/main/resources for example) automatically get included in the zip. This way no additional assembly.xml is needed. This would be a nice, clean and straight forward way to allow users to create zips.

then we end up with bunch life cycles to support mutliple packaking types ..... zip, tar, tgz, bz2, etc. but it may not be a bad idea

I'm sure we could find a way to make it work with one lifecycle. The mojo in assembly could just take type in the config and have the zip just be default.

I agree that we need a zip packaging and plugin. The assembly mojo is a hack is you just want to generate a zip of your project. The reason is that the packaging should represent what your project is and pom is certainly not right. Also the assembly plugin attaches a secondary artifact. In some cases I want my zip to be the primary artifact and not a secondary one.

I need to have the war unpack feature available to maven-war-pgin-2.0.2. So I have applied the functionality that Oliver added in his 2.0 attachements above to the 2.0.2 plugin. I have generated a patch and attached it. Also required is a zip file for testing.

Looking forward to having this as a supported feature rather than being out on a branch o)

Peter

Apply Oliver's war plugin unzip resource dependencies changes to 2.0.2

Olamy can you push these other patches to the respective plugins. I will add support for the zip type.

Simple zip artifact handling dealth with.

Whats about reopen this issue or create a new one in order to fix this in 2.0.x branch ?

+1 for a 2.0.x fix.

reopen the issue as it's not fixed.
See thread http://www.nabble.com/Zip-packaging-in-2.0.x-%28MNG-1683%29-td14721657.html#a14821406

I don't understand why we aren't talking about making a "archive" packaging type.

It would be so simple by using Plexus Archiver.

In fact I made a plugin supporting zip, gzip, tar and tgz as packaging types.

Yes but the goal here is to able to have in your pom :

<packaging>zip</packaging>

Sorry I wasn't clear.

<packaging>zip</packaging>

<packaging>tar</packaging>

<packaging>tgz</packaging>

etc..

This is what I was talking about.

But instead of making a plugin for each why not create a "archive" plugin
which contains these components.

It would in essence be a Plexus Archiver wrapper.

This way it assures a compatibility between different
core plugins i.e.: dependency plugin

I got permission from my boss to release our plugin for handling the zip and tar packaging.

It's based on Plexus Archive.

Do whatever you want with it

There's also a file-plugin (only file:copy right now)

They are a bit in the rough as I just finished them...

what is the status of this issue? What does the fix version of "3.X (to be reviewed)" mean?

issues that haven't been looked at recently have been marked for review so we can schedule them (and close those that aren't reproducible / already fixed / etc). The issue history still shows the current 'status'

We are interested in this ticket and we have tried the solution provided by Pino. We have used it succesfully for some time but now we need to add type zip as a dependency for another project but is not possible. We expect that maven treats the dependency as an overlay like it does with war type. Is it getting to complex? Does it makes sense?

Regards