Maven 1.x War Plugin
  1. Maven 1.x War Plugin
  2. MPWAR-21

war-plugin should be able to add manifest Class-Path Entry for dependencies

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.6
    • Labels:
      None
    • Number of attachments :
      0

      Description

      In the ejb-plugin we have the possibility to set the manifest Class-Path - Entry. The war-plugin should be able to do this accordingly.
      It should be possible to set the Class-Path-Entry WITHOUT bundling the dependencies.
      Generally it would be a good idea to centralize the manifest-Building somehow; currently manifest-buildung is done in different ways in
      jar, war, ear - plugins
      My simplified change of war:war is
      "
      <j:forEach var="dep" items="$

      {pom.dependencies}

      ">
      <j:if test="$

      {dep.getProperty('tmobile.war.manifest.classpath')=='true'}

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

      {tmobile.maven.war.classpath} ${dep.artifact}"/>
      </j:if>
      </j:forEach>
      "
      AND
      <ant:attribute name="Class-Path" value="${tmobile.maven.war.classpath}

      "/>

        Issue Links

          Activity

          Hide
          johan Eltes added a comment -

          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).

          Show
          johan Eltes added a comment - 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).
          Hide
          Augustinus Deimel added a comment -

          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>

          Show
          Augustinus Deimel added a comment - 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>
          Hide
          Felipe Leme added a comment -

          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>

          Show
          Felipe Leme added a comment - 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>
          Hide
          Felipe Leme added a comment -

          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

          Show
          Felipe Leme added a comment - 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
          Hide
          Patrick Burleson added a comment -

          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.

          Show
          Patrick Burleson added a comment - 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.
          Hide
          Patrick Burleson added a comment -

          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?

          Show
          Patrick Burleson added a comment - 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?
          Hide
          Felipe Leme added a comment -

          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

          Show
          Felipe Leme added a comment - 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
          Hide
          Lukas Theussl added a comment -

          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.

          Show
          Lukas Theussl added a comment - 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              Augustinus Deimel
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 1 hour
                1h
                Remaining:
                Remaining Estimate - 1 hour
                1h
                Logged:
                Time Spent - Not Specified
                Not Specified