You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Neeme Praks (JIRA)" <ji...@codehaus.org> on 2010/01/11 17:04:55 UTC
[jira] Created: (MWAR-215) class file JAR inconsistency
(archiveClasses and attachClasses options)
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
[jira] Commented: (MWAR-215) class file JAR inconsistency
(archiveClasses and attachClasses options)
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206455#action_206455 ]
Stephane Nicoll commented on MWAR-215:
--------------------------------------
Exactly what I said on the dev list.
> 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
[jira] Commented: (MWAR-215) class file JAR inconsistency
(archiveClasses and attachClasses options)
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206454#action_206454 ]
Jason van Zyl commented on MWAR-215:
------------------------------------
What are you plans to preserve backward compatibility? We are taking the same approach with plugins that we are with the Maven 3.x core. You must provide backward compatibility with a path to use the new features. It's unlikely this will be accepted if backward compatibility is not considered.
> 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
[jira] Commented: (MWAR-215) class file JAR inconsistency
(archiveClasses and attachClasses options)
Posted by "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
[jira] Commented: (MWAR-215) class file JAR inconsistency
(archiveClasses and attachClasses options)
Posted by "Neeme Praks (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=206569#action_206569 ]
Neeme Praks commented on MWAR-215:
----------------------------------
I can rework the patch, I just need to know, what the behavior should be:
# 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)
# 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?
> 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
[jira] Commented: (MWAR-215) class file JAR inconsistency
(archiveClasses and attachClasses options)
Posted by "Stephane Nicoll (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MWAR-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=231755#action_231755 ]
Stephane Nicoll commented on MWAR-215:
--------------------------------------
Think at it again, the backward compatibility issue is limited. What we could do is allow users to provide (optionally) the name of the embedded jar. As for the location of the file either we create it at the same location and copy it to WEB-INF/lib or we don't but it would only affect custom scripts relying on that specific location. If they do, these are probably old scripts before attachClasses came out so it's a good reason to upgrade.
> 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
[jira] Commented: (MWAR-215) class file JAR inconsistency
(archiveClasses and attachClasses options)
Posted by "Dennis Lundberg (JIRA)" <ji...@codehaus.org>.
[ 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