[jira] Issue Comment Edited: (SCM-182) git provider
[
http://jira.codehaus.org/browse/SCM-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129875#action_129875
]
eu edited comment on SCM-182 at 4/5/08 12:20 AM:
--
Mark, unfortunately your provider doesn't work on Windows, or alt least it is
failing for me on clone command with the error 'git-clone' is not recognized as
an internal or external command, operable program or batch file.
On windows you can't run shell scripts like that and have to run them trough
the shell (e.g. using "bash git-clone" command, or run it using "git clone"
instead). I've tried to replace "-" with " " in those commands and it seem
fixed issue on Windows.
was (Author: eu):
Mark, unfortunately your provider doesn't work on windows, or alt least it
is failing for me on clone command with the error 'git-clone' is not recognized
as an internal or external command, operable program or batch file.
On windows you can't run shell scripts like that and have to run them trough
the shell (e.g. using "bash git-clone" command, or run it using "git clone"
instead).
> git provider
>
>
> Key: SCM-182
> URL: http://jira.codehaus.org/browse/SCM-182
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-provider-git
> Environment: Developed on Mac OS X 10.3.9 with git 1.2.4
>Reporter: Dominik Winter
> Fix For: future
>
> Attachments: git.patch, git.tar.bz2, SCM-182.patch, update1.patch.bz2
>
>
> Please find the git provider as attachment.
> Usefulness:
> I used the git provider together with
> [http://maven.apache.org/plugins/maven-release-plugin|maven-release-plugin],
> it works fine for that use case.
> Open issues:
> - the JUnit tests are "proprietary", not yet TCK. I'll fix that.
> If you want to run the tests, you must have git installed and it must be in
> your {{PATH}}.
> To run git:
> - on *Windows*: use [Cygwin|http://www.cygwin.com] and install the binutils,
> openssh, openssl, rsync, curl
> than you are able to compile and install git
> - on Linux: there are packages somewhere
> - on Mac OS X: use the [DarwinPorts|http://www.darwinports.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
[jira] Commented: (SCM-182) git provider
[
http://jira.codehaus.org/browse/SCM-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129875#action_129875
]
Eugene Kuleshov commented on SCM-182:
-
Mark, unfortunately your provider doesn't work on windows, or alt least it is
failing for me on clone command with the error 'git-clone' is not recognized as
an internal or external command, operable program or batch file.
On windows you can't run shell scripts like that and have to run them trough
the shell (e.g. using "bash git-clone" command, or run it using "git clone"
instead).
> git provider
>
>
> Key: SCM-182
> URL: http://jira.codehaus.org/browse/SCM-182
> Project: Maven SCM
> Issue Type: New Feature
> Components: maven-scm-provider-git
> Environment: Developed on Mac OS X 10.3.9 with git 1.2.4
>Reporter: Dominik Winter
> Fix For: future
>
> Attachments: git.patch, git.tar.bz2, SCM-182.patch, update1.patch.bz2
>
>
> Please find the git provider as attachment.
> Usefulness:
> I used the git provider together with
> [http://maven.apache.org/plugins/maven-release-plugin|maven-release-plugin],
> it works fine for that use case.
> Open issues:
> - the JUnit tests are "proprietary", not yet TCK. I'll fix that.
> If you want to run the tests, you must have git installed and it must be in
> your {{PATH}}.
> To run git:
> - on *Windows*: use [Cygwin|http://www.cygwin.com] and install the binutils,
> openssh, openssl, rsync, curl
> than you are able to compile and install git
> - on Linux: there are packages somewhere
> - on Mac OS X: use the [DarwinPorts|http://www.darwinports.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
[jira] Updated: (MAVENUPLOAD-1981) maven-license-plugin-1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathieu Carbou updated MAVENUPLOAD-1981: Attachment: maven-license-plugin-1.2.5-bundle.jar Fixed in version 1.2.5. Download URL: http://code.google.com/p/maven-license-plugin/downloads/list > maven-license-plugin-1.2.3 > -- > > Key: MAVENUPLOAD-1981 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1981 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Mathieu Carbou > Attachments: maven-license-plugin-1.2.3-bundle.jar, > maven-license-plugin-1.2.4-bundle.jar, maven-license-plugin-1.2.5-bundle.jar > > > Hi, > Can you please upload this new (and good) version of maven-license-plugin ? > - groupId and packages are fixed to com.google.code.mojo (to conform to maven > upload doc.) - I did what Guice did. > - Little other fixes - See release notes at > http://code.google.com/p/maven-license-plugin/wiki/ReleaseNotes > Note: the plugin can be accessed temporary from this maven 2 repository: > http://mc-repo.googlecode.com/svn/maven2/releases/ > Thanks ! > --- > Mathieu Carbou > [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] Updated: (MINVOKER-30) Allow to configure file encoding for verifications scripts
[
http://jira.codehaus.org/browse/MINVOKER-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MINVOKER-30:
--
Description:
Right now, the {{verify.bsh}} is read using the platform's default encoding,
making the tests platform-dependent. We should enrich the plugin configuration
to allow the user to lock down the encoding and ensure reproducible tests.
The same applies to the {{goals.txt}} and {{profiles.txt}}.
was:
Right now, the {{verify.bsh}} is read using the platform's default encoding,
making the tests platform-dependent. We should enrich the plugin configuration
to allow the user to lock down the encoding and ensure reproducible tests.
The same applies to the {{goals.txt}}.
Patch Submitted: [Yes]
Attachment: file-encoding.patch
Here is the proposed patch, following our current proposal about [source file
encoding|http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding].
> Allow to configure file encoding for verifications scripts
> --
>
> Key: MINVOKER-30
> URL: http://jira.codehaus.org/browse/MINVOKER-30
> Project: Maven 2.x Invoker Plugin
> Issue Type: Improvement
>Affects Versions: 1.1
>Reporter: Benjamin Bentmann
> Attachments: file-encoding.patch
>
>
> Right now, the {{verify.bsh}} is read using the platform's default encoding,
> making the tests platform-dependent. We should enrich the plugin
> configuration to allow the user to lock down the encoding and ensure
> reproducible tests.
> The same applies to the {{goals.txt}} and {{profiles.txt}}.
--
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: (MRELEASE-295) Internal dependencies left at old snapshot
[ http://jira.codehaus.org/browse/MRELEASE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129862#action_129862 ] [EMAIL PROTECTED] edited comment on MRELEASE-295 at 4/4/08 2:51 PM: -- I have attached a fully-functional standalone example of this issue. This is the command that I used to test it against 2.0-beta-4 through beta-7: mvn -DdryRun=true clean release:clean release:prepare --batch-mode As mentioned above, I have two modules (one called services and one called client) that depend on the third module -- interfaces. When released, the tag is generated appropriately, but the dependency is not updated as you would expect -- it remains at 1.0.0-SNAPSHOT even though everything else has been updated to 1.0.1-SNAPSHOT. The interfaces dependency has never been installed, and is used locally in the reactor. mvn --version info: Maven version: 2.0.8 Java version: 1.6.0_03 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" was (Author: [EMAIL PROTECTED]): A fully-functional standalone example of this issue. This is the command that I used to test it against 2.0-beta-4 through beta-7: mvn -DdryRun=true clean release:clean release:prepare --batch-mode As mentioned above, I have two modules (one called services and one called client) that depend on the third module -- interfaces. When released, the tag is generated appropriately, but the dependency is not updated as you would expect -- it remains at 1.0.0-SNAPSHOT even though everything else has been updated to 1.0.1-SNAPSHOT. The interfaces dependency has never been installed, and is used locally in the reactor. mvn --version info: Maven version: 2.0.8 Java version: 1.6.0_03 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > Internal dependencies left at old snapshot > -- > > Key: MRELEASE-295 > URL: http://jira.codehaus.org/browse/MRELEASE-295 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Chris Searle > Attachments: release_test.zip > > > I'm having a problem with version numbering when releasing a given reactor > with modules within the reactor that have dependencies inside the reactor. > I have narrowed this to the following structure > A parent test/pom.xml (basically a pom packging grouping pom - but here is > where the scm and repos are also defined) with > test > test > pom > 1.0-SNAPSHOT > and > > test-1 > test-2 > > Then - the two modules: > test/test-1/pom.xml with > > test > test > 1.0-SNAPSHOT > > test > test-1 > 1.0-SNAPSHOT > test/test-2/pom.xml with > > test > test > 1.0-SNAPSHOT > > test > test-2 > 1.0-SNAPSHOT > > > test > test-1 > 1.0-SNAPSHOT > > > Then run mvn -DdryRun=true release:prepare > test/pom.xml.tag version=1.0 - good > test/pom.xml.next version=1.1-SNAPSHOT - good > test-1/pom.xml.tag version=1.0, parent version=1.0 good > test-1/pom.xml.next version=1.1-SNAPSHOT, parent version=1.1-SNAPSHOT - good > test-2/pom.xml.tag version=1.0, parent version=1.0, dependency to test-1 > version=1.0 good > test-2/pom.xml.next version=1.1-SNAPSHOT, parent version=1.1-SNAPSHOT - good > BUT > test-2/pom.xml.next dependency to test-1 version=1.0-SNAPSHOT > This seems wrong to me - I would expect it to also get 1.1-SNAPSHOT for the > dependency on test-1 since it has the same parent and is being run in the > same reactor. -- 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: (MRELEASE-295) Internal dependencies left at old snapshot
[ http://jira.codehaus.org/browse/MRELEASE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129862#action_129862 ] [EMAIL PROTECTED] edited comment on MRELEASE-295 at 4/4/08 2:50 PM: -- A fully-functional standalone example of this issue. This is the command that I used to test it against 2.0-beta-4 through beta-7: mvn -DdryRun=true clean release:clean release:prepare --batch-mode As mentioned above, I have two modules (one called services and one called client) that depend on the third module -- interfaces. When released, the tag is generated appropriately, but the dependency is not updated as you would expect -- it remains at 1.0.0-SNAPSHOT even though everything else has been updated to 1.0.1-SNAPSHOT. The interfaces dependency has never been installed, and is used locally in the reactor. mvn --version info: Maven version: 2.0.8 Java version: 1.6.0_03 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" was (Author: [EMAIL PROTECTED]): A fully-functional standalone example of this issue. See my post for more info. > Internal dependencies left at old snapshot > -- > > Key: MRELEASE-295 > URL: http://jira.codehaus.org/browse/MRELEASE-295 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Chris Searle > Attachments: release_test.zip > > > I'm having a problem with version numbering when releasing a given reactor > with modules within the reactor that have dependencies inside the reactor. > I have narrowed this to the following structure > A parent test/pom.xml (basically a pom packging grouping pom - but here is > where the scm and repos are also defined) with > test > test > pom > 1.0-SNAPSHOT > and > > test-1 > test-2 > > Then - the two modules: > test/test-1/pom.xml with > > test > test > 1.0-SNAPSHOT > > test > test-1 > 1.0-SNAPSHOT > test/test-2/pom.xml with > > test > test > 1.0-SNAPSHOT > > test > test-2 > 1.0-SNAPSHOT > > > test > test-1 > 1.0-SNAPSHOT > > > Then run mvn -DdryRun=true release:prepare > test/pom.xml.tag version=1.0 - good > test/pom.xml.next version=1.1-SNAPSHOT - good > test-1/pom.xml.tag version=1.0, parent version=1.0 good > test-1/pom.xml.next version=1.1-SNAPSHOT, parent version=1.1-SNAPSHOT - good > test-2/pom.xml.tag version=1.0, parent version=1.0, dependency to test-1 > version=1.0 good > test-2/pom.xml.next version=1.1-SNAPSHOT, parent version=1.1-SNAPSHOT - good > BUT > test-2/pom.xml.next dependency to test-1 version=1.0-SNAPSHOT > This seems wrong to me - I would expect it to also get 1.1-SNAPSHOT for the > dependency on test-1 since it has the same parent and is being run in the > same reactor. -- 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: (MRELEASE-295) Internal dependencies left at old snapshot
[ http://jira.codehaus.org/browse/MRELEASE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trevor Spackman updated MRELEASE-295: - Attachment: release_test.zip A fully-functional standalone example of this issue. See my post for more info. > Internal dependencies left at old snapshot > -- > > Key: MRELEASE-295 > URL: http://jira.codehaus.org/browse/MRELEASE-295 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Chris Searle > Attachments: release_test.zip > > > I'm having a problem with version numbering when releasing a given reactor > with modules within the reactor that have dependencies inside the reactor. > I have narrowed this to the following structure > A parent test/pom.xml (basically a pom packging grouping pom - but here is > where the scm and repos are also defined) with > test > test > pom > 1.0-SNAPSHOT > and > > test-1 > test-2 > > Then - the two modules: > test/test-1/pom.xml with > > test > test > 1.0-SNAPSHOT > > test > test-1 > 1.0-SNAPSHOT > test/test-2/pom.xml with > > test > test > 1.0-SNAPSHOT > > test > test-2 > 1.0-SNAPSHOT > > > test > test-1 > 1.0-SNAPSHOT > > > Then run mvn -DdryRun=true release:prepare > test/pom.xml.tag version=1.0 - good > test/pom.xml.next version=1.1-SNAPSHOT - good > test-1/pom.xml.tag version=1.0, parent version=1.0 good > test-1/pom.xml.next version=1.1-SNAPSHOT, parent version=1.1-SNAPSHOT - good > test-2/pom.xml.tag version=1.0, parent version=1.0, dependency to test-1 > version=1.0 good > test-2/pom.xml.next version=1.1-SNAPSHOT, parent version=1.1-SNAPSHOT - good > BUT > test-2/pom.xml.next dependency to test-1 version=1.0-SNAPSHOT > This seems wrong to me - I would expect it to also get 1.1-SNAPSHOT for the > dependency on test-1 since it has the same parent and is being run in the > same reactor. -- 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-423) NullPointerException when existing Manifest.MF file has no Class-Path element
[
http://jira.codehaus.org/browse/MECLIPSE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129860#action_129860
]
Arnaud Heritier commented on MECLIPSE-423:
--
Can you give us a sample of your pom settings to help us to reproduce it. thx.
cheers.
> NullPointerException when existing Manifest.MF file has no Class-Path element
> -
>
> Key: MECLIPSE-423
> URL: http://jira.codehaus.org/browse/MECLIPSE-423
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Michael Johns
>Priority: Minor
>
> A NullPointerException arises when running the rad goal against a project
> containing a manifest that has no Class-Path element. The exception is
> caught and the only error on the screen is "No
> \META-INF\MANIFEST.MF file found". The problem is in the
> RadManifestWriter.orderClasspath() method. It needs to check newValue for
> null before trying to split it up.
> Here's the manifest I had that caused the problem:
> {code}
> Manifest-Version: 1.0
> Build-Jdk: 1.4.2
> Built-By: Michael Johns
> Created-By: Apache Maven
> {code}
> Notice that it has no Class-Path element.
--
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: (MSHADE-28) Add full support for glob patterns in relocator exclusions
[
http://jira.codehaus.org/browse/MSHADE-28?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHADE-28.
---
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 1.1
Committed in [r644822|http://svn.apache.org/viewvc?view=rev&revision=644822].
> Add full support for glob patterns in relocator exclusions
> --
>
> Key: MSHADE-28
> URL: http://jira.codehaus.org/browse/MSHADE-28
> Project: Maven 2.x Shade Plugin
> Issue Type: Improvement
>Affects Versions: 1.0.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 1.1
>
>
> This is currently not possible
> {code:xml}
>
>
> org.codehaus.plexus.util
>
> org.codehaus.plexus.util.xml.pull.Xml*
>
>
>
> {code}
> The plugin only supports patterns that end with ".*" which is confusing.
--
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: (MSHADE-28) Add full support for glob patterns in relocator exclusions
Add full support for glob patterns in relocator exclusions
--
Key: MSHADE-28
URL: http://jira.codehaus.org/browse/MSHADE-28
Project: Maven 2.x Shade Plugin
Issue Type: Improvement
Affects Versions: 1.0.1
Reporter: Benjamin Bentmann
This is currently not possible
{code:xml}
org.codehaus.plexus.util
org.codehaus.plexus.util.xml.pull.Xml*
{code}
The plugin only supports patterns that end with ".*" which is confusing.
--
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-1823) dependencies with classifier mask transitive dependencies of same dependency without classifier
[ http://jira.codehaus.org/browse/MNG-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129854#action_129854 ] mollusk edited comment on MNG-1823 at 4/4/08 1:02 PM: -- I have the same problem , but only on unix platform test-jar dependencies work fine on windows it seems that the problem comes from maven-jar-compiler, because the depencies are in maven.compile.classpath as a work arround , i launch javac ant task before the compile phase org.apache.maven.plugins maven-antrun-plugin 1.2-SNAPSHOT ant.compile-source process-sources run was (Author: mollusk): I have the same problem , but only on unix platform test-jar dependencies work fine on windows it seems that the problem comes from maven-jar-compiler, because the depencies are in maven.compile.classpath as a work arround , i launch javac ant task before the compile phase org.apache.maven.plugins maven-antrun-plugin 1.2-SNAPSHOT pm.ant.compile-source process-sources run > dependencies with classifier mask transitive dependencies of same dependency > without classifier > --- > > Key: MNG-1823 > URL: http://jira.codehaus.org/browse/MNG-1823 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.1 >Reporter: Jorg Heymans >Assignee: Carlos Sanchez > Fix For: 2.1 > > > A module in cocoon has following dependencies : > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > tests > test > > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > > The first dependency is created by the core module using : > > maven-jar-plugin > > > > test-jar > > > > > Now i would like the module to depend on the jar with classifier "tests" > during the testing phase ie cocoon-core-2.2.0-SNAPSHOT-tests.jar, and during > the normal compilation phase it should just use > cocoon-core-2.2.0-SNAPSHOT.jar. IMO above dependencies express exactly this. > The problem is that maven somehow removes all transitive dependencies from > cocoon-core-2.2.0-SNAPSHOT.jar when both dependencies are in place, breaking > compilation. When i remove the dependency with the classifier, then all is > fine (but ofcourse my tests can't run) > I hope above is clear, otherwise just ping me on irc -- 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-1823) dependencies with classifier mask transitive dependencies of same dependency without classifier
[ http://jira.codehaus.org/browse/MNG-1823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129854#action_129854 ] mollusk commented on MNG-1823: -- I have the same problem , but only on unix platform test-jar dependencies work fine on windows it seems that the problem comes from maven-jar-compiler, because the depencies are in maven.compile.classpath as a work arround , i launch javac ant task before the compile phase org.apache.maven.plugins maven-antrun-plugin 1.2-SNAPSHOT pm.ant.compile-source process-sources run > dependencies with classifier mask transitive dependencies of same dependency > without classifier > --- > > Key: MNG-1823 > URL: http://jira.codehaus.org/browse/MNG-1823 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.1 >Reporter: Jorg Heymans >Assignee: Carlos Sanchez > Fix For: 2.1 > > > A module in cocoon has following dependencies : > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > tests > test > > > org.apache.cocoon > cocoon-core > 2.2.0-SNAPSHOT > > The first dependency is created by the core module using : > > maven-jar-plugin > > > > test-jar > > > > > Now i would like the module to depend on the jar with classifier "tests" > during the testing phase ie cocoon-core-2.2.0-SNAPSHOT-tests.jar, and during > the normal compilation phase it should just use > cocoon-core-2.2.0-SNAPSHOT.jar. IMO above dependencies express exactly this. > The problem is that maven somehow removes all transitive dependencies from > cocoon-core-2.2.0-SNAPSHOT.jar when both dependencies are in place, breaking > compilation. When i remove the dependency with the classifier, then all is > fine (but ofcourse my tests can't run) > I hope above is clear, otherwise just ping me on irc -- 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-2004) Hessian 3.1.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129849#action_129849 ] Carlos Sanchez commented on MAVENUPLOAD-2004: - the svn url is wrong, and there are no dependencies ? > Hessian 3.1.5 > - > > Key: MAVENUPLOAD-2004 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2004 > Project: maven-upload-requests > Issue Type: Task >Reporter: evgeny > Attachments: hessian-3.1.5-bundle.jar > > > The Hessian binary web service protocol makes web services usable without > requiring a large framework, and without learning yet another alphabet soup > of protocols. Because it is a binary protocol, it is well-suited to sending > binary data without any need to extend the protocol with attachments. -- 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: (MAVENUPLOAD-1999) bouncycastle 138 bundles for bcmail and bcprov
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1999. --- Assignee: Carlos Sanchez Resolution: Fixed Added with license and other info > bouncycastle 138 bundles for bcmail and bcprov > -- > > Key: MAVENUPLOAD-1999 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1999 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Xavier Le Vourch >Assignee: Carlos Sanchez > > Two bundles to upload bouncycastle's bcprov and bcmail jar files: > http://brittanysoftware.com/tmp/bcmail-jdk14-138-bundle.jar > http://brittanysoftware.com/tmp/bcprov-jdk14-138-bundle.jar > A newer version has just been released but 138 is used by iText and its > dependency check fails... Note that I am part of the iText dev team but not > associated with BouncyCastle. -- 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: (MAVENUPLOAD-2003) iText 2.1.0 broken bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2003. --- Assignee: Carlos Sanchez Resolution: Fixed Updated but people that already got downloaded 2.1.0 will have to delete it locally by hand A new release 2.1.1 would be better > iText 2.1.0 broken bundle > - > > Key: MAVENUPLOAD-2003 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2003 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Bruno Lowagie >Assignee: Carlos Sanchez > > When I posted the initial upload request for iText 2.1.0: > http://jira.codehaus.org/browse/MAVENUPLOAD-1986 > I wasn't aware that there were 2 problems: > - iText uses BouncyCastle jars version 138 and the most recent BC version in > maven is 136 > see also: http://jira.codehaus.org/browse/MAVENUPLOAD-1999 > - worse: apparently the iText.jar was overwritten by the iText-RUPS.jar > when making the bundle. > More and more people are mailing me because of these problems, > so I've made new jars and bundles here: http://itext.ugent.be/library/maven/ -- 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: (MSITE-171) Site plugin uses plain dependencies for reactor projects instead of results of earlier modules
[ http://jira.codehaus.org/browse/MSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-171: - Attachment: install_site_runs.log mvn install file runs > Site plugin uses plain dependencies for reactor projects instead of results > of earlier modules > -- > > Key: MSITE-171 > URL: http://jira.codehaus.org/browse/MSITE-171 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Win XP, Linux >Reporter: Alex Rau > Attachments: install_site_runs.log, site_fails.log, > subsequent_site_runs.log > > > When creating a multi-module site the site plugin uses dependencies from > related modules from the repository instead of using artifacts from the same > execution. > That causes inconsistent reports on the sites. An example: > Project A has modules B and C defined. B is build first and a site for > project B is created. Then project C is build using a dependency either from > the local or remote repository. Therefore the site contains results which > rely on a build with an "out-dated" artifact used as dependency. This leads > to plainly wrong results when examining surefire-reports as Project C should > have been build with the (current) artifact of project B (taken from the same > execution of the site plugin). -- 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: (MSITE-171) Site plugin uses plain dependencies for reactor projects instead of results of earlier modules
[ http://jira.codehaus.org/browse/MSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-171: - Attachment: site_fails.log mvn site fails > Site plugin uses plain dependencies for reactor projects instead of results > of earlier modules > -- > > Key: MSITE-171 > URL: http://jira.codehaus.org/browse/MSITE-171 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Win XP, Linux >Reporter: Alex Rau > Attachments: install_site_runs.log, site_fails.log, > subsequent_site_runs.log > > > When creating a multi-module site the site plugin uses dependencies from > related modules from the repository instead of using artifacts from the same > execution. > That causes inconsistent reports on the sites. An example: > Project A has modules B and C defined. B is build first and a site for > project B is created. Then project C is build using a dependency either from > the local or remote repository. Therefore the site contains results which > rely on a build with an "out-dated" artifact used as dependency. This leads > to plainly wrong results when examining surefire-reports as Project C should > have been build with the (current) artifact of project B (taken from the same > execution of the site plugin). -- 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: (MSITE-171) Site plugin uses plain dependencies for reactor projects instead of results of earlier modules
[ http://jira.codehaus.org/browse/MSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MSITE-171: - Attachment: subsequent_site_runs.log subsequent mvn site runs > Site plugin uses plain dependencies for reactor projects instead of results > of earlier modules > -- > > Key: MSITE-171 > URL: http://jira.codehaus.org/browse/MSITE-171 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Win XP, Linux >Reporter: Alex Rau > Attachments: install_site_runs.log, site_fails.log, > subsequent_site_runs.log > > > When creating a multi-module site the site plugin uses dependencies from > related modules from the repository instead of using artifacts from the same > execution. > That causes inconsistent reports on the sites. An example: > Project A has modules B and C defined. B is build first and a site for > project B is created. Then project C is build using a dependency either from > the local or remote repository. Therefore the site contains results which > rely on a build with an "out-dated" artifact used as dependency. This leads > to plainly wrong results when examining surefire-reports as Project C should > have been build with the (current) artifact of project B (taken from the same > execution of the site plugin). -- 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: (MSITE-171) Site plugin uses plain dependencies for reactor projects instead of results of earlier modules
[ http://jira.codehaus.org/browse/MSITE-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129842#action_129842 ] Michael Osipov commented on MSITE-171: -- I suffer from the same problem too. I have an example for, check out my repo [here|http://svn.fckeditor.net/FCKeditor.Java/branches/2.4/] and run "mvn site" you should see the error log which I have attached too. Running "mvn install site" resolves the issue. Every subsequent exection of site runs fine because it is already in local repo. > Site plugin uses plain dependencies for reactor projects instead of results > of earlier modules > -- > > Key: MSITE-171 > URL: http://jira.codehaus.org/browse/MSITE-171 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-5 > Environment: Win XP, Linux >Reporter: Alex Rau > > When creating a multi-module site the site plugin uses dependencies from > related modules from the repository instead of using artifacts from the same > execution. > That causes inconsistent reports on the sites. An example: > Project A has modules B and C defined. B is build first and a site for > project B is created. Then project C is build using a dependency either from > the local or remote repository. Therefore the site contains results which > rely on a build with an "out-dated" artifact used as dependency. This leads > to plainly wrong results when examining surefire-reports as Project C should > have been build with the (current) artifact of project B (taken from the same > execution of the site plugin). -- 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: (MAVENUPLOAD-2002) Please upload JCROM 1.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2002. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload JCROM 1.2 > --- > > Key: MAVENUPLOAD-2002 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2002 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Olafur Gauti Gudmundsson >Assignee: Carlos Sanchez > > http://jcrom.googlecode.com/files/jcrom-1.2-bundle.jar > http://jcrom.org (forwards to the google-code page for JCROM) > http://code.google.com/u/oli.gauti/ > I am the project owner, please 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] Closed: (MSHADE-27) Use platform-independent file encoding for processing of NOTICE file
[
http://jira.codehaus.org/browse/MSHADE-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHADE-27.
---
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 1.1
Fixed in [r644772|http://svn.apache.org/viewvc?view=rev&revision=644772].
> Use platform-independent file encoding for processing of NOTICE file
>
>
> Key: MSHADE-27
> URL: http://jira.codehaus.org/browse/MSHADE-27
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 1.1
>
>
> The {{ApacheNoticeResourceTransformer}} uses the JVM's default encoding to
> read/write the NOTICE file, making the output of the resource transformation
> platform-dependent. For reproducible builds, the file encoding should be
> locked down using a parameter of the transformator.
--
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: (MAVENUPLOAD-2001) JasperReports 2.0.5 upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2001. --- Assignee: Carlos Sanchez Resolution: Fixed > JasperReports 2.0.5 upload > -- > > Key: MAVENUPLOAD-2001 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2001 > Project: maven-upload-requests > Issue Type: Task >Reporter: Teodor Danciu >Assignee: Carlos Sanchez > > http://jasperreports.sf.net/maven/jasperreports-2.0.5-bundle.jar > http://sourceforge.net/projects/jasperreports > http://sourceforge.net/project/memberlist.php?group_id=36382 > Open Source Reporting Engine -- 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-1981) maven-license-plugin-1.2.3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129839#action_129839 ] Carlos Sanchez commented on MAVENUPLOAD-1981: - i still see com.google.code as groupid > maven-license-plugin-1.2.3 > -- > > Key: MAVENUPLOAD-1981 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1981 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Mathieu Carbou > Attachments: maven-license-plugin-1.2.3-bundle.jar, > maven-license-plugin-1.2.4-bundle.jar > > > Hi, > Can you please upload this new (and good) version of maven-license-plugin ? > - groupId and packages are fixed to com.google.code.mojo (to conform to maven > upload doc.) - I did what Guice did. > - Little other fixes - See release notes at > http://code.google.com/p/maven-license-plugin/wiki/ReleaseNotes > Note: the plugin can be accessed temporary from this maven 2 repository: > http://mc-repo.googlecode.com/svn/maven2/releases/ > Thanks ! > --- > Mathieu Carbou > [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: (MECLIPSE-423) NullPointerException when existing Manifest.MF file has no Class-Path element
NullPointerException when existing Manifest.MF file has no Class-Path element
-
Key: MECLIPSE-423
URL: http://jira.codehaus.org/browse/MECLIPSE-423
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Michael Johns
Priority: Minor
A NullPointerException arises when running the rad goal against a project
containing a manifest that has no Class-Path element. The exception is caught
and the only error on the screen is "No \META-INF\MANIFEST.MF
file found". The problem is in the RadManifestWriter.orderClasspath() method.
It needs to check newValue for null before trying to split it up.
Here's the manifest I had that caused the problem:
{code}
Manifest-Version: 1.0
Build-Jdk: 1.4.2
Built-By: Michael Johns
Created-By: Apache Maven
{code}
Notice that it has no Class-Path element.
--
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: (MAVENUPLOAD-2000) Set up rsync for ant-contrib
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2000. --- Assignee: Carlos Sanchez Resolution: Fixed > Set up rsync for ant-contrib > > > Key: MAVENUPLOAD-2000 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2000 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Curt Arnold >Assignee: Carlos Sanchez > > rsync-ssh request for ant-contrib (cpptasks/1.0b5 is newly released) > "ant-contrib","[EMAIL > PROTECTED]:/home/groups/a/an/ant-contrib/htdocs/m2-repo","rsync_ssh","Curt > Arnold","[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] Closed: (MAVENUPLOAD-1998) BlazeDS: Setup Unofficial Maintainer
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1998. --- Assignee: Carlos Sanchez Resolution: Fixed > BlazeDS: Setup Unofficial Maintainer > > > Key: MAVENUPLOAD-1998 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1998 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Ryan Heaton >Assignee: Carlos Sanchez > > "com.adobe.blazeds","[EMAIL > PROTECTED]:/home/users/s/st/stoicflame/m2","rsync_ssh","Ryan Heaton","[EMAIL > PROTECTED]",, > I maintain Enunciate (http://enunciate.codehaus.org), which has an explicit > dependency on Adobe's BlazeDS. I therefore regularly use the BlazeDS jars and > will frequently require an update to said jars. Since Adobe does not provide > a repository to sync from, I would like to take the responsibility of being > the "unofficial maintainer" of the project in the m2 repo according to the > "Guide to uploading artifacts to the Central Repository". -- 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: (MAVENUPLOAD-1984) please upload scannotations
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1984. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload scannotations > --- > > Key: MAVENUPLOAD-1984 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1984 > Project: maven-upload-requests > Issue Type: Task >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > Scannotation allow to retrieve a set of annotated classes from classpath > This bundle was create from the project POM.xml, with addition for required > metadatas to build the bundle. -- 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: (MAVENUPLOAD-1989) Add Xalan 2.7.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1989. --- Assignee: Carlos Sanchez Resolution: Won't Fix Brian Minchau from Xalan will be copying the jars to tha apache m1 repo > Add Xalan 2.7.1 > --- > > Key: MAVENUPLOAD-1989 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1989 > Project: maven-upload-requests > Issue Type: Task >Reporter: Daniel Kulp >Assignee: Carlos Sanchez > > Please add xalan 2.7.1 to the maven repos. It fixes a couple of nasty bugs > that we're encountering and would like to be able to use it. -- 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: (MAVENUPLOAD-1995) Please sync javassist groupId
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1995. --- Assignee: Carlos Sanchez Resolution: Fixed > Please sync javassist groupId > - > > Key: MAVENUPLOAD-1995 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1995 > Project: maven-upload-requests > Issue Type: Task >Reporter: nicolas de loof >Assignee: Carlos Sanchez > > This is only a copy of http://repository.jboss.com/maven2/javassist/ > If there is a better way to sync some artifacts from > http://repository.jboss.com to central please let me know -- 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: (MAVENUPLOAD-1996) Upload Hessian 3.1.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1996. --- Assignee: Carlos Sanchez Resolution: Duplicate > Upload Hessian 3.1.5 > > > Key: MAVENUPLOAD-1996 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1996 > Project: maven-upload-requests > Issue Type: Task >Reporter: evgeny >Assignee: Carlos Sanchez > Attachments: hessian-3.1.5.jar > > > The Hessian binary web service protocol makes web services usable without > requiring a large framework, and without learning yet another alphabet soup > of protocols. Because it is a binary protocol, it is well-suited to sending > binary data without any need to extend the protocol with attachments. -- 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: (MAVENUPLOAD-1997) Upload Hessian Flex 3.1.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1997. --- Assignee: Carlos Sanchez Resolution: Duplicate > Upload Hessian Flex 3.1.5 > - > > Key: MAVENUPLOAD-1997 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1997 > Project: maven-upload-requests > Issue Type: Task >Reporter: evgeny >Assignee: Carlos Sanchez > Attachments: hessian-flex-3.1.5.swc > > > The Hessian binary web service protocol makes web services usable without > requiring a large framework, and without learning yet another alphabet soup > of protocols. Because it is a binary protocol, it is well-suited to sending > binary data without any need to extend the protocol with attachments. -- 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: (MSHADE-27) Use platform-independent file encoding for processing of NOTICE file
Use platform-independent file encoding for processing of NOTICE file
Key: MSHADE-27
URL: http://jira.codehaus.org/browse/MSHADE-27
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Benjamin Bentmann
The {{ApacheNoticeResourceTransformer}} uses the JVM's default encoding to
read/write the NOTICE file, making the output of the resource transformation
platform-dependent. For reproducible builds, the file encoding should be locked
down using a parameter of the transformator.
--
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: (MSHADE-26) Fix case-insensitive string comparisions in resource transformers
[
http://jira.codehaus.org/browse/MSHADE-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MSHADE-26.
---
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 1.1
Fixed in [r644743|http://svn.apache.org/viewvc?view=rev&revision=644743].
> Fix case-insensitive string comparisions in resource transformers
> -
>
> Key: MSHADE-26
> URL: http://jira.codehaus.org/browse/MSHADE-26
> Project: Maven 2.x Shade Plugin
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 1.1
>
>
> {{[String.toLowerCase()|http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase()]}}
> is sensitive to the JVM's default locale and hence platform-dependent,
> potentially yielding wrong build output. For instance:
> {code:java}
> Locale.setDefault( new Locale( "en" ) );
> System.out.println( "META-INF/NOTICE".toLowerCase().equals( "meta-inf/notice"
> ) );
> Locale.setDefault( new Locale( "tr" ) );
> System.out.println( "META-INF/NOTICE".toLowerCase().equals( "meta-inf/notice"
> ) );
> {code}
> will print
> {noformat}
> true
> false
> {noformat}
> See also [Common
> Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a14931921].
--
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-3489) StringIndexOutOfBoundsException in AbstractMavenReportRenderer.applyPattern
[ http://jira.codehaus.org/browse/MNG-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3489: --- Description: Maybe the problem is in 'ProjectSummaryReport$ProjectSummaryRenderer.renderBody'. Here is the stack trace: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -221 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -221 at java.lang.String.substring(String.java:1768) at org.apache.maven.reporting.AbstractMavenReportRenderer.applyPattern(AbstractMavenReportRenderer.java:533) at org.apache.maven.reporting.AbstractMavenReportRenderer.linkPatternedText(AbstractMavenReportRenderer.java:353) at org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:213) at org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:193) at org.apache.maven.reporting.AbstractMavenReportRenderer.tableRow(AbstractMavenReportRenderer.java:225) at org.apache.maven.report.projectinfo.ProjectSummaryReport$ProjectSummaryRenderer.renderBody(ProjectSummaryReport.java:109) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) at org.apache.maven.report.projectinfo.ProjectSummaryReport.executeReport(ProjectSummaryReport.java:39) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) 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:585) 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) was: Maybe the problem is in 'ProjectSummaryReport$ProjectSummaryRenderer.renderBody'. Here is the stack trace: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -221 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -221 at java.lang.String.substring(String.java:1768) at org.apache.maven.reporting.AbstractMavenReportRenderer.applyPattern(AbstractMavenReportRenderer.java:533) at org.apache.maven.reporting.AbstractMavenReportRenderer.linkPatternedText(AbstractMavenReportRenderer.java:353) at org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:213) at org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:193) at org.apache.maven.reporting.AbstractMavenRep
[jira] Commented: (NMAVEN-113) Remove dependencies using VS NMaven Plugin
[ http://jira.codehaus.org/browse/NMAVEN-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129823#action_129823 ] Shane Isbell commented on NMAVEN-113: - When a user adds and deletes local assembly references from a project within VS, the addin takes care of synching these operations with the pom. These actions are handled by adding listeners to the standard VS interface. The AddArtifactForm is needed to view and pull down dependencies from a remote Maven repository. I'm not quiet sure why we need a remove dependencies form is needed, removing dependencies locally is already handled. > Remove dependencies using VS NMaven Plugin > -- > > Key: NMAVEN-113 > URL: http://jira.codehaus.org/browse/NMAVEN-113 > Project: NMaven > Issue Type: Bug >Reporter: John Michael Luy > Attachments: NMAVEN-113.patch > > > Provide functionality to remove dependencies using VS NMaven plugin. -- 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: (MSHADE-26) Fix case-insensitive string comparisions in resource transformers
Fix case-insensitive string comparisions in resource transformers
-
Key: MSHADE-26
URL: http://jira.codehaus.org/browse/MSHADE-26
Project: Maven 2.x Shade Plugin
Issue Type: Bug
Affects Versions: 1.0.1
Reporter: Benjamin Bentmann
{{[String.toLowerCase()|http://java.sun.com/javase/6/docs/api/java/lang/String.html#toLowerCase()]}}
is sensitive to the JVM's default locale and hence platform-dependent,
potentially yielding wrong build output. For instance:
{code:java}
Locale.setDefault( new Locale( "en" ) );
System.out.println( "META-INF/NOTICE".toLowerCase().equals( "meta-inf/notice" )
);
Locale.setDefault( new Locale( "tr" ) );
System.out.println( "META-INF/NOTICE".toLowerCase().equals( "meta-inf/notice" )
);
{code}
will print
{noformat}
true
false
{noformat}
See also [Common
Bugs|http://www.nabble.com/Common-Bugs-to14783703s177.html#a14931921].
--
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: (MECLIPSE-422) Cannot specify a separate output directory for test classes when custom buildOutputDirectory set
Cannot specify a separate output directory for test classes when custom buildOutputDirectory set Key: MECLIPSE-422 URL: http://jira.codehaus.org/browse/MECLIPSE-422 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path Affects Versions: 2.5 Reporter: Mark Hobson As soon as buildOutputDirectory is set to a non-default value the output directories for all source folders are the same. It should be possible to specify a buildTestOutputDirectory to separate main and test classes, as is the default behaviour when buildOutputDirectory is not set. -- 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-3489) StringIndexOutOfBoundsException in AbstractMavenReportRenderer.applyPattern
[ http://jira.codehaus.org/browse/MNG-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129806#action_129806 ] elifarley edited comment on MNG-3489 at 4/4/08 8:52 AM: --- I've attached a very simple unit test case and a proposed fix for it, which is quite simple too. This patch is against https://svn.apache.org/repos/asf/maven/shared/branches/maven-reporting-impl-2.0.4.x was (Author: elifarley): I've attached a very simple unit test case and a proposed fix for it, which is quite simple too. > StringIndexOutOfBoundsException in AbstractMavenReportRenderer.applyPattern > --- > > Key: MNG-3489 > URL: http://jira.codehaus.org/browse/MNG-3489 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.8 > Environment: Maven embedder being called from Hudson 1.199 >Reporter: Elifarley Callado Coelho >Priority: Blocker > Attachments: MNG-3489-test-and-fix.patch.gz > > > Maybe the problem is in > 'ProjectSummaryReport$ProjectSummaryRenderer.renderBody'. > Here is the stack trace: > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] String index out of range: -221 > [INFO] > > [INFO] Trace > java.lang.StringIndexOutOfBoundsException: String index out of range: -221 > at java.lang.String.substring(String.java:1768) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.applyPattern(AbstractMavenReportRenderer.java:533) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.linkPatternedText(AbstractMavenReportRenderer.java:353) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:213) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:193) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.tableRow(AbstractMavenReportRenderer.java:225) > at > org.apache.maven.report.projectinfo.ProjectSummaryReport$ProjectSummaryRenderer.renderBody(ProjectSummaryReport.java:109) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.ProjectSummaryReport.executeReport(ProjectSummaryReport.java:39) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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:585) > 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.jav
[jira] Commented: (MECLIPSE-388) Correct classpath ordering in .classpath
[
http://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129813#action_129813
]
Jeroen Ruijgers commented on MECLIPSE-388:
--
the ordering has changed in 2.5. i had a problem with a dependency of a
subproject. in the project is a class with the same package/name as in de
dependency, but on the eclipse classpath the dependency came before the
subproject. therefore the wrong class was used in eclipse and i got a nice red
cross.
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: http://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Priority: Critical
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
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-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ http://jira.codehaus.org/browse/MWAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129812#action_129812 ] Barend Garvelink commented on MWAR-9: - This is a big issue for a lot of people, and the information on it appears to be very fragmented. I have tried to summarize all the information related to this issue on the Codehaus wiki so that a good, lasting solution can hopefully be found. Please chip in with your thoughts: [http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem] > WAR plugin should support minimal WARs for inclusion within an EAR > -- > > Key: MWAR-9 > URL: http://jira.codehaus.org/browse/MWAR-9 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Reporter: Mike Perham >Assignee: Stephane Nicoll > Fix For: 2.1 > > Attachments: AbstractWarMojo.patch > > > I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my > deps. This is fine for a default but maven should also support "skeleton" > WARs which will be packaged within an EAR. We have EARs which package 3-4 > WARs each and to have the deps duplicated within each WAR means we cannot > have shared data (since the classes are loaded within each WAR's classloader, > rather than by the parent EAR's classloader). It also means 80MB EARs! :-) > It seems like two things need to happen: > 1) Add a "skeleton" flag which prevents copying any dependencies to > WEB-INF/lib. > 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which > lists the relative locations of the dependencies within the parent EAR. > Fabrice has basically the same idea written down here. Starting with "- for > a War..." : > http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2 -- 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: (MEAR-60) Improve support for skinny war files
[ http://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129811#action_129811 ] Barend Garvelink commented on MEAR-60: -- This is a big issue for a lot of people, and the information on it appears to be very fragmented. I have tried to summarize all the information related to this issue on the Codehaus wiki so that a good, lasting solution can hopefully be found. Please chip in with your thoughts: [http://docs.codehaus.org/display/MAVENUSER/Solving+the+Skinny+Wars+problem] > Improve support for skinny war files > > > Key: MEAR-60 > URL: http://jira.codehaus.org/browse/MEAR-60 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: mvn 2.0.5 >Reporter: Marcel Schutte >Priority: Critical > > Provide a boolean configuration option for webModules to include the war's > transitive dependencies. > As described on > http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it > is very common in a J2EE environment to use so called skinny wars. Here the > war's WEB-INF/lib will not contain the dependent jars, but instead they are > packaged inside the EAR. The war references them through its > META-INF/MANIFEST.MF > This option could be used to avoid the 'painful part' mentioned in the above > web page. The war's dependencies wouldn't have to be duplicated alongside the > ear's. > I also found an old issue (MEAR-14) which has asked for the current default > behavior of not including the transitive dependencies. It suggests a property > to include specific dependencies of the war. As far as I can tell this has > never been implemented and this is also not what I am asking for. My proposal > is an all of nothing kind of option for each war module in the ear. > On a side note, for me this is the part where removal of the old maven 1 > style properties per dependency is missed the most. With them it was possible > to decide for each single dependency whether to put it in WEB-INF/lib or > reference it through the manifest classpath. But of course, then we didn't > have the transitive dependencies -- 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: (MSITE-224) [PATCH] please make UTF-8 the default encoding
[ http://jira.codehaus.org/browse/MSITE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129810#action_129810 ] Petr Kozelka commented on MSITE-224: That's true for input encoding. However, for output encoding, each xml file has its own XML declaration with encoding optionally specified. And when it is specified, it should be respected, otherwise it is a bug. But respecting XML encoding is possible only if you can convert any text from its content into the output encoding. So in my opinion, the best solution is that the functionality fails when it encounters any character that cannot be converted this way, but it might be much harder to implement. While switching (at least) the default output encoding to UTF8 is easy and would be very helpful and produces no compatibility issues I believe. > [PATCH] please make UTF-8 the default encoding > -- > > Key: MSITE-224 > URL: http://jira.codehaus.org/browse/MSITE-224 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: encoding > Environment: Gentoo Linux, UTF-8 encoded pom files >Reporter: Petr Kozelka >Priority: Minor > Attachments: site-plugin-UTF8-encoding.patch > > > UTF-8 is already widely supported and used by tools, there is hardly a reason > to keep with ISO-8859-1 found through the code. > In my usecases, it typically makes troubles with developer names containing > accented letters. > Attached patch changes the default input and output encoding in > maven-site-plugin which is the most important piece. -- 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-3489) StringIndexOutOfBoundsException in AbstractMavenReportRenderer.applyPattern
[ http://jira.codehaus.org/browse/MNG-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elifarley Callado Coelho updated MNG-3489: -- Attachment: MNG-3489-test-and-fix.patch.gz I've attached a very simple unit test case and a proposed fix for it, which is quite simple too. > StringIndexOutOfBoundsException in AbstractMavenReportRenderer.applyPattern > --- > > Key: MNG-3489 > URL: http://jira.codehaus.org/browse/MNG-3489 > Project: Maven 2 > Issue Type: Bug > Components: Sites & Reporting >Affects Versions: 2.0.8 > Environment: Maven embedder being called from Hudson 1.199 >Reporter: Elifarley Callado Coelho >Priority: Blocker > Attachments: MNG-3489-test-and-fix.patch.gz > > > Maybe the problem is in > 'ProjectSummaryReport$ProjectSummaryRenderer.renderBody'. > Here is the stack trace: > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] String index out of range: -221 > [INFO] > > [INFO] Trace > java.lang.StringIndexOutOfBoundsException: String index out of range: -221 > at java.lang.String.substring(String.java:1768) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.applyPattern(AbstractMavenReportRenderer.java:533) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.linkPatternedText(AbstractMavenReportRenderer.java:353) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:213) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:193) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.tableRow(AbstractMavenReportRenderer.java:225) > at > org.apache.maven.report.projectinfo.ProjectSummaryReport$ProjectSummaryRenderer.renderBody(ProjectSummaryReport.java:109) > at > org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) > at > org.apache.maven.report.projectinfo.ProjectSummaryReport.executeReport(ProjectSummaryReport.java:39) > at > org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) > at > org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) > at > org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) > 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:585) > 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) -- 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-3238) property not resolved in for war projects
[ http://jira.codehaus.org/browse/MNG-3238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129797#action_129797 ] Barend Garvelink commented on MNG-3238: --- Could this be related to MNG-3269? > property not resolved in for war projects > > > Key: MNG-3238 > URL: http://jira.codehaus.org/browse/MNG-3238 > Project: Maven 2 > Issue Type: Bug > Components: POM >Reporter: Jerome Lacoste > Fix For: 2.0.x > > Attachments: optional-properties-taken-from-pom.tar > > > I am trying to make some sort of custom skinny war files without having to > use profiles which tend to be very verbose. > So I am using true to make those dependencies not being > packaged. > In order to make this conditional, I tried to use a to define the > default value, which I can override in the command line. > This doesn't work. See attached test case. -- 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-3501) Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT
Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT - Key: MNG-3501 URL: http://jira.codehaus.org/browse/MNG-3501 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.6, 2.1 Reporter: Dave Syer Priority: Minor Maven truncates the final "." from versionId 1.0.0.-SNAPSHOT. This appears to be a regression, since it works OK in 2.0.8, but not in 2.0.6 or 2.1. To reproduce: 1. set up a Maven project with versionId 1.0.0.-SNAPSHOT (or X.X.-SNAPSHOT). 2. run "mvn install" 3. Look in the local repository for the artifact, and find it in a directory called "1.0.0". -- 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: (MSITE-224) [PATCH] please make UTF-8 the default encoding
[ http://jira.codehaus.org/browse/MSITE-224?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129794#action_129794 ] Michael Osipov commented on MSITE-224: -- applying this patch we should ensure that every single file (xdoc, apt, fml) are written in UTF-8 too! > [PATCH] please make UTF-8 the default encoding > -- > > Key: MSITE-224 > URL: http://jira.codehaus.org/browse/MSITE-224 > Project: Maven 2.x Site Plugin > Issue Type: Improvement > Components: encoding > Environment: Gentoo Linux, UTF-8 encoded pom files >Reporter: Petr Kozelka >Priority: Minor > Attachments: site-plugin-UTF8-encoding.patch > > > UTF-8 is already widely supported and used by tools, there is hardly a reason > to keep with ISO-8859-1 found through the code. > In my usecases, it typically makes troubles with developer names containing > accented letters. > Attached patch changes the default input and output encoding in > maven-site-plugin which is the most important piece. -- 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: (MSITE-293) Submodule inherit menu but this should not happend
[ http://jira.codehaus.org/browse/MSITE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129792#action_129792 ] Michael Osipov commented on MSITE-293: -- I suffer from this one too! That's why I removed the automatic references for parent and modules (ref parent/modules) and did it my own. There is no other way at the moment. > Submodule inherit menu but this should not happend > -- > > Key: MSITE-293 > URL: http://jira.codehaus.org/browse/MSITE-293 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 > Environment: maven 2.0.8 > jdk 1.6 > windows >Reporter: Andreas Höhmann >Priority: Critical > > Projectstructur: > modul > | pom.xml > | src/site/site.xml > | src/site/xdoc/index.xml > +-- submodul 1 > | pom.xml > | src/site/xdoc/index.xml > +-- submodul 2 > | pom.xml > | src/site/xdoc/index.xml > modul :: site.xml > ... > > > > > > > > > > > > > >href="http://lp2p067c:82/maven2/repositories/"; /> > > > > > > ... > after "mvn clean install site" each submodules has a menu "Maven" ... but i > want this only for the "main-modul". > whats wrong? > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html > ... Inheritance ... "By default, only the basic settings are inherited. From > the body, only the links are inherited, and these accumulate to contain all > the parents' site descriptor links." -- 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: (NMAVEN-113) Remove dependencies using VS NMaven Plugin
[ http://jira.codehaus.org/browse/NMAVEN-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Michael Luy updated NMAVEN-113: Attachment: NMAVEN-113.patch attached a patch based on STABLE-2007-12-16 tag > Remove dependencies using VS NMaven Plugin > -- > > Key: NMAVEN-113 > URL: http://jira.codehaus.org/browse/NMAVEN-113 > Project: NMaven > Issue Type: Bug >Reporter: John Michael Luy > Attachments: NMAVEN-113.patch > > > Provide functionality to remove dependencies using VS NMaven plugin. -- 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: (MAVENUPLOAD-2005) Hessian Flex 3.1.5
Hessian Flex 3.1.5 -- Key: MAVENUPLOAD-2005 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2005 Project: maven-upload-requests Issue Type: Task Reporter: evgeny Attachments: hessian-flex-3.1.5-bundle.jar The Hessian binary web service protocol makes web services usable without requiring a large framework, and without learning yet another alphabet soup of protocols. Because it is a binary protocol, it is well-suited to sending binary data without any need to extend the protocol with attachments. -- 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: (MAVENUPLOAD-2004) Hessian 3.1.5
Hessian 3.1.5 - Key: MAVENUPLOAD-2004 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2004 Project: maven-upload-requests Issue Type: Task Reporter: evgeny Attachments: hessian-3.1.5-bundle.jar The Hessian binary web service protocol makes web services usable without requiring a large framework, and without learning yet another alphabet soup of protocols. Because it is a binary protocol, it is well-suited to sending binary data without any need to extend the protocol with attachments. -- 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: (NMAVEN-113) Remove dependencies using VS NMaven Plugin
Remove dependencies using VS NMaven Plugin -- Key: NMAVEN-113 URL: http://jira.codehaus.org/browse/NMAVEN-113 Project: NMaven Issue Type: Bug Reporter: John Michael Luy Provide functionality to remove dependencies using VS NMaven plugin. -- 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-2691) DefaultPluginManager.addPlugin() doesn't tell which plugin is broken
[ http://jira.codehaus.org/browse/MNG-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=129787#action_129787 ] Aaron Digulla commented on MNG-2691: I think this bug is fixed in 2.0.8 but there is a new issue: I get this error with the maven-site-plugin 2.0-beta-6: [code] [DEBUG] maven-site-plugin: resolved to version 2.0-beta-6 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::10 for project: null:maven-site-plugin:maven-plugin:2.0-beta-6 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-site-plugin] was not found. [INFO] [DEBUG] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-site-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:321) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:208) [code] As you can see, the plugin exists and the POM could be loaded. So what is wrong in this case? > DefaultPluginManager.addPlugin() doesn't tell which plugin is broken > > > Key: MNG-2691 > URL: http://jira.codehaus.org/browse/MNG-2691 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0.5 >Reporter: Aaron Digulla > Fix For: Reviewed Pending Version Assignment > > > In DefaultPluginManager.addPlugin() is code like this: > throw new IllegalStateException( "The PluginDescriptor for the plugin " + > plugin + " was not found." ); > Unfortunately, "plugin" has no toString(), so you just see the Java classname > and the object id. > Replace all three places with "plugin.getKey()" or, even better, add a new > method to Plugin which also includes the version string if there is one. > Also the error message of the IllegalStateException should be: > "The PluginDescriptor for the plugin " + plugin.getKey() + " was not found. > Are you sure this is a Maven plugin and not a normal dependency?" -- 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: (MECLIPSE-421) Support apt integration in eclipse:eclipse goal
Support apt integration in eclipse:eclipse goal --- Key: MECLIPSE-421 URL: http://jira.codehaus.org/browse/MECLIPSE-421 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.5 Reporter: Mark Hobson Eclipse supports apt integration via the Project Properties -> Java Compiler -> Annotation Processing options. It'd be handy if eclipse:eclipse could configure this from the plugin configuration. A goal that attempts to achieve this already exists in the mojo apt-maven-plugin project: http://svn.codehaus.org/mojo/trunk/sandbox/apt-maven-plugin/src/main/java/org/codehaus/mojo/apt/EclipseAptMojo.java I haven't used this much myself but I feel it would better housed by the maven-eclipse-plugin 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] Created: (MAVENUPLOAD-2003) iText 2.1.0 broken bundle
iText 2.1.0 broken bundle - Key: MAVENUPLOAD-2003 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2003 Project: maven-upload-requests Issue Type: Bug Reporter: Bruno Lowagie When I posted the initial upload request for iText 2.1.0: http://jira.codehaus.org/browse/MAVENUPLOAD-1986 I wasn't aware that there were 2 problems: - iText uses BouncyCastle jars version 138 and the most recent BC version in maven is 136 see also: http://jira.codehaus.org/browse/MAVENUPLOAD-1999 - worse: apparently the iText.jar was overwritten by the iText-RUPS.jar when making the bundle. More and more people are mailing me because of these problems, so I've made new jars and bundles here: http://itext.ugent.be/library/maven/ -- 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: (MECLIPSE-420) eclipse:eclipse on pom with modules: order of entries in .classpath
eclipse:eclipse on pom with modules: order of entries in .classpath
---
Key: MECLIPSE-420
URL: http://jira.codehaus.org/browse/MECLIPSE-420
Project: Maven 2.x Eclipse Plugin
Issue Type: Improvement
Components: Core : Dependencies resolution and build path, Core :
Multi-projects
Affects Versions: 2.5
Environment: Maven version: 2.0.8
Java version: 1.6.0_05
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Sebastian Jacobi
Attachments: test.zip
I have three modules: module1, module2 and module3.
Module2 depends on module1 (with some dependency inclusions) and module3
depends on module2 (and indirectly on module1).
Now I created a "super pom" as follows:
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
com.mycompany.app
1.0-SNAPSHOT
app
pom
module1
module2
module3
{code}
When executing {noformat}mvn eclipse:eclipse{noformat} on this pom will
beautifully generate all project and classpath files with the dependencies set
correctly between the projects (rather than the jars from the maven repo).
BUT:
the ordering in the .classpath IMHO should have the referenced projects last -
as otherwise the excluded dependencies can accidentally take precedence to the
actually referenced version.
--
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: (SUREFIRE-480) Improper TestCase classes incorrectly reported as a failure of the TestSuite class
Improper TestCase classes incorrectly reported as a failure of the TestSuite class -- Key: SUREFIRE-480 URL: http://jira.codehaus.org/browse/SUREFIRE-480 Project: Maven Surefire Issue Type: Bug Components: JUnit 3.x support Affects Versions: 2.4.2 Environment: OS X 10.5, JDK 1.5.0_13, Maven 2.0.8 Reporter: Chad La Joie surefire creates a synthetic TestSuite from all concrete classes that match its include configuration. If one of these classes is not a proper JUnit TestCase (for example if it contains no test methods) surefire reports this as a test failure on the junit.framework.TestSuite$1 class, within the summary and surefire report, instead of an issue with the improper test class. It does correctly flag the improper class as a failure as the plugin reports the test results on console but if you have many tests its easy to miss this. It would be nice if, in the summary and the report, the improper test class can be flagged as the failing class instead of the TestSuite class. -- 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: (NMAVEN-112) Unable to generate solution file from test project
Unable to generate solution file from test project
--
Key: NMAVEN-112
URL: http://jira.codehaus.org/browse/NMAVEN-112
Project: NMaven
Issue Type: Bug
Reporter: Maria Catherine Tan
Priority: Critical
To reproduce:
mvn archetype:create -DgroupId=NMaven -DartifactId=NMaven.Test
-DarchetypeArtifactId=maven-archetype-dotnet-simple
-DarchetypeGroupId=org.apache.maven.dotnet
-DarchetypeVersion=0.14-maestro-1.5-M3
cd NMaven.Test
mvn install
mvn clean
mvn org.apache.maven.dotnet.plugins:maven-vsinstaller-plugin:install
mvn NMaven.Plugins:NMaven.Plugin.Solution.JavaBinding:Solution
This results in some build output, then an error/debug dialog:
NMaven.Plugin.Loader has encountered a problem and needs to close
Console output:
{code}
[INFO] [NMaven.Plugin.Solution.JavaBinding:Solution]
NMAVEN: Start Process = 12/10/2007 2:35:19 PM
"parameterFile=C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml" "assemblyFile=C
:\Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.14-mae
stro-1.5-M3__NMaven.Plugins\NMaven.Plugin.Solution.dll" "mojoName=NMaven.Plugin.
Solution.SolutionMojo" "startProcessAssembly=C:\Documents and Settings\wsmoak\.m
2\pab\gac_msil\NMaven.Plugin.Loader\0.14-maestro-1.5-M3__NMaven.Plugin\NMaven.Pl
ugin.Loader.exe"
NMAVEN: End Process = 12/10/2007 2:35:19 PM
Creating Plugin Domain Manager
ParamFile = C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml, AssemblyFile = C:\
Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.14-maest
ro-1.5-M3__NMaven.Plugins\NMaven.Plugin.Solution.dll, MojoName = NMaven.Plugin.S
olution.SolutionMojo
Loading Plugin: C:\Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.
Solution\0.14-maestro-1.5-M3__NMaven.Plugins
Creating Plugin Domain Manager
System.String:NMaven.Model.Pom.Model
System.String:System.String
NMaven.Model.Pom.Model:NMaven.Model.Pom.Model
System.String:NMaven.Model.Pom.Model
System.String:System.String
[ERROR]
[ERROR] Unhandled Exception: System.IO.FileNotFoundException: Could not load fil
e or assembly 'NMaven.Solution, Version=0.14.0.0, Culture=neutral, PublicKeyToke
n=null' or one of its dependencies. The system cannot find the file specified.
[ERROR] File name: 'NMaven.Solution, Version=0.14.0.0, Culture=neutral, PublicKe
yToken=null'
[ERROR]at NMaven.Plugin.Solution.SolutionMojo.Execute()
[ERROR]at NMaven.Plugin.AbstractMojo.Execute()
[ERROR]at NMaven.Plugin.Loader.PluginLoader.Main(String[] args)
[ERROR]
[ERROR] WRN: Assembly binding logging is turned OFF.
[ERROR] To enable assembly bind failure logging, set the registry value [HKLM\So
ftware\Microsoft\Fusion!EnableLog] (DWORD) to 1.
[ERROR] Note: There is some performance penalty associated with assembly bind
failure logging.
[ERROR] To turn this feature off, remove the registry value
[HKLM\Software\Microsoft\Fusion!EnableLog].
[ERROR]
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] NMAVEN-xxx-000
Embedded error: NMAVEN-063-000: Execution Path = C:\Documents and Settings\wsmoa
k\.m2\pab\gac_msil\NMaven.Plugin.Runner\0.14-maestro-1.5-M3__NMaven.Plugin, Comm
and = [parameterFile=C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml, assemblyF
ile=C:\Documents and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.1
4-maestro-1.5-M3__NMaven.Plugins\NMaven.Plugin.Solution.dll, mojoName=NMaven.Plu
gin.Solution.SolutionMojo, startProcessAssembly=C:\Documents and Settings\wsmoak
\.m2\pab\gac_msil\NMaven.Plugin.Loader\0.14-maestro-1.5-M3__NMaven.Plugin\NMaven
.Plugin.Loader.exe]
NMAVEN-040-001: Could not execute: Command = NMaven.Plugin.Runner.exe parameterF
ile=C:\DOCUME~1\wsmoak\LOCALS~1\Temp\Plugin34917.xml "assemblyFile=C:\Documents
and Settings\wsmoak\.m2\pab\gac_msil\NMaven.Plugin.Solution\0.14-maestro-1.5-M3_
_NMaven.Plugins\NMaven.Plugin.Solution.dll" mojoName=NMaven.Plugin.Solution.Solu
tionMojo "startProcessAssembly=C:\Documents and Settings\wsmoak\.m2\pab\gac_msil
\NMaven.Plugin.Loader\0.14-maestro-1.5-M3__NMaven.Plugin\NMaven.Plugin.Loader.ex
e", Result = 0
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 24 seconds
[INFO] Finished at: Mon Dec 10 14:36:15 MST 2007
[INFO] Final Memory: 5M/12M
[INFO]
C:\Temp\NMaven.Test>
{code}
--
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-3500) Include/Exclude of transitive dependencies depends on alphabetic order of module names.
Include/Exclude of transitive dependencies depends on alphabetic order of module names. --- Key: MNG-3500 URL: http://jira.codehaus.org/browse/MNG-3500 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Environment: $ mvn -v Maven version: 2.0.8-el4j-20071205 Java version: 1.5.0_15 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: David Bernhard Attachments: maven-issue.zip Consider five projects A, B, C, D, E with dependencies (--> = depends-on) A --> B, C B --> D excluding E C --> D D --> E In this scenario, as B comes before C alphabetically, dependency D of A is processed as in B and E is *not* included as a transitive dependency of A. Removing the exclusion in B and putting it in C makes E appear. To recreate the bug: I have attached a small demo zip; after building all five projects run "mvn exec:java -Dexec.mainClass=test.A" in /A. Note that E is not included in the classpath. (I got this result: file:/d:/Projects/maven-test/A/target/classes/ file:/d:/Projects/maven-test/A/target/test-classes file:/d:/m2repository/test/B/1.0-SNAPSHOT/X-1.0-SNAPSHOT.jar file:/d:/m2repository/test/D/1.0-SNAPSHOT/D-1.0-SNAPSHOT.jar file:/d:/m2repository/test/C/1.0-SNAPSHOT/C-1.0-SNAPSHOT.jar ) Remove the exclusion of E in B's pom and put it in C's in the same place. Then remake all projects - E is now included (Sample oputput: file:/d:/Projects/maven-test/A/target/classes/ file:/d:/Projects/maven-test/A/target/test-classes file:/d:/m2repository/test/B/1.0-SNAPSHOT/B-1.0-SNAPSHOT.jar file:/d:/m2repository/test/D/1.0-SNAPSHOT/D-1.0-SNAPSHOT.jar file:/d:/m2repository/test/E/1.0-SNAPSHOT/E-1.0-SNAPSHOT.jar file:/d:/m2repository/test/C/1.0-SNAPSHOT/C-1.0-SNAPSHOT.jar) -- 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: (NMAVEN-111) the visual studio installer plugin doesn't work on an empty local repository
the visual studio installer plugin doesn't work on an empty local repository Key: NMAVEN-111 URL: http://jira.codehaus.org/browse/NMAVEN-111 Project: NMaven Issue Type: Bug Reporter: Maria Catherine Tan This applies for https://svn.apache.org/repos/asf/incubator/nmaven/tags/STABLE-2007-12-16/ You currently have to run both "mvn install" on an NMaven project and to generate the solution file to get the following artifacts in your local repository for the vsinstaller plugin to succeed: * NMaven.Plugins:NMaven.Plugin.Settings.JavaBinding * NMaven.Plugins:NMaven.Plugin.Solution In addition, you have to manually install the dotnet-embedder WAR file using the following: mvn install:install-file -DgroupId=org.apache.maven.dotnet -DartifactId=dotnet-service-embedder -Dversion=0.14-maestro-1.5-M3 -Dpackaging=war -Dfile=%REPOSITORY%\org\apache\maven\dotnet\dotnet-service-embedder\0.14-maestro-1.5-M3\dotnet-service-embedder-0.14-maestro-1.5-M3.war -DpomFile=%REPOSITORY%\org\apache\maven\dotnet\dotnet-service-embedder\0.14-maestro-1.5-M3\dotnet-service-embedder-0.14-maestro-1.5-M3.pom (Assumes %REPOSITORY% is the location of the MPS releases repository - obviously not always available on the client... so maybe a POM is better). -- 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
