[PATCH] Option to pack project classes inside a JAR into WEB-INF/lib

Patch that implements the proposal, if the user sets the maven.war.usesJar propertie to true (default value is false).

Notice that in order to include the jar on WEB-INF/lib, it's necessary to call <attaingGoal name="jar:jar">. That might make the goal being called twice, but I don't think there is a better way to solve it (we could avoid it if the <goal> tags allowed if/unless attributes, as Ant does).

I was going to mark this as "Won't Fix" because it kind of goes against Maven way of doing thing (in other words, there should be a JAR project, a WAR project and a multi-project in this case), besides the fact of the jar goal being called twice.

But then I realized there are 3 votes for this issue. So, what should we do, keep it open, discuss the solution again or mark it as 'Won't Fix'?

– Felipe

+1 for adding this feature.

If you have a single webapp project you can prefer to pack your classes in a single jar for distribution: you can consider this as a different way to package things, using multiproject with a parent project and 2 subproject is overkilling in this situation.
The artifact will still be only one: a war packaged in a different way.

ps. the patch should be modified to only use jar:jar as a prereqs, so that it will not be called twice

Hi Fabrizio,

The problem with adding jar:jar as prereqs is that it would be called anyway, even if the project does not have any Java file (there might be situations where calling jar:jar is not desirable in a war project).

– Felipe

Hi Felipe,
the jar:jar goal can be added as a prereqs for a specific goal, only used when maven.war.usesJar is set. Since jar will only be called if this property is set it will not executed if the project doesn't have any java file.

This is the goal using a prereqs:

<j:choose>
<j:when test="$

">
<util:available file="$

"
includes="$

"
excludes="$

">
</ant:fileset>
</ant:copy>
</util:available>
</j:when>
<j:otherwise>
<attainGoal name="war:webapp-using-jar"/>
</j:otherwise>
</j:choose>
</goal>

<goal name="war:webapp-using-jar" prereqs="war:war-resources,test:test,jar:jar"
description="Internal goal called when maven.war.usesJar is set">
<ant:copy todir="$

" file="$

/$

-$

.jar"/>
</goal>

I'm still not particularly enamored with this, probably because of the use cases I've seen quoted in here to produce two things from a project. Doing so mucks with the way m2 does things, and generally adds to the guesswork of what a project is doing.

I'm -0.75, but won't block it being committed if Felipe wishes to do so. Bear in mind that we hope to start replacing all of the m1 plugins with functionality equivalent wrappers around their m2 counterparts "real soon now", so there is a risk this will disappear again unless you are prepared to make the change there too/instead.

I've mentioned this before on the mailing list...Maven needs to be careful to balance "the Maven way" vs. making things that should be trivial, hard on users. As someone mentioned above, this is strictly about packaging within a WAR; separate projects just to get your classes JAR'ed and placed in WEB-INF/lib is extreme overkill.

I remember asking for this a while back. In my case I wanted to be able to get package information (build/revision, company etc) when an exception occured in a webapp. In the end I had to use a rather ugly custom solution to do it.

I don't actually think it's against the "Maven Way"... it just makes the WAR a little cleaner and allows the use of the java.lang.Package class to actually get information about the class in question (it mostly uses the manifest). It also makes deploying hot-fixes simple as you only need to replace on jar file.

I see this as a simple property, off be default that will tell the war plugin to bundle it all up in a jar and copy that instead of simply sending all the raw classes to /target/webapp/WEB-INF/classes... in fact even though its adding another operation to the war goal, it might make it faster as a copy tends to be slow.

Anyway, I've added another vote for it, and hope to see it in the future.

updated patch, adds the jar generation as a prerequisite

I'm unassigning it as I haven't been able to do any Maven work on the last 2-3 months and the situations doesn't seem to be changing in the short time

I had a look at the source code of today's svn trunk and saw that the jar is created individually. I suggest to check first if there is already a created jar (created by maven-jar-plugin) and use this if it exists. In this case you can benefit from the power of the maven-jar-plugin (edit manifest for example).

Cheers,
Martin