The old behavior can be re-worked in a way it is mostly backward compatible. Regarding the naming issues, we can change it in a way the bundled jar file follows the same convention as the "attached" jar file (this is purely automated so it shouldn't make a single difference unless people are hacking the overlay by excluding the library afterwards). Regarding the signature issue, creating a single jar if both options are set is not a big deal either.
There are a set of pending issues in the war plugin that really should be addressed. I'll try to work on that over the week-end. Thanks, S. On Tue, Jan 19, 2010 at 2:09 AM, Jason van Zyl <ja...@sonatype.com> wrote: > I honestly don't have time to look right now, but I would be fine with 2 > provided there were tests. You can't break the old behavior even if you > think it's wrong. Document it, let people try it and if folks agree we can > make it the default in the next major release. > > On 2010-01-18, at 8:35 AM, Neeme Praks wrote: > > > I wrote the following comment in JIRA, but there is no response, so I > will send it also here. > > > > --- quote --- > > I can rework the patch, I just need to know, what the behavior should be: > > 1. by default turn on the consistent behavior (as the old behavior seems > quite broken to me) and the user can enable the old behavior with some flag > (e.g. legacyStyleClassesJar=true) > > 2. by default leave the old behavior and the user can enable the new > behavior with some flag (e.g. consistentClassesJar=true) > > > > I personally prefer the first approach, but you know better. Also, what > should be the configuration option name, to switch between the new and old > behavior? > > --- /quote --- > > http://jira.codehaus.org/browse/MWAR-215#action_206569 > > > > Can Stephane or Jason respond to this, please? > > > > Rgds, > > Neeme > > > > Neeme Praks wrote: > >> Thanks, created issue: > >> http://jira.codehaus.org/browse/MWAR-215 > >> Stephane Nicoll wrote: > >>> Please create a Jira issue[1] if none has been created already and > attach > >>> your patch. > >>> > >>> The inconsistency is coming from the way those settings were > implemented and > >>> to preserve backward compatibility. The checksum issue was overlooked > truth > >>> be told. > >>> > >>> Thanks, > >>> Stéphane > >>> > >>> [1] http://jira.codehaus.org/browse/MWAR > >>> > >>> On Mon, Jan 11, 2010 at 12:57 PM, Neeme Praks <ne...@apache.org> > wrote: > >>> > >>>> Hi again, > >>>> > >>>> It's now been 6 days since I wrote this e-mail and no response so far. > Does > >>>> anybody care about the WAR plugin or is it homeless and abandoned? :-P > >>>> > >>>> Or, maybe someone can form an opinion, based on some sort of gut > feeling or > >>>> some best-practice for Maven plugins? > >>>> > >>>> I would love to get my patches accepted to WAR plugin (with > adaptations, if > >>>> needed), but the current feedback is not too encouraging. > >>>> > >>>> Rgds, > >>>> Neeme > >>>> > >>>> > >>>> Neeme Praks wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> 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) > >>>>> > >>>>> I have patched the WAR plugin to have this behavior and I'm looking > for > >>>>> feedback. Is this behavior OK or should it be more backwards > compatible? If > >>>>> it should be more backwards compatible, then how? New configuration > option? > >>>>> If this behavior is OK, then how do I proceed? File a new JIRA issue, > with > >>>>> patches? > >>>>> > >>>>> Rgds, > >>>>> Neeme > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>>> > >>> > >>> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Large Systems Suck: This rule is 100% transitive. If you build one, you suck" -- S.Yegge
