You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Neeme Praks <ne...@apache.org> on 2010/01/05 13:48:35 UTC
WAR plugin and class file handling (archiveClasses and attachClasses
options)
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: WAR plugin and class file handling (archiveClasses and attachClasses
options)
Posted by Neeme Praks <ne...@apache.org>.
Ok, I'm on vacation next week, but when I get back in the beginning of
Feb, I will check back here to see if you have reached some conclusion
about the best approach to take.
Thanks,
Neeme
Stephane Nicoll wrote:
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: WAR plugin and class file handling (archiveClasses and attachClasses options)
Posted by Jörg Schaible <jo...@gmx.de>.
Stephane Nicoll wrote at Dienstag, 19. Januar 2010 08:49:
> 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.
Actually it is not of much interest how the jar was named, because it was
not used as attached artifact anyway and could therefore not be addressed as
dependency on its own. The important point was always that it's in the WEB-
INF/lib and the WEB-INF/classes folder is empty. Backward compatibility is
not tied to the jars name.
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: WAR plugin and class file handling (archiveClasses and
attachClasses options)
Posted by Stephane Nicoll <st...@gmail.com>.
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-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ----------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck" -- S.Yegge
Re: WAR plugin and class file handling (archiveClasses and attachClasses options)
Posted by Jason van Zyl <ja...@sonatype.com>.
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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: WAR plugin and class file handling (archiveClasses and attachClasses
options)
Posted by Neeme Praks <ne...@apache.org>.
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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: WAR plugin and class file handling (archiveClasses and attachClasses
options)
Posted by Neeme Praks <ne...@apache.org>.
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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: WAR plugin and class file handling (archiveClasses and
attachClasses options)
Posted by Stephane Nicoll <st...@gmail.com>.
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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
Large Systems Suck: This rule is 100% transitive. If you build one, you
suck" -- S.Yegge
Re: WAR plugin and class file handling (archiveClasses and attachClasses
options)
Posted by Neeme Praks <ne...@apache.org>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org