Maven 2.x WAR Plugin

Ability to deploy the content of WEB-INF/classes as a classified artifact

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.1-alpha-1
  • Fix Version/s: 2.1-alpha-2
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

If the server-side code of a war project need to be reused somewhere, we need to deploy the content of the WEB-INF/classes to be able to use it as a dependency

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. MWAR-73 war overlay mechanism does not work for classes

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stéphane Nicoll added a comment -

Done

attachClasses flag triggers the creation of the jar that will be attached. classesClassifier defines the classifier of the attached artifact (classes by default)

Show
Stéphane Nicoll added a comment - Done attachClasses flag triggers the creation of the jar that will be attached. classesClassifier defines the classifier of the attached artifact (classes by default)
Hide
Permalink
Wendy Smoak added a comment -

Added a faq describing (but advising against) the new functionality. (r640119)

IMO this contradicts the best practice of "one artifact per pom".

And what will it mean to declare a dependency on a jar (with a classifier) when the associated pom has packaging=war?

Show
Wendy Smoak added a comment - Added a faq describing (but advising against) the new functionality. (r640119) IMO this contradicts the best practice of "one artifact per pom". And what will it mean to declare a dependency on a jar (with a classifier) when the associated pom has packaging=war?
Hide
Permalink
Stéphane Nicoll added a comment -

I agree Wendy but in many cases you just don't have the choice.

Some users use the technique you mention to have dependency management working with multiple war overlays (till we find an acceptable solution). The problem is the overlay functionality in maven which is not supported properly

Show
Stéphane Nicoll added a comment - I agree Wendy but in many cases you just don't have the choice. Some users use the technique you mention to have dependency management working with multiple war overlays (till we find an acceptable solution). The problem is the overlay functionality in maven which is not supported properly
Hide
Permalink
Wendy Smoak added a comment -

Added an integration test in r642499, please take a look at it.

Chatting on irc, Jason thought that the packaging=war in the pom associated with the classified artifact would cause a problem. I thought the jar might be excluded from the classpath and/or treated as an overlay, but it actually seems to work fine.

Show
Wendy Smoak added a comment - Added an integration test in r642499, please take a look at it. Chatting on irc, Jason thought that the packaging=war in the pom associated with the classified artifact would cause a problem. I thought the jar might be excluded from the classpath and/or treated as an overlay, but it actually seems to work fine.
Hide
Permalink
Mark Struberg added a comment -

There was a similar discussion back in early 2006 (related to MWAR-73).
Imho, there are 3 different situations which may occur:

1.) We get a WAR file as a dependency which is not built with maven and contains all needed dependencies in WEB-INF/lib.
In this case, we must not evaluate and use the transitive dependencies we get from this WAR (usually this WAR will not have transitive dependencies at all)
This is the current behavior of the maven-war-plugin

2.) We get a WAR file as a dependency which is built with maven and does not contain transitive dependencies in WEB-INF/lib.
So we could easily take all transitive dependencies and tie them together in the freshly packaged WEB-INF/lib

3.) A mixture between 1.) and 2.) We get a WAR file as a dependency which is built with maven and contains all needed dependencies in WEB-INF/lib
In this case, there should be a switch to enable transitive dependency resolution and automatically ignoring all jars in WEB-INF/lib which fits any of the dependencies (otherwise we would end up having different versions of the same jar in WEB-INF/lib).
If we find any depending WAR having an attached classes artifact (as of this Jira), we should skip the WEB-INF/classes of those WARs in the war:overlay

Show
Mark Struberg added a comment - There was a similar discussion back in early 2006 (related to MWAR-73 ). Imho, there are 3 different situations which may occur: 1.) We get a WAR file as a dependency which is not built with maven and contains all needed dependencies in WEB-INF/lib. In this case, we must not evaluate and use the transitive dependencies we get from this WAR (usually this WAR will not have transitive dependencies at all) This is the current behavior of the maven-war-plugin 2.) We get a WAR file as a dependency which is built with maven and does not contain transitive dependencies in WEB-INF/lib. So we could easily take all transitive dependencies and tie them together in the freshly packaged WEB-INF/lib 3.) A mixture between 1.) and 2.) We get a WAR file as a dependency which is built with maven and contains all needed dependencies in WEB-INF/lib In this case, there should be a switch to enable transitive dependency resolution and automatically ignoring all jars in WEB-INF/lib which fits any of the dependencies (otherwise we would end up having different versions of the same jar in WEB-INF/lib). If we find any depending WAR having an attached classes artifact (as of this Jira), we should skip the WEB-INF/classes of those WARs in the war:overlay

People

  • Assignee:
    Stéphane Nicoll
    Reporter:
    Stéphane Nicoll
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: