Maven 1.x War Plugin

I would suggest that the name of the depepency property is "de-pluginalized" from ejb.manifest.classpath to manifest.classpath, so that the name could be shared across all J2EE module types (although I wouldn't include the ear in the list . Anyway, prio 1 is definitely to get the functionality into the war plug-in - with or without cleaning up the naming (so that as a next step, the ear plug-in could automatically collect dependent jars by scanning the poms of its dependent modules).

with maven 1.0 (final) this issue is "nearly" resolved insofar
that you can add a Class-Path entry in the manifest-File now for
the dependents if you like.
One little thing is not solved:
We would like to insert a simple "/" at the beginning Class-Path.
This is not possible with the current implementation.
We have changed the war:war goal like this:

<!-- build dependency list -->
<j:set var="maven.war.classpath" value=""/>
<!-EINGEBAUT->
<j:set var="tmobilePreClasspath" value="${tmobile.maven.war.pre.classpath}"/>
<j:if test="${!empty(tmobilePreClasspath)}">
<j:set var="maven.war.classpath" value="${tmobile.maven.war.pre.classpath}"/>
</j:if>
<!-EINGEBAUT ENDE->
<j:forEach var="dep" items="${pom.dependencies}">
<j:if test="${dep.getProperty('war.manifest.classpath')=='true'}">
<j:set var="maven.war.classpath" value="${maven.war.classpath} ${dep.artifact}"/>
</j:if>
</j:forEach>

This was solved on release 1.6. From changes.xml:

<action dev="dion" type="update" issue="MPWAR-21">Allow automated generation of manifest Class-Path</action>

Augustinus,

I agree that an initial classpath is useful. In fact, I had to locallly modify the plugin in order to provide that too, but in my case I didn't use a special property, I just changed the line:

<j:set var="maven.war.classpath" value=""/>

to:

<j:set var="maven.war.classpath" value="${maven.war.classpath}"/>

So, if Dion (and others) is fine with this change, I can commit it to CVS and close this bug.

– Felipe

PS: for consistency's sake, if we do this change, we should apply it to the maven-ear plugin as well...

So, it

PS: please ignore my previous comment, it was generated by Jira when I update MPWAR-2

I've notice that the war plugin does honor the war.manifest.classpath which is cool. The only problem I'm seeing is every time I build a war, another Class-path: entry gets added to the MANIFEST.MF file. So after 4 builds, I have 4 Class-path: lines. For whatever reason, the EJB plugin doesn't have this problem. I thought it was the update="true" parameter to the ant:jar task, but removing that doesn't seem to fix it.

I take that back. I removed the update parameter from a temp file. Not the actual plugin.jelly script. When I took it out in the actual script, things started working, no duplicate Class-path: entries.

Is there a reason to use update="true" instead of just building a whole new WAR? When in fact, it should be assumed that the WAR should be brand new since a new build is taking place?

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

This issue is marked fixed in release 1.6 of the war plugin, please open a new ticket for anything that needs to be done still.