[
http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231959#action_231959
]
Dennis Lundberg commented on MWAR-215:
--------------------------------------
Sure, we can do it like that and make sure to document the new behavior
properly.
> class file JAR inconsistency (archiveClasses and attachClasses options)
> -----------------------------------------------------------------------
>
> Key: MWAR-215
> URL: http://jira.codehaus.org/browse/MWAR-215
> Project: Maven 2.x WAR Plugin
> Issue Type: Improvement
> Affects Versions: 2.1-beta-1
> Reporter: Neeme Praks
> Attachments: maven-WAR-plugin-classes.patch
>
>
> Copy-paste from
> http://article.gmane.org/gmane.comp.jakarta.turbine.maven.devel/94789
> {quote}
> I have a couple of issues with the current WAR plugin and the way it
> packages class files in JAR files (archiveClasses and attachClasses
> configuration options), as these two options work independently of each
> other:
> * archiveClasses moves all class files (and related resources) from
> "classes" directory to JAR file inside WEB-INF/lib directory
> * attachClasses creates a new JAR file in "target" directory from same
> set of files and attaches it to the Maven project with some qualifier
> (by default it uses "classes" qualifier)
> When we deploy artifacts to Maven repository, this results in two
> different JAR files being deployed: one inside WAR and the other
> separate from WAR.
> Problems with this approach:
> * two different JAR files with different MD5/SHA1 checksums.
> * the naming convention for these two JAR files is different
> These issues really start to snag you when you need to perform updates
> after the initial deploy of the WAR. Consider the following scenario:
> * development team hands WAR artifact over to deployment team for deployment
> * development team needs to give an update to the webapp code (the
> dependencies have not changed). One approach is to give the whole WAR
> again, but a more reasonable approach would be to give only JAR file, as
> it contains all the changes and dependent JARs have not changed.
> Whole-WAR-approach becomes especially problematic, when the update needs
> to be uploaded over slow network links and you are in a hurry. However,
> giving only JAR file presents us with some problems:
> # there is no easy way to check the currently deployed webapp JAR
> version, as the checksum of the embedded JAR file does not match any
> other JAR file in the Maven repository.
> # as the naming convention differs, it is going to confuse the
> deployment team
> Solution to this mess? Unify the way "archiveClasses" and
> "attachClasses" functionalities work, so they would operate on the same
> JAR file. The way this would work:
> * if "archiveClasses" option is specified, it moves all class files to
> JAR file inside WEB-INF/lib directory (same as before). It would use the
> same naming convention as regular Maven JAR artifacts, with some qualifier.
> * if "attachClasses" option is specified, it attaches that same JAR
> file (as created in previous point) to the Maven project.
> * if "attachClasses" is specified, but no "archiveClasses" - nothing
> happens. Or maybe we should then implicitly turn on also the
> "archiveClasses" option?
> This has some implications for backwards compatibility:
> * naming convention of the embedded JAR file is changed
> * the attached JAR file is no longer created in the "target"
> directory, next to the WAR file (it is now attached directly from
> WEB-INF/lib directory)
> {quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
