class file JAR inconsistency (archiveClasses and attachClasses options)

Copy-paste from http://article.gmane.org/gmane.comp.jakarta.turbine.maven.devel/94789

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:

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