[jira] Updated: (MRRESOURCES-36) ${project.build.sourceEncoding} not honoured.
[
http://jira.codehaus.org/browse/MRRESOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MRRESOURCES-36:
-
Attachment: MRRESOURCES-36
New sourceEncoding parameter and updated ProcessRemoteResourcesMojo.java to
honour source encodings.
> ${project.build.sourceEncoding} not honoured.
> -
>
> Key: MRRESOURCES-36
> URL: http://jira.codehaus.org/browse/MRRESOURCES-36
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.0-alpha-1, 1.0-alpha-2, 1.0-alpha-3, 1.0-alpha-4,
> 1.0-alpha-5, 1.0-alpha-6, 1.0-beta-2, 1.0
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_07
> OS name: "linux" version: "2.6.27.6-workstation" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Priority: Blocker
> Attachments: MRRESOURCES-36
>
>
> Velocity has its own default encoding (ISO-8859-1) when reading templates and
> does not honour the current environment setting. Also the plugin ignores any
> source encoding which leads to encoding issues for any non-ASCII resources.
> The attached patch adds a new mojo parameter sourceEncoding which defaults to
> ${project.build.sourceEncoding} and makes copying and appending to resources
> encoding aware.
--
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] Updated: (MSHARED-84) dependency:tree fails to show all dependencies
[ http://jira.codehaus.org/browse/MSHARED-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaran Nilsen updated MSHARED-84: Attachment: minimal-reproduce-pom.xml > dependency:tree fails to show all dependencies > -- > > Key: MSHARED-84 > URL: http://jira.codehaus.org/browse/MSHARED-84 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree > Environment: Linux (Ubuntu 8.10), i386, java version "1.6.0_10", > Java(TM) SE Runtime Environment (build 1.6.0_10-b33), Java HotSpot(TM) Server > VM (build 11.0-b15, mixed mode), Maven 2.0.9 >Reporter: Jaran Nilsen >Priority: Minor > Attachments: castor-1.1.1.pom, ijcommons-distribution-pom.xml, > minimal-reproduce-pom.xml, original-problem-pom.xml > > > After strugling with xerces 1.4.0 sneaking onto my classpath whenever I ran > mvn eclipse:eclipse I was asked to submit the minimal pom which recreates the > problem. > The dependency in my original project which caused the problem is an artifact > developed by us, which has a dependency to Castor 1.1.1. Castor has a direct > dependency to xerces 1.4.0 which is visible when running dependency:tree on > the ijcommons-distribution project (which is our local artifact). The problem > arises when we run dependency:tree on the initial project, which has a > dependency to ijcommons-distribution - then the dependency to castor and > xerces is never shown, even if xerces is included on the classpath. > Attached is the 3 poms I used to produce the problem. > "mvn dependency:tree | grep xerces" on the project using > "original-problem-pom.xml", gives the following output: > [INFO] | | +- xerces:xmlParserAPIs:jar:2.6.2:compile > [INFO] | | \- xerces:xercesImpl:jar:2.6.2:compile > [INFO] | \- xerces:dom3-xml-apis:jar:1.0:compile > "mvn dependency:tree" on the project using "ijcommons-distribution-pom.xml", > gives the following output: > [INFO] [dependency:tree] > [INFO] no.integrasco.commons:ijcommons-distribution:jar:0.5-SNAPSHOT > [INFO] +- junit:junit:jar:4.4:test > [INFO] +- ch.ethz.ganymed:ganymed-ssh2:jar:build210:compile > [INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile > [INFO] | \- commons-codec:commons-codec:jar:1.2:compile > [INFO] +- org.codehaus.castor:castor:jar:1.1.1:compile > [INFO] | +- cglib:cglib-full:jar:2.0.2:compile > [INFO] | +- javax.transaction:jta:jar:1.0.1B:compile > [INFO] | \- xerces:xerces:jar:1.4.0:compile > [INFO] +- commons-logging:commons-logging:jar:1.1.1:compile > [INFO] \- log4j:log4j:jar:1.2.14:test (scope not updated to compile) > By adding every single dependency of original-problem-pom.xml to > minimal-reproduce-pom.xml I confirmed that ijcommons-distribution.xml was the > only dependency adding xerces 1.4.0 to the classpath. > To my understanding xerces-1.4.0 should then also appear on the classpath of > the project using original-problem-pom.xml? > The POM of Castor version 1.1.1 is also attached. -- 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: (MAVENUPLOAD-2271) "net.objectlab.kit.datecalc","mavens...@shell.sourceforge.net:/home/groups/o/ob/objectlabkit/htdocs/m2-repo","rsync_ssh","Marcin Jekot","mar...@users.sourceforge.n
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156220#action_156220 ] Benoit Xhenseval commented on MAVENUPLOAD-2271: --- Hi I'm the owner of objectlab.net (check the whois records), I am also one of the developer on the ObjectLab Kit project. We do not have a public website for this domain. Marcin Jekot and any developer of ObjectLab Kit are authorised to publish under net.objectllab Thanks for checking this, I trust that this resolves the current situation. Kind regards Benoit Xhenseval > "net.objectlab.kit.datecalc","[EMAIL > PROTECTED]:/home/groups/o/ob/objectlabkit/htdocs/m2-repo","rsync_ssh","Marcin > Jekot","[EMAIL PROTECTED]",, > > > Key: MAVENUPLOAD-2271 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2271 > Project: Maven Upload Requests > Issue Type: Task >Reporter: Marcin Jekot > -- 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] Created: (MRRESOURCES-36) ${project.build.sourceEncoding} not honoured.
${project.build.sourceEncoding} not honoured.
-
Key: MRRESOURCES-36
URL: http://jira.codehaus.org/browse/MRRESOURCES-36
Project: Maven 2.x Remote Resources Plugin
Issue Type: New Feature
Affects Versions: 1.0, 1.0-beta-2, 1.0-alpha-6, 1.0-alpha-5, 1.0-alpha-4,
1.0-alpha-3, 1.0-alpha-2, 1.0-alpha-1
Environment: Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "linux" version: "2.6.27.6-workstation" arch: "i386" Family: "unix"
Reporter: Christian Schulte
Priority: Blocker
Velocity has its own default encoding (ISO-8859-1) when reading templates and
does not honour the current environment setting. Also the plugin ignores any
source encoding which leads to encoding issues for any non-ASCII resources. The
attached patch adds a new mojo parameter sourceEncoding which defaults to
${project.build.sourceEncoding} and makes copying and appending to resources
encoding aware.
--
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: (MAVENUPLOAD-2286) nez sync rule from sourceforge project
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156210#action_156210 ] Christophe Lallement commented on MAVENUPLOAD-2286: --- OK, sorry for the incomprehension, find below the right groupId "net.java","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL PROTECTED]",, > nez sync rule from sourceforge project > -- > > Key: MAVENUPLOAD-2286 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2286 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.jvyaml","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","ouaibsky.free.fr",, -- 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: (MRRESOURCES-36) ${project.build.sourceEncoding} not honoured.
[
http://jira.codehaus.org/browse/MRRESOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156222#action_156222
]
Christian Schulte commented on MRRESOURCES-36:
--
Correct solution would be to make the sourceEncoding an attribute of the
RemoteResourcesBundle model so that a bundle created with, for example, UTF-8
can be used in a project using a different encoding. See the second patched
attached.
> ${project.build.sourceEncoding} not honoured.
> -
>
> Key: MRRESOURCES-36
> URL: http://jira.codehaus.org/browse/MRRESOURCES-36
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.0-alpha-1, 1.0-alpha-2, 1.0-alpha-3, 1.0-alpha-4,
> 1.0-alpha-5, 1.0-alpha-6, 1.0-beta-2, 1.0
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_07
> OS name: "linux" version: "2.6.27.6-workstation" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Priority: Blocker
> Attachments: MRRESOURCES-36
>
>
> Velocity has its own default encoding (ISO-8859-1) when reading templates and
> does not honour the current environment setting. Also the plugin ignores any
> source encoding which leads to encoding issues for any non-ASCII resources.
> The attached patch adds a new mojo parameter sourceEncoding which defaults to
> ${project.build.sourceEncoding} and makes copying and appending to resources
> encoding aware.
--
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] Updated: (MRRESOURCES-36) ${project.build.sourceEncoding} not honoured.
[
http://jira.codehaus.org/browse/MRRESOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MRRESOURCES-36:
-
Attachment: MRRESOURCES-36-2
Patch additionally adding a sourceEncoding attribute to the
remote-resources.mdo model. When creating a bundle the source encoding of the
resources is stored along the remote-resources.xml document. When processing
such a bundle that encoding is used for reading the remote resources.
Additionally, when processing a bundle, all resources will be written using
${project.build.sourceEncoding}, if specified.
> ${project.build.sourceEncoding} not honoured.
> -
>
> Key: MRRESOURCES-36
> URL: http://jira.codehaus.org/browse/MRRESOURCES-36
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.0-alpha-1, 1.0-alpha-2, 1.0-alpha-3, 1.0-alpha-4,
> 1.0-alpha-5, 1.0-alpha-6, 1.0-beta-2, 1.0
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_07
> OS name: "linux" version: "2.6.27.6-workstation" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Priority: Blocker
> Attachments: MRRESOURCES-36, MRRESOURCES-36-2
>
>
> Velocity has its own default encoding (ISO-8859-1) when reading templates and
> does not honour the current environment setting. Also the plugin ignores any
> source encoding which leads to encoding issues for any non-ASCII resources.
> The attached patch adds a new mojo parameter sourceEncoding which defaults to
> ${project.build.sourceEncoding} and makes copying and appending to resources
> encoding aware.
--
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: (MAVENUPLOAD-2250) Upload bundle for opensymhony.org's quartz scheduler
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156240#action_156240 ] David J. M. Karlsen commented on MAVENUPLOAD-2250: -- Do you suggest I change it back to the same groups as today - or create relocation? > Upload bundle for opensymhony.org's quartz scheduler > > > Key: MAVENUPLOAD-2250 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2250 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: David J. M. Karlsen > Attachments: org.opensymphony.quartz.161.zip > > > Bundle attached as file upload -- 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] Created: (MNG-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as -SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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] Updated: (MRRESOURCES-36) ${project.build.sourceEncoding} not honoured.
[
http://jira.codehaus.org/browse/MRRESOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Schulte updated MRRESOURCES-36:
-
Attachment: MRRESOURCES-36-3.patch
MRRESOURCES-36-2 was incorrect.
> ${project.build.sourceEncoding} not honoured.
> -
>
> Key: MRRESOURCES-36
> URL: http://jira.codehaus.org/browse/MRRESOURCES-36
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: New Feature
>Affects Versions: 1.0-alpha-1, 1.0-alpha-2, 1.0-alpha-3, 1.0-alpha-4,
> 1.0-alpha-5, 1.0-alpha-6, 1.0-beta-2, 1.0
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_07
> OS name: "linux" version: "2.6.27.6-workstation" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Priority: Blocker
> Attachments: MRRESOURCES-36, MRRESOURCES-36-2, MRRESOURCES-36-3.patch
>
>
> Velocity has its own default encoding (ISO-8859-1) when reading templates and
> does not honour the current environment setting. Also the plugin ignores any
> source encoding which leads to encoding issues for any non-ASCII resources.
> The attached patch adds a new mojo parameter sourceEncoding which defaults to
> ${project.build.sourceEncoding} and makes copying and appending to resources
> encoding aware.
--
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: (MAVENUPLOAD-2287) New opensource library (swing) to sync with central repository: JBusyComponent
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156211#action_156211 ] Christophe Lallement commented on MAVENUPLOAD-2287: --- OK, sorry for the incomprehension, find below the right groupId "com.google","[EMAIL PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL PROTECTED]",, > New opensource library (swing) to sync with central repository: JBusyComponent > -- > > Key: MAVENUPLOAD-2287 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2287 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Christophe Lallement > > "org.divxdede","[EMAIL > PROTECTED]:/home/users/o/ou/ouaibsky/maven/m2repo","rsync_ssh","Ouaibsky","[EMAIL > PROTECTED]",, -- 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] Created: (MSHARED-84) dependency:tree fails to show all dependencies
dependency:tree fails to show all dependencies -- Key: MSHARED-84 URL: http://jira.codehaus.org/browse/MSHARED-84 Project: Maven Shared Components Issue Type: Bug Components: maven-dependency-tree Environment: Linux (Ubuntu 8.10), i386, java version "1.6.0_10", Java(TM) SE Runtime Environment (build 1.6.0_10-b33), Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode), Maven 2.0.9 Reporter: Jaran Nilsen Priority: Minor Attachments: castor-1.1.1.pom, ijcommons-distribution-pom.xml, original-problem-pom.xml After strugling with xerces 1.4.0 sneaking onto my classpath whenever I ran mvn eclipse:eclipse I was asked to submit the minimal pom which recreates the problem. The dependency in my original project which caused the problem is an artifact developed by us, which has a dependency to Castor 1.1.1. Castor has a direct dependency to xerces 1.4.0 which is visible when running dependency:tree on the ijcommons-distribution project (which is our local artifact). The problem arises when we run dependency:tree on the initial project, which has a dependency to ijcommons-distribution - then the dependency to castor and xerces is never shown, even if xerces is included on the classpath. Attached is the 3 poms I used to produce the problem. "mvn dependency:tree | grep xerces" on the project using "original-problem-pom.xml", gives the following output: [INFO] | | +- xerces:xmlParserAPIs:jar:2.6.2:compile [INFO] | | \- xerces:xercesImpl:jar:2.6.2:compile [INFO] | \- xerces:dom3-xml-apis:jar:1.0:compile "mvn dependency:tree" on the project using "ijcommons-distribution-pom.xml", gives the following output: [INFO] [dependency:tree] [INFO] no.integrasco.commons:ijcommons-distribution:jar:0.5-SNAPSHOT [INFO] +- junit:junit:jar:4.4:test [INFO] +- ch.ethz.ganymed:ganymed-ssh2:jar:build210:compile [INFO] +- commons-httpclient:commons-httpclient:jar:3.1:compile [INFO] | \- commons-codec:commons-codec:jar:1.2:compile [INFO] +- org.codehaus.castor:castor:jar:1.1.1:compile [INFO] | +- cglib:cglib-full:jar:2.0.2:compile [INFO] | +- javax.transaction:jta:jar:1.0.1B:compile [INFO] | \- xerces:xerces:jar:1.4.0:compile [INFO] +- commons-logging:commons-logging:jar:1.1.1:compile [INFO] \- log4j:log4j:jar:1.2.14:test (scope not updated to compile) By adding every single dependency of original-problem-pom.xml to minimal-reproduce-pom.xml I confirmed that ijcommons-distribution.xml was the only dependency adding xerces 1.4.0 to the classpath. To my understanding xerces-1.4.0 should then also appear on the classpath of the project using original-problem-pom.xml? The POM of Castor version 1.1.1 is also attached. -- 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: (MNG-3880) package phase devided into more specific phases
[
http://jira.codehaus.org/browse/MNG-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156273#action_156273
]
Paul Benedict commented on MNG-3880:
I don't think the solution is to have more phases. What about simply allowing a
pre or post chain of behavior on each phase?
> package phase devided into more specific phases
> ---
>
> Key: MNG-3880
> URL: http://jira.codehaus.org/browse/MNG-3880
> Project: Maven 2
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.9
>Reporter: Anders Kr. Andersen
>
> Currently the command mvn package will produce a zipped result file like
> xx.war or xxx.jar
> So I belive it must always be...
> I suggest that the phase is devided into multiple pre phases like:
> package-copy --> copies files to target/xxx-war (the prezipped
> directory structure)
> package-manifest --> generates the manifest to be packed into the zipped
> result
> package-maven --> generates the maven META-INF/maven files
> package-compress --> zips the target/xxx-war into the file target/xxx-war.war
> The reasoning for these suggestions is that I had a situation where I had to
> add more files into the unpacked result.
> This ended up more jobbi than I had thought because I had to manage the
> manifest, maven and compress as well.
> Best regards
> /Anders
> PS: My sample is a Weblogic Integration Problem with task
> weblogic.ant.taskdefs.build.AnnotationManifestTask
> The task will go through all classes and jars in the result and make a kind
> of index and place the index into META-INF.
> My code got ugly
> I had to run the task yes, ofcause..
> But I had to do much more than I hoped.
> 1) MANIFEST.MF (maven generates it under the final ZIP process) I had to
> steal it from mavens ZIP
> 2) META-INF/maven/ (Maven also generates it under the final ZIP process).
> I had to steal this as well
> 3) the package phase will do the compress as well. I had to zip again !!!
> (Maybe I could just update existing zip?, but i did not choose that)
> If I had multiple steps in the package phase I could have made this
> "customer-plugin" easier...
> Here is the ugly code
> searchClasspathRef="annotation.manifest.search.path"
> classpathRef="annotation.manifest.class.path"
> verbose="false"
> version=""
> stagingDir="${project.build.directory}/manifest-work"/>
>
> dest="${staging.dir}">
>
>
>
>
>
>
> whenempty="create">
>
>
>
--
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] Created: (MNGSITE-73) The example for specifying the MAVEN_OPTS is incorrect for the Unix installation instructions
The example for specifying the MAVEN_OPTS is incorrect for the Unix installation instructions - Key: MNGSITE-73 URL: http://jira.codehaus.org/browse/MNGSITE-73 Project: Maven 2 Project Web Site Issue Type: Bug Reporter: umesh balasubramaniam Priority: Minor The step 4 of the installation documentation says: Optional: Add the MAVEN_OPTS environment variable to specify JVM properties, e.g. export MAVEN_OPTS=-Xms256m -Xmx512m. This environment variable can be used to supply extra options to Maven. This should be e.g. export MAVEN_OPTS="-Xms256m -Xmx512m" -- 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] Created: (MNG-3886) Ordering of goals from a plugin execution is not respected if plugin management applies
Ordering of goals from a plugin execution is not respected if plugin management
applies
---
Key: MNG-3886
URL: http://jira.codehaus.org/browse/MNG-3886
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
Priority: Minor
For a POM snippet like
{code:xml}
test
validate
one
two
{code}
the effective execution order of the specified goals is either [one, two] or
[two, one] depending on the existence of {{}} for the plugin
in question.
--
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] Created: (MNG-3887) Order of plugin executions within same phase does not match POM order when plugin management is used
Order of plugin executions within same phase does not match POM order when
plugin management is used
Key: MNG-3887
URL: http://jira.codehaus.org/browse/MNG-3887
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 3.0-alpha-1
Reporter: Benjamin Bentmann
For a POM snippet like
{code:xml}
test-1
validate
one
test-2
validate
two
{code}
the effective goal execution order is either [one, two] or [two, one] depending
on the usage of {{}} for the plugin in question.
--
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: (MAVENUPLOAD-2272) upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156321#action_156321 ] Francois Fernandes commented on MAVENUPLOAD-2272: - could you please tell me what is wrong with the package? > upload > --- > > Key: MAVENUPLOAD-2272 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2272 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Francois Fernandes > > another version of the svnkit library. -- 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: (MAVENUPLOAD-2189) Please setup synchronization for dbfit
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156338#action_156338 ] Pål Brattberg commented on MAVENUPLOAD-2189: It's an independent project, but it's hosted on fitnesse.info (which is like an active version of fitnesse.org sort of). I could change it to info.fitnesse.dbfit if you'd like? "info.fitnesse.dbfit","[EMAIL PROTECTED]://home/groups/d/db/dbfit/htdocs/m2repo/releases","rsync_ssh","Pal Brattberg","[EMAIL PROTECTED]",, > Please setup synchronization for dbfit > -- > > Key: MAVENUPLOAD-2189 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2189 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Pål Brattberg >Assignee: Carlos Sanchez > > "dbfit","[EMAIL > PROTECTED]://home/groups/d/db/dbfit/htdocs/m2repo/releases","rsync_ssh","Pal > Brattberg","[EMAIL PROTECTED]",, -- 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: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156340#action_156340 ] David J. M. Karlsen commented on MRELEASE-261: -- Any news on this. Not being able to release a flat structure is a real PITA - and having nearly empty pom.xml's around just to satisfy maven is really bad publicity... > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: linux / maven2 / svn >Reporter: [EMAIL PROTECTED] > Attachments: PrepareReleaseMojo.patch > > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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] Created: (MASSEMBLY-372) Maven with attached assembies and manually invoked in one step
Maven with attached assembies and manually invoked in one step
--
Key: MASSEMBLY-372
URL: http://jira.codehaus.org/browse/MASSEMBLY-372
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Environment: XP SP2, Maven 2.0.9, JDK 6 u10
Reporter: Michael Osipov
Attachments: error.log, testproject.zip
This is what I tried to realize:
I have a very simple project. I wanted to create besides the regular jar and a
jar with depencies. After both have been created, I wanted to create an
assembly along with some other fies.
What I did:
I attached assembly:attached to phase package with descriptorRef
"jar-with-depencies" and configured the assembly a bin assembly which will be
invoked manually.
Well, it failed. According th Benjamin Bentmann on IRC, he advised me to create
a profile to build the bin assembly. Guess what? It works if invoke:
{noformat}
$mvn package
$mvn assembly:assembly -Pbin-assembly
{noformat}
Well, I want run it rather in one step: mvn clean package assembly:assembly
-Pbin-assembly. This fails with the attached log above. I also attached my
project.
I expect during the one call that my package, attachment and bin assembly will
be build as expected.
The log says, the descriptors are messed up.
--
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: (MASSEMBLY-372) Maven with attached assembies and manually invoked in one step
[
http://jira.codehaus.org/browse/MASSEMBLY-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156344#action_156344
]
Michael Osipov commented on MASSEMBLY-372:
--
You may even move the profile configuration back to the plugin config and the
result remains the same.
> Maven with attached assembies and manually invoked in one step
> --
>
> Key: MASSEMBLY-372
> URL: http://jira.codehaus.org/browse/MASSEMBLY-372
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: XP SP2, Maven 2.0.9, JDK 6 u10
>Reporter: Michael Osipov
> Attachments: error.log, testproject.zip
>
>
> This is what I tried to realize:
> I have a very simple project. I wanted to create besides the regular jar and
> a jar with depencies. After both have been created, I wanted to create an
> assembly along with some other fies.
> What I did:
> I attached assembly:attached to phase package with descriptorRef
> "jar-with-depencies" and configured the assembly a bin assembly which will be
> invoked manually.
> Well, it failed. According th Benjamin Bentmann on IRC, he advised me to
> create a profile to build the bin assembly. Guess what? It works if invoke:
> {noformat}
> $mvn package
> $mvn assembly:assembly -Pbin-assembly
> {noformat}
> Well, I want run it rather in one step: mvn clean package assembly:assembly
> -Pbin-assembly. This fails with the attached log above. I also attached my
> project.
> I expect during the one call that my package, attachment and bin assembly
> will be build as expected.
> The log says, the descriptors are messed up.
--
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: (MECLIPSE-331) Allow to use a packaging model to override the packaging defined in the pom
[ http://jira.codehaus.org/browse/MECLIPSE-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156346#action_156346 ] Steve Karlovitz commented on MECLIPSE-331: -- I am having the same issue but with an amp packaging type. Warehouse xxx 1.0-SNAPSHOT 4.0.0 xxx WarehouseModule amp WarehouseModule 1.0 http://maven.apache.org org.apache.maven.plugins maven-eclipse-plugin 2.5 true false true D:\SDE-AssetLibrary\workspace jar > Allow to use a packaging model to override the packaging defined in the pom > --- > > Key: MECLIPSE-331 > URL: http://jira.codehaus.org/browse/MECLIPSE-331 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Arnaud Heritier >Assignee: Arnaud Heritier > Fix For: 2.5 > > > It can be useful to be able to define the packaging to use to generate > eclipse settings. > In the case of a customized packaging (a grails application for ex) you would > like to use a war packaging model to be able to reuse WTP feature, but it is > actually impossible because the plugin reads directly the pom packaging (and > not an intermediate configuration variable). -- 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] Issue Comment Edited: (MASSEMBLY-372) Maven with attached assembies and manually invoked in one step
[
http://jira.codehaus.org/browse/MASSEMBLY-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156344#action_156344
]
Michael Osipov edited comment on MASSEMBLY-372 at 12/2/08 1:49 PM:
---
.
was (Author: sgfan):
You may even move the profile configuration back to the plugin config and
the result remains the same.
> Maven with attached assembies and manually invoked in one step
> --
>
> Key: MASSEMBLY-372
> URL: http://jira.codehaus.org/browse/MASSEMBLY-372
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: XP SP2, Maven 2.0.9, JDK 6 u10
>Reporter: Michael Osipov
> Attachments: error.log, testproject.zip
>
>
> This is what I tried to realize:
> I have a very simple project. I wanted to create besides the regular jar and
> a jar with depencies. After both have been created, I wanted to create an
> assembly along with some other fies.
> What I did:
> I attached assembly:attached to phase package with descriptorRef
> "jar-with-depencies" and configured the assembly a bin assembly which will be
> invoked manually.
> Well, it failed. According th Benjamin Bentmann on IRC, he advised me to
> create a profile to build the bin assembly. Guess what? It works if invoke:
> {noformat}
> $mvn package
> $mvn assembly:assembly -Pbin-assembly
> {noformat}
> Well, I want run it rather in one step: mvn clean package assembly:assembly
> -Pbin-assembly. This fails with the attached log above. I also attached my
> project.
> I expect during the one call that my package, attachment and bin assembly
> will be build as expected.
> The log says, the descriptors are messed up.
--
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: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[ http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156352#action_156352 ] Yann Albou commented on SCM-262: George, It seems to work on Windows. Yes I agree with you it is overkill. but either we resolve the worst scenario with this overkill solution or we use a lighter solution that doesn't cover all situations Personnally, I prefer the simple solution where we tag from the repository. > scm:tag for subversion tagging from local version of code, not directly from > repository > --- > > Key: SCM-262 > URL: http://jira.codehaus.org/browse/SCM-262 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Reporter: Stephan Heilner > Fix For: future > > > In theory, you shouldn't tag or branch from a local and potentially different > version of the code. From what I can tell, the scm:tag imports your existing > code into a new tag. With subversion, tagging is very lightweight if you do > a 'svn copy trunk_url tag_url'. The way it currently works make sense for > other repositories such as CVS but not for subversion. -- 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: (MNG-3880) package phase devided into more specific phases
[
http://jira.codehaus.org/browse/MNG-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156353#action_156353
]
Anders Kr. Andersen commented on MNG-3880:
--
In this case my problem is that war:war (the package phase) is doing too much
in one "job"
The war:war will 1) copy the sources, classes, jars and resources into the
pre-zipped directory, 2) generate manifest 3) zip the directory.
The Weblogic build-manifests needs the final classes and jars for searching and
make the "index" file.
That is why I want to be able to add functionality to war:war before the
zipping and manifest making takes place.
I want to add my "job" in the mittle of this process, currently after the
"copy" but before generating manifest.
So I'm not sure that a "pre"/"post" chain helps here. Because the problem is
that war:war does too many things.
I feel good about adding more phases because it makes it more precise what
Maven is doing. Once a man told me that "being precise" is a core quality in
software making :-)
> package phase devided into more specific phases
> ---
>
> Key: MNG-3880
> URL: http://jira.codehaus.org/browse/MNG-3880
> Project: Maven 2
> Issue Type: Improvement
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.9
>Reporter: Anders Kr. Andersen
>
> Currently the command mvn package will produce a zipped result file like
> xx.war or xxx.jar
> So I belive it must always be...
> I suggest that the phase is devided into multiple pre phases like:
> package-copy --> copies files to target/xxx-war (the prezipped
> directory structure)
> package-manifest --> generates the manifest to be packed into the zipped
> result
> package-maven --> generates the maven META-INF/maven files
> package-compress --> zips the target/xxx-war into the file target/xxx-war.war
> The reasoning for these suggestions is that I had a situation where I had to
> add more files into the unpacked result.
> This ended up more jobbi than I had thought because I had to manage the
> manifest, maven and compress as well.
> Best regards
> /Anders
> PS: My sample is a Weblogic Integration Problem with task
> weblogic.ant.taskdefs.build.AnnotationManifestTask
> The task will go through all classes and jars in the result and make a kind
> of index and place the index into META-INF.
> My code got ugly
> I had to run the task yes, ofcause..
> But I had to do much more than I hoped.
> 1) MANIFEST.MF (maven generates it under the final ZIP process) I had to
> steal it from mavens ZIP
> 2) META-INF/maven/ (Maven also generates it under the final ZIP process).
> I had to steal this as well
> 3) the package phase will do the compress as well. I had to zip again !!!
> (Maybe I could just update existing zip?, but i did not choose that)
> If I had multiple steps in the package phase I could have made this
> "customer-plugin" easier...
> Here is the ugly code
> searchClasspathRef="annotation.manifest.search.path"
> classpathRef="annotation.manifest.class.path"
> verbose="false"
> version=""
> stagingDir="${project.build.directory}/manifest-work"/>
>
> dest="${staging.dir}">
>
>
>
>
>
>
> whenempty="create">
>
>
>
--
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] Created: (MCOMPILER-86) Certain Java configuration of Compiler Plugin causes ArrayStoreException
Certain Java configuration of Compiler Plugin causes ArrayStoreException Key: MCOMPILER-86 URL: http://jira.codehaus.org/browse/MCOMPILER-86 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Maven 2.0.9, Java 1.6 Reporter: Trevor Harmon Attachments: pom.xml Running "mvn exec:java" on the attached POM causes an ArrayStoreException. -- 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: (MCOMPILER-86) Certain Java configuration of Compiler Plugin causes ArrayStoreException
[ http://jira.codehaus.org/browse/MCOMPILER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156354#action_156354 ] Trevor Harmon commented on MCOMPILER-86: java.lang.ArrayStoreException at java.lang.System.arraycopy(Native Method) at java.util.Arrays.copyOf(Arrays.java:2763) at java.util.ArrayList.toArray(ArrayList.java:305) at org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromConfiguration(ArrayConverter.java:141) at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1282) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:661) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:429) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Certain Java configuration of Compiler Plugin causes ArrayStoreException > > > Key: MCOMPILER-86 > URL: http://jira.codehaus.org/browse/MCOMPILER-86 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Maven 2.0.9, Java 1.6 >Reporter: Trevor Harmon > Attachments: pom.xml > > > Running "mvn exec:java" on the attached POM causes an ArrayStoreException. -- 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: (MCOMPILER-86) Certain Java configuration of Compiler Plugin causes ArrayStoreException
[ http://jira.codehaus.org/browse/MCOMPILER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156355#action_156355 ] Trevor Harmon commented on MCOMPILER-86: I realize that the attached POM shows an invalid configuration for exec:java (the arguments element shouldn't be there), but still, Maven should fail gracefully instead of throwing an exception. > Certain Java configuration of Compiler Plugin causes ArrayStoreException > > > Key: MCOMPILER-86 > URL: http://jira.codehaus.org/browse/MCOMPILER-86 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: Maven 2.0.9, Java 1.6 >Reporter: Trevor Harmon > Attachments: pom.xml > > > Running "mvn exec:java" on the attached POM causes an ArrayStoreException. -- 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] Created: (MJAVADOC-221) test-scoped dependencies sometimes used instead of compile-scoped if group and artifact are the same
test-scoped dependencies sometimes used instead of compile-scoped if group and
artifact are the same
Key: MJAVADOC-221
URL: http://jira.codehaus.org/browse/MJAVADOC-221
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.5
Environment: Maven 2.0.9, WinXP and Redhat Linux
Reporter: Jeff Mills
Priority: Minor
I had a build failing because of unresolved classes, but only in the
javadoc:javadoc goal, not when compiling. Debugging showed that the classpath
excluded some expected compile-scoped dependencies and replaced them with the
test-scoped dependencies that have the same group and artifact IDs but
different classifier ("tests").
We have a few modules for which we use the jar:test-jar goal to package the
unit test code for re-use by other modules. So the dependent modules specify 2
dependencies: group:artifact with compile scope and group:artifact:classifer
with test scope. What I discovered was that this plugin uses the one that is
specified last, regardless of whether its scope is compile or test. IOW, I
fixed my build by moving my test-scoped dependencies to be before the
compile-scoped dependencies.
Example resulting in test jar (moduleA-version-tests.jar) in classpath instead
of the main jar (moduleA-version.jar):
com.company.group
moduleA
compile
com.company.group
moduleA
tests
test
Example resulting in correct classpath:
com.company.group
moduleA
tests
test
com.company.group
moduleA
compile
--
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] Moved: (MNG-3888) Certain Java configuration of Compiler Plugin causes ArrayStoreException
[ http://jira.codehaus.org/browse/MNG-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann moved MCOMPILER-86 to MNG-3888: - Affects Version/s: (was: 2.0.2) 3.0-alpha-1 2.0.9 2.1.0-M1 Complexity: Intermediate Key: MNG-3888 (was: MCOMPILER-86) Project: Maven 2 (was: Maven 2.x Compiler Plugin) > Certain Java configuration of Compiler Plugin causes ArrayStoreException > > > Key: MNG-3888 > URL: http://jira.codehaus.org/browse/MNG-3888 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.0-M1, 2.0.9, 3.0-alpha-1 > Environment: Maven 2.0.9, Java 1.6 >Reporter: Trevor Harmon > Attachments: pom.xml > > > Running "mvn exec:java" on the attached POM causes an ArrayStoreException. -- 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] Updated: (MNG-3888) Configuration of array-typed mojo parameters with type-incompatible elements causes ArrayStoreException
[ http://jira.codehaus.org/browse/MNG-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3888: --- Priority: Minor (was: Major) Summary: Configuration of array-typed mojo parameters with type-incompatible elements causes ArrayStoreException (was: Certain Java configuration of Compiler Plugin causes ArrayStoreException) > Configuration of array-typed mojo parameters with type-incompatible elements > causes ArrayStoreException > --- > > Key: MNG-3888 > URL: http://jira.codehaus.org/browse/MNG-3888 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1 > Environment: Maven 2.0.9, Java 1.6 >Reporter: Trevor Harmon >Priority: Minor > Attachments: pom.xml > > > Running "mvn exec:java" on the attached POM causes an ArrayStoreException. -- 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: (MNG-3888) Configuration of array-typed mojo parameters with type-incompatible elements causes ArrayStoreException
[
http://jira.codehaus.org/browse/MNG-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156370#action_156370
]
Benjamin Bentmann commented on MNG-3888:
The cause is that in the snippet
{code:xml}
{code}
the mojo parameter {{arguments}} is of type {{String[]}} while the
{{}} elements resolves to some custom type.
> Configuration of array-typed mojo parameters with type-incompatible elements
> causes ArrayStoreException
> ---
>
> Key: MNG-3888
> URL: http://jira.codehaus.org/browse/MNG-3888
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
> Environment: Maven 2.0.9, Java 1.6
>Reporter: Trevor Harmon
>Priority: Minor
> Attachments: pom.xml
>
>
> Running "mvn exec:java" on the attached POM causes an ArrayStoreException.
--
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: (MNG-3888) Configuration of array-typed mojo parameters with type-incompatible elements causes ArrayStoreException
[
http://jira.codehaus.org/browse/MNG-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156372#action_156372
]
Trevor Harmon commented on MNG-3888:
But it is perfectly valid to have inside , such as:
{code:xml}
-classpath
{code}
This is a normal use case of the compiler-plugin.
> Configuration of array-typed mojo parameters with type-incompatible elements
> causes ArrayStoreException
> ---
>
> Key: MNG-3888
> URL: http://jira.codehaus.org/browse/MNG-3888
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
> Environment: Maven 2.0.9, Java 1.6
>Reporter: Trevor Harmon
>Priority: Minor
> Attachments: pom.xml
>
>
> Running "mvn exec:java" on the attached POM causes an ArrayStoreException.
--
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] Issue Comment Edited: (MNG-3888) Configuration of array-typed mojo parameters with type-incompatible elements causes ArrayStoreException
[
http://jira.codehaus.org/browse/MNG-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156372#action_156372
]
Trevor Harmon edited comment on MNG-3888 at 12/2/08 3:20 PM:
-
But it is perfectly valid to have inside , such as:
{code:xml}
-classpath
{code}
This is a normal use case of the exec-plugin.
was (Author: vocaro):
But it is perfectly valid to have inside , such as:
{code:xml}
-classpath
{code}
This is a normal use case of the compiler-plugin.
> Configuration of array-typed mojo parameters with type-incompatible elements
> causes ArrayStoreException
> ---
>
> Key: MNG-3888
> URL: http://jira.codehaus.org/browse/MNG-3888
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
> Environment: Maven 2.0.9, Java 1.6
>Reporter: Trevor Harmon
>Priority: Minor
> Attachments: pom.xml
>
>
> Running "mvn exec:java" on the attached POM causes an ArrayStoreException.
--
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: (MNG-3888) Configuration of array-typed mojo parameters with type-incompatible elements causes ArrayStoreException
[
http://jira.codehaus.org/browse/MNG-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156377#action_156377
]
Benjamin Bentmann commented on MNG-3888:
One needs to be a little more specific about which use case is considered. For
the {{exec:exec}} goal, the snippet you gave is valid because internally its
mojo parameter {{arguments}} is of type {{java.util.List}}. However for the
{{exec:java}} mojo, this crashes as you reported because its mojo parameter is
of type {{String[]}}. This is a subtle implementation detail.
bq. [...] compiler-plugin.
Just for the record: The plugin you are using is called Exec Maven Plugin and
is not related to the Maven Compiler Plugin ;-)
> Configuration of array-typed mojo parameters with type-incompatible elements
> causes ArrayStoreException
> ---
>
> Key: MNG-3888
> URL: http://jira.codehaus.org/browse/MNG-3888
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
> Environment: Maven 2.0.9, Java 1.6
>Reporter: Trevor Harmon
>Priority: Minor
> Attachments: pom.xml
>
>
> Running "mvn exec:java" on the attached POM causes an ArrayStoreException.
--
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] Closed: (ARCHETYPE-142) catalog default location problem in CrawlRepositoryMojo
[ http://jira.codehaus.org/browse/ARCHETYPE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphaël Piéroni closed ARCHETYPE-142. - Resolution: Not A Bug This is not a bug as the way to use it is explained in the last comment > catalog default location problem in CrawlRepositoryMojo > --- > > Key: ARCHETYPE-142 > URL: http://jira.codehaus.org/browse/ARCHETYPE-142 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Affects Versions: 2.0-alpha-2 >Reporter: tom nelson > Fix For: 2.0-alpha-5 > > > the default repository location is $HOME/.m2/repository but this is also used > as the the default place to create the new archetype-catalog.xml file. > The archetype-catalog.xml should be created in $HOME/.m2 instead. -- 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: (ARCHETYPE-142) catalog default location problem in CrawlRepositoryMojo
[ http://jira.codehaus.org/browse/ARCHETYPE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156387#action_156387 ] Raphaël Piéroni commented on ARCHETYPE-142: --- > Is this a possibility to change the default location for the local catalog? Yes. There are two methods to do this: 1. mvn archetype:crawl -Dcatalog=/home/username/.m2/archetype-catalog.xml ; mvn archetype:generate -DarchetypeCatalog=local or 2. mvn archetype:crawl ; mvn arhetype:generate -DarchetypeCatalog=file:///home/username/.m2/repository/archetype-catalog.xml > catalog default location problem in CrawlRepositoryMojo > --- > > Key: ARCHETYPE-142 > URL: http://jira.codehaus.org/browse/ARCHETYPE-142 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Affects Versions: 2.0-alpha-2 >Reporter: tom nelson > Fix For: 2.0-alpha-5 > > > the default repository location is $HOME/.m2/repository but this is also used > as the the default place to create the new archetype-catalog.xml file. > The archetype-catalog.xml should be created in $HOME/.m2 instead. -- 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] Closed: (MNGSITE-73) The example for specifying the MAVEN_OPTS is incorrect for the Unix installation instructions
[ http://jira.codehaus.org/browse/MNGSITE-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNGSITE-73. Assignee: Benjamin Bentmann Resolution: Fixed Fixed in [r722638|http://svn.eu.apache.org/viewvc?view=rev&revision=722638]. > The example for specifying the MAVEN_OPTS is incorrect for the Unix > installation instructions > - > > Key: MNGSITE-73 > URL: http://jira.codehaus.org/browse/MNGSITE-73 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: umesh balasubramaniam >Assignee: Benjamin Bentmann >Priority: Minor > > The step 4 of the installation documentation says: Optional: Add the > MAVEN_OPTS environment variable to specify JVM properties, e.g. export > MAVEN_OPTS=-Xms256m -Xmx512m. This environment variable can be used to supply > extra options to Maven. > This should be e.g. export MAVEN_OPTS="-Xms256m -Xmx512m" -- 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] Closed: (ARCHETYPE-110) Maven archetype overwrites parent information
[
http://jira.codehaus.org/browse/ARCHETYPE-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raphaël Piéroni closed ARCHETYPE-110.
-
Resolution: Fixed
Fixed since revision 722648
Thanks to Jason Voegele patch.
> Maven archetype overwrites parent information
> -
>
> Key: ARCHETYPE-110
> URL: http://jira.codehaus.org/browse/ARCHETYPE-110
> Project: Maven Archetype
> Issue Type: Bug
>Reporter: Peter Liljenberg
>Priority: Critical
> Fix For: 2.0-alpha-5
>
> Attachments: ARCHETYPE-110.patch
>
>
> When creating a new archetype that I want to use for my projects I ran into
> some trouble with the created/copied pom.xml.
> The archetype pom.xml (\src\main\resources\archetype-resources\pom.xml) looks
> like this:
>
>
> group
> masterpom
> 1.0
>
> 4.0.0
> group
> ${artifactId}
> 1.0
>
> When I run my archetype it creates a pom.xml that looks like:
>
>
> integration
> group
> 1.0
>
> 4.0.0
> group
> test
> 1.0
>
> Where "integration" is the name of the pom in the folder that I'm running mvn
> archetype:create from.
> Digging into the source we find in DefaultArchetype.java that processTemplate
> is indeed reading the parent pom and overwriting whatever was found in the
> original pom.xml.
> Is this really what we want to achieve? It should be possible to keep the
> parent-pom from the pom.xml in the archetype since it reduces the need for
> all developers to change their newly created pom.xml.
>
> processTemplates
> if ( parentModel != null )
> {
> Parent parent = new Parent();
> parent.setGroupId( parentModel.getGroupId() );
> if ( parent.getGroupId() == null )
> {
> parent.setGroupId( parentModel.getParent().getGroupId() );
> }
> parent.setArtifactId( parentModel.getArtifactId() );
> parent.setVersion( parentModel.getVersion() );
> if ( parent.getVersion() == null )
> {
> parent.setVersion( parentModel.getParent().getVersion() );
> }
> generatedModel.setParent( parent );
>
> Two alternative solutions:
> * If the parent-pom is specified in the archetype-pom, don't replace it
> * A parameter that we can supply that will leave the archetype-pom parent
> setting untouched.
> I vote for solution number 1
--
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] Closed: (MNGSITE-71) Mistakes in "Introduction to the Dependency Mechanism"
[ http://jira.codehaus.org/browse/MNGSITE-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNGSITE-71. Assignee: Benjamin Bentmann Resolution: Fixed Fixed in [r722656|http://svn.eu.apache.org/viewvc?view=rev&revision=722656]. > Mistakes in "Introduction to the Dependency Mechanism" > -- > > Key: MNGSITE-71 > URL: http://jira.codehaus.org/browse/MNGSITE-71 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: Trevor Harmon >Assignee: Benjamin Bentmann >Priority: Minor > > There is an introduction to the dependency mechanism here: > http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html > But it has some mistakes. First, there is at least one misspelling: > "managemnet". > Also, some of the sample POMs refer to "maven-test" as the groupId, but I > believe the groupIds should be "test" instead. With "maven-test", the > dependencies are all distinct (test:a, test:c, maven-test:a, and > maven-test:c), and the explanatory text (such as "a and c both are declared > as dependencies of the project") does not make sense. -- 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] Closed: (ARCHETYPE-81) Archetype not downloaded until pom is placed in working dir
[ http://jira.codehaus.org/browse/ARCHETYPE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raphaël Piéroni closed ARCHETYPE-81. Resolution: Cannot Reproduce Thanks to Tim Reilly. This is issue is closed by obsolescence. > Archetype not downloaded until pom is placed in working dir > --- > > Key: ARCHETYPE-81 > URL: http://jira.codehaus.org/browse/ARCHETYPE-81 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Affects Versions: 1.0-alpha-4 >Reporter: Tim Reilly > Fix For: 2.0-alpha-5 > > > Our archetype is hosted internally in the company repository. > Our settings.xml contains profiles with the internal repository locations. > I mkdir C:\temp\archtest > I execute mvn archetype:create -D etc > I get "could not download archetype ... from central > Next I put a valid pom.xml in the working dir > I execute mvn archetype:create -D etc > I get an expected error since the directory is not empty, but now if I check > my local repository the archetype is downloaded from the company repository. > !! Why wasn't it found until a pom.xml is in the directory? > Now I delete the pom.xml > Now I can build sucessfully. > It would appear the profiles where we define our repositories are not being > used until the pom.xml is available. But even mvn -P archetype:create doesn't > resolve the issue. -- 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] Closed: (MNGSITE-66) Bad link on the intro to repositories page
[ http://jira.codehaus.org/browse/MNGSITE-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNGSITE-66. Assignee: Benjamin Bentmann Resolution: Fixed Fixed in [r722657|http://svn.eu.apache.org/viewvc?view=rev&revision=722657]. > Bad link on the intro to repositories page > -- > > Key: MNGSITE-66 > URL: http://jira.codehaus.org/browse/MNGSITE-66 > Project: Maven 2 Project Web Site > Issue Type: Bug >Reporter: Eric Haszlakiewicz >Assignee: Benjamin Bentmann >Priority: Minor > > On the page: > http://maven.apache.org/guides/introduction/introduction-to-repositories.html > The "The Hype About Repository Managers" link at the bottom of the page > points at: > http://www.devzuz.org/blogs/oching/2007/11/05/119423340.html > when it should point at this instead: > http://blogs.exist.com/oching/2007/11/05/the-hype-about-repository-managers/ -- 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: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository
[ http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156408#action_156408 ] Nick Stolwijk commented on SCM-262: --- Wouldn't it be possible to take the revision number at start of the release and give that to svn checkout and svn copy? Noone can change a revision so you will be save. > scm:tag for subversion tagging from local version of code, not directly from > repository > --- > > Key: SCM-262 > URL: http://jira.codehaus.org/browse/SCM-262 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Reporter: Stephan Heilner > Fix For: future > > > In theory, you shouldn't tag or branch from a local and potentially different > version of the code. From what I can tell, the scm:tag imports your existing > code into a new tag. With subversion, tagging is very lightweight if you do > a 'svn copy trunk_url tag_url'. The way it currently works make sense for > other repositories such as CVS but not for subversion. -- 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: (MAVENUPLOAD-2279) please sync org.bluestemsoftware
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156424#action_156424 ] twayne commented on MAVENUPLOAD-2279: - Hi Carlos, Here's extract from log (not sure what the warning means): Dec 1 09:54:23 ip-208-109-219-84 sshd[16163]: Connection from 207.182.253.34 port 60783 Dec 1 09:54:25 ip-208-109-219-84 sshd[16163]: reverse mapping checking getaddrinfo for haw-207-182-253-34.vel.net [207.182.253.34] failed - POSSIBLE BREAK-IN ATTEMPT! Dec 1 09:54:25 ip-208-109-219-84 sshd[16163]: Failed publickey for archiva from 207.182.253.34 port 60783 ssh2 Dec 1 09:54:32 ip-208-109-219-84 sshd[16164]: Connection closed by 207.182.253.34 I can run the following w/ my pub/priv key w/out error (so i know permissions are set correctly): rsync --include=*/ --include=**/maven-metadata.xml* --exclude=* -Lrtivz "--rsh=ssh" [EMAIL PROTECTED]:/var/archiva/data/repositories/internal test Also, I added authorized_keys2 file (only had authorized_keys,) which may be the problem depending upon version of ssh you're client is using??? Here's the maven public key contained within the above files: ssh-dss B3NzaC1kc3MAAACBAL9WxLqVn4DgS3pl6XrHQ467FLfhX+9ESYUQNsmqOxsubixtVVfiNFDpDI/LlSZSs9YcKr6XUMrVy58y3yg8pxR+T+4h3xGlUIhr/YJ60z02X7mSYNa8S2uVVL2Gou8z/GjDJnlY1GGzqXwKI07WdQ8QSAK8AYgAAZfVzn4VbCcjFQCnVrFfasrKOb6s8gteHeYyYPgndwAAAIEAhtVdf/cQ+KuzBQQqEhz9O7rqSh5GqZE177oY+2lPNpR8lKg2TRk87j3sh506gmpk82Gm4RvAOBOI6zEwLoOLsR+ucVSzUfhqgGanUworHVUnGQ7mIBqBq91JVVGORfVfK5/omi0ShIdhyZscf3vmeE3GiYtH8J3aUbGXxylkpLYAAACAOBk/ghnjuujhVo4sypxn0ATVLJ4ZcyHkl2vC4SE6VQ2XgYQv3P+NLbQtKoiNASifF1V0sOrzXxPzhPwWoh+8SxVqVLui7VC+2MKgd3etBJ3tllXIjgsxL9k8LxfDwsM+3dmICf28YQePRt4XkXADthdhOdkgG7MnpSidVmNBgDc= [EMAIL PROTECTED] > please sync org.bluestemsoftware > > > Key: MAVENUPLOAD-2279 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2279 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: twayne > > http://www.networksolutions.com/whois/results.jsp?domain=bluestemsoftware.org -- 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
