Maven 2.x JAR Plugin

Allow includes/excludes specification

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.2
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    4

Description

Allow the specification of includes / excludes to customise jar content.

Issue Links

This issue is duplicated by:
MJAR-80 excludes is not working for maven-jar-plugin Critical Closed
This issue relates to:
MJAR-13 configure test-jar to include only special classes of the test source Minor Closed
This issue is related to:
MJAR-72 Option to include source within the jar artifact Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Brett Porter added a comment -

you can already do this on compilation and resources that causes them to be omitted. Is that enough?

Show
Brett Porter added a comment - you can already do this on compilation and resources that causes them to be omitted. Is that enough?
Hide
Permalink
Michael Böckling added a comment -

Unfortunately not.
I wouldn't have thought of this in the first place, but he problem here is that I have a legacy ANT build, where a test.jar is being produced that contains a subset of the compiled test-classes.
I guess this feature is relatively easy to implement and is useful in all cases where a test.jar should be deployed that is stripped from all files that are environment-specific (that were possibly created through pofile-specific filtering).

Show
Michael Böckling added a comment - Unfortunately not. I wouldn't have thought of this in the first place, but he problem here is that I have a legacy ANT build, where a test.jar is being produced that contains a subset of the compiled test-classes. I guess this feature is relatively easy to implement and is useful in all cases where a test.jar should be deployed that is stripped from all files that are environment-specific (that were possibly created through pofile-specific filtering).
Hide
Permalink
Mike Perham added a comment -

A patch would get this fixed quickly.

Show
Mike Perham added a comment - A patch would get this fixed quickly.
Hide
Permalink
Simon Kitching added a comment -

I'd also like to see include/exclude for the jar plugin. Like the original requester, I have a project (jakarta commons logging) where three jars are created: one with the full set of classes, and two with selected subsets. All three need to be created to build a "distribution". Splitting into separate modules doesn't seem right to me; this is the same codebase with exactly the same classes, unit tests, etc. It's more like the "classifier" concept. Rebinding maven-jar-plugin using executions with different include/exclude patterns configured would seem to be a perfectly fine solution to this problem. And besides, there is an ant build already in place, so restructuring the source code (breaking the ant build) just for the purposes of creating maven modules isn't tempting.

I'll try to create a patch, though for someone already familiar with maven plugins this would be a lot quicker!

Thanks, Simon

Show
Simon Kitching added a comment - I'd also like to see include/exclude for the jar plugin. Like the original requester, I have a project (jakarta commons logging) where three jars are created: one with the full set of classes, and two with selected subsets. All three need to be created to build a "distribution". Splitting into separate modules doesn't seem right to me; this is the same codebase with exactly the same classes, unit tests, etc. It's more like the "classifier" concept. Rebinding maven-jar-plugin using executions with different include/exclude patterns configured would seem to be a perfectly fine solution to this problem. And besides, there is an ant build already in place, so restructuring the source code (breaking the ant build) just for the purposes of creating maven modules isn't tempting. I'll try to create a patch, though for someone already familiar with maven plugins this would be a lot quicker! Thanks, Simon
Hide
Permalink
Alex added a comment -

I would like to see this added as well.

It is sometimes necessary to compile all classes, but package only a subset. For example to package an RMI client JAR I need to compile all classes in order to run the RMIC to generate client Stubs. I then need to package interfaces and stubs only and skip the server side implementation.

I find it very hard to do in Maven2 today without resorting to ANTRUN and such.

Show
Alex added a comment - I would like to see this added as well. It is sometimes necessary to compile all classes, but package only a subset. For example to package an RMI client JAR I need to compile all classes in order to run the RMIC to generate client Stubs. I then need to package interfaces and stubs only and skip the server side implementation. I find it very hard to do in Maven2 today without resorting to ANTRUN and such.
Hide
Permalink
Yossi Shmulevitch added a comment -

I think that this is important capability.
Since some plugins are generating classes (as wsdl2java axis plugin),
Sometimes there is need to omit classes from the final jar.

In my case it's a bug of the tool (or wrong behavior) but I can see places it's is needed.

Show
Yossi Shmulevitch added a comment - I think that this is important capability. Since some plugins are generating classes (as wsdl2java axis plugin), Sometimes there is need to omit classes from the final jar. In my case it's a bug of the tool (or wrong behavior) but I can see places it's is needed.
Hide
Permalink
Ilia Lewis added a comment -

I would also like to see this capability get added.

I've got a legacy project with an ant build that currently uses Java classes to generate other resources during the compile phase. The unit tests use these classes as well, so I cannot use ANTRUN to delete them after the compile phase. These classes are then excluded from the jar. I can't think of any way to get rid of these files short of relying on ANTRUN to delete them after the test phase, which feels like a hack.

I realize that if I had a brand new project that I could modify, I could find better ways of doing this, but based on the comments I've read here and elsewhere, there seems to be a hundred different reasons why someone would need to exclude files from the jar.

Thanks,

Ilia

Show
Ilia Lewis added a comment - I would also like to see this capability get added. I've got a legacy project with an ant build that currently uses Java classes to generate other resources during the compile phase. The unit tests use these classes as well, so I cannot use ANTRUN to delete them after the compile phase. These classes are then excluded from the jar. I can't think of any way to get rid of these files short of relying on ANTRUN to delete them after the test phase, which feels like a hack. I realize that if I had a brand new project that I could modify, I could find better ways of doing this, but based on the comments I've read here and elsewhere, there seems to be a hundred different reasons why someone would need to exclude files from the jar. Thanks, Ilia
Hide
Permalink
Paul Smith added a comment -

This would be a very handy feature. What's insidious is that:

http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html

Indicates that the exclude set is a valid option.

I have a need to create several customised (classified) jars for different purposes.

Show
Paul Smith added a comment - This would be a very handy feature. What's insidious is that: http://maven.apache.org/plugins/maven-jar-plugin/jar-mojo.html Indicates that the exclude set is a valid option. I have a need to create several customised (classified) jars for different purposes.
Hide
Permalink
Johan Kindgren added a comment -

This patch should fix MJAR-30 and MJAR-80.
Added integration tests for the include/exclude functionality.

Show
Johan Kindgren added a comment - This patch should fix MJAR-30 and MJAR-80. Added integration tests for the include/exclude functionality.
Hide
Permalink
Johan Kindgren added a comment - - edited

Have renamed the tests so that they refer to the issue that they are testing.
I have also updated the usage documentation to show how to include/exclude files from the produced jar.

The tests verifies both of the issues MJAR-30 and MJAR-80. The MJAR-13 issue seems to be a duplicate of MJAR-80, so that should be covered in the tests as well.

I slipped up twice creating the patch, but 'MJAR-30-maven-jar-plugin-1.patch' should be the one to use.

Show
Johan Kindgren added a comment - - edited Have renamed the tests so that they refer to the issue that they are testing. I have also updated the usage documentation to show how to include/exclude files from the produced jar. The tests verifies both of the issues MJAR-30 and MJAR-80. The MJAR-13 issue seems to be a duplicate of MJAR-80, so that should be covered in the tests as well. I slipped up twice creating the patch, but 'MJAR-30-maven-jar-plugin-1.patch' should be the one to use.
Hide
Permalink
Alex Deschapelles added a comment -

This might not be the right spot for this comment, but...

This bug has been killing me. Where can I get a snaphot of the plugin with this patch, or the source with the patch so I can build it myself.
I looked in the snapshot repositories and did not see one.

Thanks

Show
Alex Deschapelles added a comment - This might not be the right spot for this comment, but... This bug has been killing me. Where can I get a snaphot of the plugin with this patch, or the source with the patch so I can build it myself. I looked in the snapshot repositories and did not see one. Thanks
Hide
Permalink
Dennis Lundberg added a comment -

Alex, the patch has not been reviewed or applied yet. You will have to download the plugin sources from svn and apply the patch yourself, for the time being.

Show
Dennis Lundberg added a comment - Alex, the patch has not been reviewed or applied yet. You will have to download the plugin sources from svn and apply the patch yourself, for the time being.
Hide
Permalink
Alex Deschapelles added a comment -

I was unable to get the patch file to patch the code, (see attached failed-patch.txt) this might be my error.
I did manually apply the changes to the AbstractJarMojo.java file, compiled and tested the excludes portion of the patch, which worked for me.

Show
Alex Deschapelles added a comment - I was unable to get the patch file to patch the code, (see attached failed-patch.txt) this might be my error. I did manually apply the changes to the AbstractJarMojo.java file, compiled and tested the excludes portion of the patch, which worked for me.
Hide
Permalink
Alex Deschapelles added a comment -

Failure results when applying the patch

Show
Alex Deschapelles added a comment - Failure results when applying the patch
Hide
Permalink
Mark Eramo added a comment -

Is there a new version of the jar available that contains this patch? If not, how does one go about gettign the src and compiling it.

Thanks,
Mark

Show
Mark Eramo added a comment - Is there a new version of the jar available that contains this patch? If not, how does one go about gettign the src and compiling it. Thanks, Mark
Hide
Permalink
Mark Eramo added a comment - - edited

I do see the code attached above but I was not sure if I needed to pull it from an official repository.

Thanks,
Mark

Show
Mark Eramo added a comment - - edited I do see the code attached above but I was not sure if I needed to pull it from an official repository. Thanks, Mark
Hide
Permalink
Pablo Gutierrez added a comment -

I really would like this to be included, and as a previous post says,
it's documented as a valid option.

How can I apply the patch?
I tried to use maven-patch-plugin, but is not working.

Thanks,
Pablo

Show
Pablo Gutierrez added a comment - I really would like this to be included, and as a previous post says, it's documented as a valid option. How can I apply the patch? I tried to use maven-patch-plugin, but is not working. Thanks, Pablo
Hide
Permalink
Jörg Henne added a comment -

Any old patch implementation should do the trick. I attached a build of the patched version to save you and others the hassle, though.

Show
Jörg Henne added a comment - Any old patch implementation should do the trick. I attached a build of the patched version to save you and others the hassle, though.
Hide
Permalink
Mauro Talevi added a comment -

Johan,

MJAR-30-maven-jar-plugin-1.patch has been applied. Thanks for a very well tested patch!

I'm keeping issue open for two reasons:

1. ITs can be improved for readability. I'd like to rename them to reflect what test case they are testing rather than having them by issue number (BTW why the duplication of MJAR-30 and MJAR-80 tests?).

2. Oddly, while tests upon install are successful, tests upon deploy fail. More investigation is needed, although I suspect some setup-related problem.

In the meantime, I've deployed a snapshot to snapshot repo (http://people.apache.org/repo/m2-snapshot-repository)

Show
Mauro Talevi added a comment - Johan, MJAR-30-maven-jar-plugin-1.patch has been applied. Thanks for a very well tested patch! I'm keeping issue open for two reasons: 1. ITs can be improved for readability. I'd like to rename them to reflect what test case they are testing rather than having them by issue number (BTW why the duplication of MJAR-30 and MJAR-80 tests?). 2. Oddly, while tests upon install are successful, tests upon deploy fail. More investigation is needed, although I suspect some setup-related problem. In the meantime, I've deployed a snapshot to snapshot repo (http://people.apache.org/repo/m2-snapshot-repository)
Hide
Permalink
Johan Kindgren added a comment -

Updated the names of the testcases according to Mauros comment.

Show
Johan Kindgren added a comment - Updated the names of the testcases according to Mauros comment.
Hide
Permalink
Olivier Lamy added a comment -

IMHO this issue can be closed because it works in the trunk.
Thoughts ?

Show
Olivier Lamy added a comment - IMHO this issue can be closed because it works in the trunk. Thoughts ?
Hide
Permalink
Mauro Talevi added a comment -

Indeed - it does work (including the deploy). I'd left it open to apply the ITs renames as per patch.
But it can be descoped to separate issue.

Show
Mauro Talevi added a comment - Indeed - it does work (including the deploy). I'd left it open to apply the ITs renames as per patch. But it can be descoped to separate issue.
Hide
Permalink
Olivier Lamy added a comment -

Ok.
I will work on renaming its to more human readable names

Show
Olivier Lamy added a comment - Ok. I will work on renaming its to more human readable names
Hide
Permalink
Olivier Lamy added a comment -

its rename in rev 604533.

Show
Olivier Lamy added a comment - its rename in rev 604533.

People

Vote (44)
Watch (31)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.