[jira] Commented: (MWAR-215) class file JAR inconsistency (archiveClasses and attachClasses options)

["Dennis Lundberg (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231722#action_231722 ] 

Dennis Lundberg commented on MWAR-215:
--------------------------------------

Usually when we change the behavior of a feature, the old behavior is the default. If someone wants the new behavior the need to change their configuration. That way we maintain backwards compatibility. So option 2 is what we want.

> 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