[jira] Closed: (MNG-3560) unable to use plugins that exist in multiple repositories
[
http://jira.codehaus.org/browse/MNG-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3560.
-
Resolution: Duplicate
Fix Version/s: (was: 2.2.x (to be reviewed))
Assignee: Brett Porter
> unable to use plugins that exist in multiple repositories
> -
>
> Key: MNG-3560
> URL: http://jira.codehaus.org/browse/MNG-3560
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.9
>Reporter: Maria Catherine Tan
>Assignee: Brett Porter
> Attachments: MNG-3560-maven-artifact.patch
>
>
> I created two test cases using maven-2.0.9
> A. Here's the settings for my first test case which builds successfully using
> mvn site or mvn site -up
> 1. Created two remote repository
> - sandbox has maven-project-info-reports-plugin 2.0.1
> - corporate has maven-project-info-reports-plugin 2.0
> 2. No maven-project-info-reports-plugin in my local repository
> 3. Access to central repository is disabled
> 4. The order in my settings.xml for the plugin repositories is sandbox first
> before corporate
>
> sandbox
> http://localhost:9091/repository/sandbox
>
>
> corporate
> http://localhost:9091/repository/corporate
>
> Result:
> * downloaded maven-project-info-reports-plugin 2.0 pom in corporate
> * check maven-project-info-reports-plugin 2.0 jar in sandbox
> * downloaded maven-project-info-reports-plugin 2.0 jar in corporate
> {code}
> mar...@kamejin:~/projects/testproject$ mvn site -up
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building testproject
> [INFO]task-segment: [site]
> [INFO]
>
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin:
> checking for updates from sandbox
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin:
> checking for updates from corporate
> [INFO] artifact org.apache.maven.plugins:maven-project-info-reports-plugin:
> checking for updates from central
> [WARNING] repository metadata for: 'artifact
> org.apache.maven.plugins:maven-project-info-reports-plugin' could not be
> retrieved from repository: central due to an error: Error transferring file
> [INFO] Repository 'central' will be blacklisted
> Downloading:
> http://localhost:9091/repository/corporate/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.pom
> 5K downloaded
> Downloading:
> http://localhost:9091/repository/sandbox/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.jar
> Downloading:
> http://localhost:9091/repository/corporate/org/apache/maven/plugins/maven-project-info-reports-plugin/2.0/maven-project-info-reports-plugin-2.0.jar
> [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [site:site]
> [INFO] Generating "Source Repository" report.
> [INFO] Generating "Issue Tracking" report.
> [INFO] Generating "About" report.
> [INFO] Generating "Project License" report.
> [INFO] Generating "Project Summary" report.
> [INFO] Generating "Dependencies" report.
> [INFO] Generating "Continuous Integration" report.
> [INFO] Generating "Project Team" report.
> [INFO] Generating "Mailing Lists" report.
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> B. Here's the settings for my second test case which replicate this issue
> 1. Created two remote repository
> - sandbox has maven-project-info-reports-plugin 2.0.1
> - corporate has maven-project-info-reports-plugin 2.0
> 2. No maven-project-info-reports-plugin in my local repository
> 3. Access to central repository is disabled
> 4. The order in my settings.xml for the plugin repositories is corporate
> first before sandbox
>
> corporate
> http://localhost:9091/repository/corporate
>
>
> sandbox
> http://localhost:9091/repository/sandbox
>
> Result:
> * downloaded maven-project-info-reports-plugin 2.0 pom in sandbox which
> it did not find and never tries to check the corporate where the pom could be
> found
> * downloaded maven-project-info-reports-plugin 2.0 jar in corporate
> {code}
> mar...@kamejin:~/projects/testproject$ mvn site -up
> [INFO] Scanning for projects...
> [INFO]
> ---
[jira] Closed: (MNG-3540) No plugin update from a staged repository
[ http://jira.codehaus.org/browse/MNG-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3540. - Resolution: Duplicate Fix Version/s: (was: 2.2.x (to be reviewed)) Assignee: Brett Porter working in 3.0-alpha-7 > No plugin update from a staged repository > - > > Key: MNG-3540 > URL: http://jira.codehaus.org/browse/MNG-3540 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: Maven 2.0.9, JDK6, both linux and windows >Reporter: Raphaël Piéroni >Assignee: Brett Porter > Attachments: with-nexus.txt, with-profile.txt > > > The archetype plugin depends on other projects. > One of them is staged along with the plugin in a > staged repository. > When i define that repository in settings.xml in a profile > which is always activated (both repository and pluginRepository) > and remove all references from archetype in my local repository. > I then call mvn archetype:create-from-project. > Maven downloads the plugin but don't download the dependencies > there it fails to instantiate the first used class from these dependencies. > The first attachment (with-profile.txt) holds the trace > When i define the repository in nexus (grouping first the repository then > central in one url) and defining that url as mirror of central in my setting, > Also using a fresh repository. I call the same goal, and it works. > The second attachment (with-nexus.txt) holds the trace. -- 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-3632) Clearer javadocs for MojoExecutionException and MojoFailureException
[ http://jira.codehaus.org/browse/MNG-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3632: -- Fix Version/s: (was: 2.2.x (to be reviewed)) 2.2.2 > Clearer javadocs for MojoExecutionException and MojoFailureException > > > Key: MNG-3632 > URL: http://jira.codehaus.org/browse/MNG-3632 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Plugin API >Affects Versions: 2.0.9 > Environment: N/A >Reporter: David J. M. Karlsen > Fix For: 2.2.2 > > > State the difference between MojoExecutionException and MojoFailureException > should be clearer in the javadocs (and maybe aslo on the site). > Maybe add a @see between the two as well. -- 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: (MNG-3330) reporting plugin poms are retrieved from the wrong repository
[ http://jira.codehaus.org/browse/MNG-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3330. - Resolution: Duplicate Fix Version/s: (was: 2.2.x (to be reviewed)) Assignee: Brett Porter (was: John Casey) > reporting plugin poms are retrieved from the wrong repository > - > > Key: MNG-3330 > URL: http://jira.codehaus.org/browse/MNG-3330 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.0.8 >Reporter: Dan Fabulich >Assignee: Brett Porter > Attachments: maven-test-report-plugin.zip > > > Pull the staged 2.4 into your local repo, and run surefire-report:report-only > on a POM configured to use 2.4. The build will fail. Try again, this time > running "mvn > org.apache.maven.plugins:maven-surefire-report-plugin:2.4:report-only" > - > this realm = > app0.child-container[org.apache.maven.plugins:maven-surefire-report-plugin] > urls[0] = > file:/c:/weirdlocalrepo/org/apache/maven/plugins/maven-surefire-report-plugin/2.4/maven-surefire-report-plugin-2.4.jar > urls[1] = > file:/c:/weirdlocalrepo/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar > Number of imports: 4 > import: org.codehaus.classworlds.en...@4891bb28 > import: org.codehaus.classworlds.en...@f8e44ca4 > import: org.codehaus.classworlds.en...@c51bc9e7 > import: org.codehaus.classworlds.en...@bece5185 > this realm = plexus.core > urls[0] = file:/C:/devtools/maven-2.0.7/lib/maven-core-2.0.7-uber.jar > Number of imports: 4 > import: org.codehaus.classworlds.en...@4891bb28 > import: org.codehaus.classworlds.en...@f8e44ca4 > import: org.codehaus.classworlds.en...@c51bc9e7 > import: org.codehaus.classworlds.en...@bece5185 > - > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Internal error in the plugin manager executing goal > 'org.apache.maven.plugins:maven-surefire-report-plugin:2.4:report-only': > Unable to find the mojo > 'org.apache.maven.plugins:maven-surefire-report-plugin:2.4:report-only' in > the p > lugin 'org.apache.maven.plugins:maven-surefire-report-plugin' > org/apache/maven/reporting/AbstractMavenReport -- 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-1945) project.getBuild().setSourceDirectory() should modify the compile source roots automatically
[
http://jira.codehaus.org/browse/MNG-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-1945:
--
Fix Version/s: (was: 2.2.x (to be reviewed))
Issues to be reviewed for 3.x
> project.getBuild().setSourceDirectory() should modify the compile source
> roots automatically
>
>
> Key: MNG-1945
> URL: http://jira.codehaus.org/browse/MNG-1945
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 2.0.1
>Reporter: Vincent Massol
>Assignee: Jason van Zyl
> Fix For: Issues to be reviewed for 3.x
>
>
> Here's the code that I have in the clover plugin right now:
> private void redirectSourceDirectories()
> {
> String oldSourceDirectory =
> this.project.getBuild().getSourceDirectory();
> this.project.getBuild().setSourceDirectory(
> this.cloverOutputSourceDirectory );
>
> // Maven2 limitation: changing the source directory doesn't change
> the compile source roots
> Iterator sourceRoots =
> this.project.getCompileSourceRoots().iterator();
> for (int i = 0; sourceRoots.hasNext(); i++)
> {
> String sourceRoot = (String)
> this.project.getCompileSourceRoots().get( i );
> if (sourceRoot.equals(oldSourceDirectory))
> {
> this.project.getCompileSourceRoots().remove( i );
> // Note: Ideally we should add the new compile source root at
> the same place as the
> // one we're removing but there's no API for this...
> this.project.addCompileSourceRoot(
> this.project.getBuild().getSourceDirectory() );
> }
> }
> }
> I believe this could be put in Maven core.
--
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: (MNG-3515) Allow several synonymous main artifacts, e.g. zip and tar.gz, just like you can have with a classifier
[ http://jira.codehaus.org/browse/MNG-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3515. - Resolution: Cannot Reproduce Fix Version/s: (was: 2.2.x (to be reviewed)) Assignee: Brett Porter Maven 2.2.0 doesn't have a problem with this at least - I was able to use the build-helper plugin to attach an artifact with no classifier and a different type and install to the repository together > Allow several synonymous main artifacts, e.g. zip and tar.gz, just like you > can have with a classifier > -- > > Key: MNG-3515 > URL: http://jira.codehaus.org/browse/MNG-3515 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: David Jencks >Assignee: Brett Porter > > It's possible for a project to generate several synonymous main artifacts > that are different packagings of the same content. The specific case I ran > across is in https://svn.apache.org/repos/asf/activemq/branches/activemq-4.1 > assembly module rev 646965. > The build happily constructs apache-activemq-4.1-SNAPSHOT.tar.gz/tar.bz2/zip > artifacts in target but does not install or deploy them. However if I add a > "bin" classifier all the artifacts are installed/deployed. > Another possible example that jdcasey suggested would be a project that > constructs both dll and so files. > I don't see how this could introduce any ambiguity since any dependency on a > non-jar artifact has to AFAIK specify the type explicitly. > -- 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: (MANTTASKS-182) deploy task tries to upload things it shouldn't.
deploy task tries to upload things it shouldn't. Key: MANTTASKS-182 URL: http://jira.codehaus.org/browse/MANTTASKS-182 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: deploy task Affects Versions: 2.1.0 Reporter: Aaron Kaplan When I run the deploy ant task, deploying to a nexus repository via http, the first thing it does is try to upload org/apache/maven/super-pom/2.0/super-pom-2.0.jar . This fails with a 400 error code because the file exists in the repository already. I posted this problem to maven-users but received no replies. http://mail-archives.apache.org/mod_mbox/maven-users/201004.mbox/%3c4bb60bca.5070...@aaronkaplan.info%3e -- 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: (MNG-4098) increase concurrency of parallel downloads
[ http://jira.codehaus.org/browse/MNG-4098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4098. -- Resolution: Fixed Fix Version/s: (was: 3.x / Backlog) 3.0-alpha-7 Assignee: Benjamin Bentmann > increase concurrency of parallel downloads > -- > > Key: MNG-4098 > URL: http://jira.codehaus.org/browse/MNG-4098 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.1.0 >Reporter: Brett Porter >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-7 > > > this started out in 2.1.0. To avoid file locking issues parallelism was > limited to artifacts in different groups. However, I'm now of the opinion > this is not necessary and we should investigate allowing jars to be > downloaded in parallel regardless of group. > Don has also suggested some improvements to the synchronization that might > make the code cleaner and faster, which I'll look for him to add here. -- 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: (MNG-4623) model parsing errors can be less helpful in Maven 3
[
http://jira.codehaus.org/browse/MNG-4623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4623.
--
Resolution: Fixed
Fix Version/s: (was: 3.0-beta-2)
3.0-beta-1
Assignee: Benjamin Bentmann
Fixed error message in
[r931492|http://svn.apache.org/viewvc?view=revision&revision=931492].
Still to be investigated is a potential regression in Modello. The error about
the duplicate element is generated from a parser invocation in non-strict mode
but in non-strict mode errors like that shouldn't be produced at all.
> model parsing errors can be less helpful in Maven 3
> ---
>
> Key: MNG-4623
> URL: http://jira.codehaus.org/browse/MNG-4623
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Errors
>Affects Versions: 3.0-alpha-7
>Reporter: Brett Porter
>Assignee: Benjamin Bentmann
> Fix For: 3.0-beta-1
>
>
> I accidentally left out the tag around extensions:
> {code:xml}
>
> ...
>
>
> org.apache.maven.wagon
> wagon-ssh-external
> 1.0-beta-6
>
>
> ...
>
> {code}
> In Maven 2.2.1 the error was long winded but included:
> {code}
> Reason: Parse error reading POM. Reason: Unrecognised tag: 'extensions'
> (position: START_TAG seen ...\n ... @18:15) for
> project unknown at .../pom.xml
> {code}
> In Maven 3.0-SNAPSHOT, the error is:
> {code}
> [ERROR] Non-parseable POM .../pom.xml: Duplicated tag: 'artifactId'
> (position: START_TAG seen ...\n ... @21:19) ->
> [Help 2]
> {code}
> While it points at the right section, the first is much more accurate about
> what the problem was
--
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-4624) filtered not applied in a fileSet using a constraining include
filtered not applied in a fileSet using a constraining include
--
Key: MNG-4624
URL: http://jira.codehaus.org/browse/MNG-4624
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 2.2.1
Reporter: Matthieu Scholler
Below will apply the filters on the relevant files:
${project.basedir}/src/main/package
true
**
but not the following one:
${project.basedir}/src/main/package
true
*.*
In both cases the target files are present but no filter is applied in the
second 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] Commented: (MNG-4624) filtered not applied in a fileSet using a constraining include
[
http://jira.codehaus.org/browse/MNG-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216989#action_216989
]
Matthieu Scholler commented on MNG-4624:
I just realized that I should have created this issue in Maven 2.x Assembly
Plugin project,
Sorry about that.
> filtered not applied in a fileSet using a constraining include
> --
>
> Key: MNG-4624
> URL: http://jira.codehaus.org/browse/MNG-4624
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 2.2.1
>Reporter: Matthieu Scholler
>
> Below will apply the filters on the relevant files:
>
> ${project.basedir}/src/main/package
>
> true
>
> **
>
>
> but not the following one:
>
> ${project.basedir}/src/main/package
>
> true
>
> *.*
>
>
> In both cases the target files are present but no filter is applied in the
> second 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] Moved: (MASSEMBLY-484) filtered not applied in a fileSet using a constraining include
[
http://jira.codehaus.org/browse/MASSEMBLY-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann moved MNG-4624 to MASSEMBLY-484:
--
Complexity: (was: Intermediate)
Affects Version/s: (was: 2.2.1)
Key: MASSEMBLY-484 (was: MNG-4624)
Project: Maven 2.x Assembly Plugin (was: Maven 2 & 3)
> filtered not applied in a fileSet using a constraining include
> --
>
> Key: MASSEMBLY-484
> URL: http://jira.codehaus.org/browse/MASSEMBLY-484
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Reporter: Matthieu Scholler
>
> Below will apply the filters on the relevant files:
>
> ${project.basedir}/src/main/package
>
> true
>
> **
>
>
> but not the following one:
>
> ${project.basedir}/src/main/package
>
> true
>
> *.*
>
>
> In both cases the target files are present but no filter is applied in the
> second 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] Commented: (MNG-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216990#action_216990 ] Tobias Sarnowski commented on MNG-3092: --- We are also very interested how the status of this very serious issue is. I tested it with a recent subversion snapshot of maven3 and this issue is still consistent. Will there be any fix in the near future or is it already possible with a special configuration? > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: http://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 3.0-beta-1 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-4611) 3.0-alpha7 password decryption log verbosity
[
http://jira.codehaus.org/browse/MNG-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216993#action_216993
]
Yoav Landman commented on MNG-4611:
---
If the password escape mechanism is broken, how is it not a bug? There is
really nothing "improper" about the password used, and it is currently the only
way to centrally enforce security and to have zero client-side password
generation or clear text keys on the client.
> 3.0-alpha7 password decryption log verbosity
>
>
> Key: MNG-4611
> URL: http://jira.codehaus.org/browse/MNG-4611
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: Dale Wyttenbach
>Assignee: Benjamin Bentmann
>
> The log verbosity of password decryption in 3.0-alpha7 that makes the mvn -X
> option effectively unusable. The password I've got in my settings.xml file
> looks like this:
> {DESede}y+qq...==
> This is an Artifactory setup password and it does work, however mvn -X logs
> exceptions about it so frequently that it makes -X almost impossible to use.
> Is there some way I can suppress this behavior through configuration? The
> exception that it logs over and over again is:
> [DEBUG] Failed to decrypt password for server central:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> ...
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
> ... 47 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCOMPILER-123) No way to set compiler arguments/options for Eclipse compiler
No way to set compiler arguments/options for Eclipse compiler
-
Key: MCOMPILER-123
URL: http://jira.codehaus.org/browse/MCOMPILER-123
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Lóránt Pintér
I have a problem with setting compiler options for the Eclipse compiler. I
tried to do the following:
{code:xml}
org.apache.maven.plugins
maven-compiler-plugin
2.2
eclipse
1.6
1.6
utf-8
ignore
org.codehaus.plexus
plexus-compiler-eclipse
1.8
{code}
It should be okay, as this is in EclipseJavaCompiler:
{code:java}
// compiler-specific extra options override anything else in the config
object...
Map extras = config.getCustomCompilerArguments();
if ( extras != null && !extras.isEmpty() )
{
settings.putAll( extras );
}
// ...
// --
// Compile!
// --
CompilerOptions options = new CompilerOptions( settings );
Compiler compiler = new Compiler( env, policy, options, requestor,
problemFactory );
{code}
But the problem is that all keys in the map are prefixed with "-" in
AbstractCompilerMojo:
{code:java}
Map effectiveCompilerArguments = getCompilerArguments();
String effectiveCompilerArgument = getCompilerArgument();
if ( ( effectiveCompilerArguments != null ) || ( effectiveCompilerArgument !=
null ) )
{
LinkedHashMap cplrArgsCopy = new LinkedHashMap();
if ( effectiveCompilerArguments != null )
{
for ( Map.Entry me :
effectiveCompilerArguments.entrySet() )
{
String key = (String) me.getKey();
String value = (String) me.getValue();
if ( !key.startsWith( "-" ) )
{
key = "-" + key;
}
cplrArgsCopy.put( key, value );
}
}
if ( !StringUtils.isEmpty( effectiveCompilerArgument ) )
{
cplrArgsCopy.put( effectiveCompilerArgument, null );
}
compilerConfiguration.setCustomCompilerArguments( cplrArgsCopy );
}
{code}
So what actually gets into the Map for CompilerOptions is this:
{code}
-org.eclipse.jdt.core.compiler.problem.missingSerialVersion = ignore
{code}
Instead of:
{code}
org.eclipse.jdt.core.compiler.problem.missingSerialVersion = ignore
{code}
The incorrect setting name is then silently discarded by ECJ.
I cannot use this either:
{code:xml}
eclipse
1.6
1.6
utf-8
-warn:-serial
{code}
...because "-warn:-serial" is not passed as a command-line argument, but it is
also added to the Map for CompilerOptions:
{code:java}
if ( !StringUtils.isEmpty( effectiveCompilerArgument ) )
{
cplrArgsCopy.put( effectiveCompilerArgument, null );
}
compilerConfiguration.setCustomCompilerArguments( cplrArgsCopy );
{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] Commented: (MNG-4611) 3.0-alpha7 password decryption log verbosity
[
http://jira.codehaus.org/browse/MNG-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216994#action_216994
]
Benjamin Bentmann commented on MNG-4611:
This issue is about the "log verbosity". The log output is fine, as there is an
issue with the password used.
> 3.0-alpha7 password decryption log verbosity
>
>
> Key: MNG-4611
> URL: http://jira.codehaus.org/browse/MNG-4611
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: Dale Wyttenbach
>Assignee: Benjamin Bentmann
>
> The log verbosity of password decryption in 3.0-alpha7 that makes the mvn -X
> option effectively unusable. The password I've got in my settings.xml file
> looks like this:
> {DESede}y+qq...==
> This is an Artifactory setup password and it does work, however mvn -X logs
> exceptions about it so frequently that it makes -X almost impossible to use.
> Is there some way I can suppress this behavior through configuration? The
> exception that it logs over and over again is:
> [DEBUG] Failed to decrypt password for server central:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> ...
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
> ... 47 more
--
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-4625) Interpolation of settings.xml fails if an expression's value contains XML markup
Interpolation of settings.xml fails if an expression's value contains XML markup
Key: MNG-4625
URL: http://jira.codehaus.org/browse/MNG-4625
Project: Maven 2 & 3
Issue Type: Bug
Components: Settings
Affects Versions: 3.0-alpha-7
Reporter: Benjamin Bentmann
Using a {{settings.xml}} like
{code:xml}
test
${test.prop}
{code}
the invocation
{noformat}
mvn validate -D "test.prop=&x=y"
{noformat}
fails with
{noformat}
[ERROR] Error executing Maven.
[ERROR] 1 problem was encountered while building the effective settings
[ERROR] Failed to interpolate settings: entity reference name can not contain
character =' (position: START_TAG seen ...&x=... @7:22) @
{noformat}
--
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-4625) Interpolation of settings.xml fails if an expression's value contains XML markup
[
http://jira.codehaus.org/browse/MNG-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4625:
---
Fix Version/s: 3.0-beta-1
> Interpolation of settings.xml fails if an expression's value contains XML
> markup
>
>
> Key: MNG-4625
> URL: http://jira.codehaus.org/browse/MNG-4625
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.0-alpha-7
>Reporter: Benjamin Bentmann
> Fix For: 3.0-beta-1
>
>
> Using a {{settings.xml}} like
> {code:xml}
>
>
>
> test
>
> ${test.prop}
>
>
>
>
> {code}
> the invocation
> {noformat}
> mvn validate -D "test.prop=&x=y"
> {noformat}
> fails with
> {noformat}
> [ERROR] Error executing Maven.
> [ERROR] 1 problem was encountered while building the effective settings
> [ERROR] Failed to interpolate settings: entity reference name can not contain
> character =' (position: START_TAG seen ...&x=... @7:22) @
> {noformat}
--
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: (MNG-3657) Ampersand characters cannot be used in profiles.xml (XML parsed twice)
[ http://jira.codehaus.org/browse/MNG-3657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-3657. -- Resolution: Duplicate Fix Version/s: (was: 3.0-beta-1) Assignee: Benjamin Bentmann > Ampersand characters cannot be used in profiles.xml (XML parsed twice) > -- > > Key: MNG-3657 > URL: http://jira.codehaus.org/browse/MNG-3657 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Profiles >Affects Versions: 2.0.9 > Environment: OS X (Leopard), Ubunut 8.04 >Reporter: Marcus Spiegel >Assignee: Benjamin Bentmann > Attachments: stacktrace.txt > > > It is not possible to use ampersand characters in the profiles.xml because > this is evaluated twice. > My case: > In my profiles.xml, I specify a database connection URL for MySQL where the > ampersand character is > used for separating connection parameters: > jdbc:mysql://localhost/myproject?autoReconnect=true&useUnicode=true&characterEncoding=utf8 > Because of the XML format, amperands are specified as "&". However, this > results in an exception (see attached > excerpt of the stack trace). Is is also not possible to specify the URL in a > CDATA section (or even in a combination > of & and CDATA). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-424) poor performance of dependencySet in assembly descriptor (compared to using maven-dependency-plugin + fileSet)
[
http://jira.codehaus.org/browse/MASSEMBLY-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217000#action_217000
]
Arnaud Heritier commented on MASSEMBLY-424:
---
New set of tests always based on
http://svn.exoplatform.org/projects/jcr-benchmark/trunk/ with mvn clean install
-o
Env :
Apache Maven 3.0-alpha-7 (r921173; 2010-03-09 23:31:07+0100)
Java version: 1.6.0_17
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"
Each test is done twice and the best value is taken.
with assembly plugin 2.1 : 11.022s
with assembly plugin 2.2-beta-1 : 11.670s
with assembly plugin 2.2-beta-2 : 19.772s
with assembly plugin 2.2-beta-3 : 30.480s
with assembly plugin 2.2-beta-4 : 30.049s
with assembly plugin 2.2-beta-5 : 30.927s
with assembly plugin 2.2-beta-6-SNAPSHOT : 31.460s
with assembly plugin 2.2-beta-6-SNAPSHOT with p-u 2.0.2 : 23.964s
It's better but not perfect.
I tried to upgrade p-u to 2.0.3, p-io to 1.0-alpha-5,
maven-common-artifact-filters to 1.2 ... but it didn't changed the result.
> poor performance of dependencySet in assembly descriptor (compared to using
> maven-dependency-plugin + fileSet)
> --
>
> Key: MASSEMBLY-424
> URL: http://jira.codehaus.org/browse/MASSEMBLY-424
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-4
> Environment: maven 2.1.0, java 6u13, os x 10.5.6, macbook pro 5400rpm
> disk
>Reporter: Cameron Fieber
>Priority: Critical
>
> The performance of the dependencySet element in the assembly descriptor is
> significantly worse than achieving the equivalent result by doing an
> execution of dependency:copy-dependencies and including the
> target/dependencies folder as a fileSet in the assembly descriptor
> replacing:
>
>...
>
>
> lib
>
>
>...
>
> with:
>
> ...
>
> ${project.build.directory}/dependency
> lib
>
> ...
>
> and (in pom.xml):
> ...
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> package
>
> copy-dependencies
>
>
> runtime
>
>
>
>
>
> org.apache.maven.plugins
> maven-assembly-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: (MASSEMBLY-480) Files with ending with a .formatted extention not cleaned up
[ http://jira.codehaus.org/browse/MASSEMBLY-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217002#action_217002 ] Reimo Daum commented on MASSEMBLY-480: -- Is there any workaround for this issue? > Files with ending with a .formatted extention not cleaned up > > > Key: MASSEMBLY-480 > URL: http://jira.codehaus.org/browse/MASSEMBLY-480 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-5 > Environment: dev on windows, build runs on Linux >Reporter: J T > > In the target directory below my project directory a folder called > archive-tmp is created and never cleaned up. In it are directories ending in > .formatted and files that were being copied as part of this task ending in > .formatted. Also in the primary directory where the output of the build is > placed there are tons of .formatted files co-mingled with regular files we > want to output. Looking through some of the code I think the .formatted > extention appears to be used to create temp files as things are copied around > but I'm not sure why they are never being cleaned up. We use the outputed > files placed in the target directory so this is causing us to get a bunch of > unwanted files as part of our build output. -- 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-4626) Avoid cleartext passwords over http
Avoid cleartext passwords over http --- Key: MNG-4626 URL: http://jira.codehaus.org/browse/MNG-4626 Project: Maven 2 & 3 Issue Type: Improvement Components: General Affects Versions: 3.0-alpha-7 Reporter: Brendan Lawlor The current encryption scheme implemented by Maven avoids the use of cleartext passwords on local files by allowing them to be encrypted locally and decrypted just before the maven client requests from or deploys to a central artifact repository. I would like to suggest that the Maven team replicate the idea adopted by Artifactory, where passwords are _transmitted_ encrypted, and only decrypted on the server side by the repository. Requests and deployments are made over http and transmitted in the clear. Where the passwords are system passwords integrated to Active Directory or similar using LDAP, this is not an option even within a company's LAN. I like the idea of where Nexus and the Maven development stack in general is going (I listened to Jason's seminar recently and I'm keen on much of where you are going). But passwords in the clear over http is a showstopper and I'm surprised you haven't already borrowed this idea from the competition. Another irritating side effect of maven's insistence in using cleartext passwords has been mentioned by a colleague of mine in MNG-4611. We currently use Artifactory for EXACTLY this reason (the password encryption) and maven logs loudly about the fact that the passwords are encrypted. -- 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-3891) Modify maven-toolchain to look in ${maven.home}/conf/toolchains.xml and in ${user.home}/.m2/toolchains.xml
[
http://jira.codehaus.org/browse/MNG-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-3891:
---
Fix Version/s: (was: 3.0-beta-1)
3.x / Backlog
> Modify maven-toolchain to look in ${maven.home}/conf/toolchains.xml and in
> ${user.home}/.m2/toolchains.xml
> ---
>
> Key: MNG-3891
> URL: http://jira.codehaus.org/browse/MNG-3891
> Project: Maven 2 & 3
> Issue Type: Improvement
>Affects Versions: 2.0.9
>Reporter: Marco Lessard
> Fix For: 3.x / Backlog
>
>
> Actually, we can only specify the toolchains.xml in
> ${user.home}/.m2/toolchains.xml.
> However, like for the settings.xml, it would be very convenient to specify a
> default toolchains.xml in ${maven.home}/conf/toolchains.xml
> The idea is : If there is NO *${user.home}/.m2/toolchains.xml*,
> then uses *${maven.home}/conf/toolchains.xml*,
> otherwise NONE defined.
> Merging both would also be good but not necessary.
> The change is very simple. Edit the file
> *maven-toolchain\src\main\java\org\apache\maven\toolchain\DefaultToolchainManager.java*
> and replace
> {code}
> private PersistedToolchains readToolchainSettings() throws
> MisconfiguredToolchainException {
> File tch = new File(System.getProperty("user.home"),
> ".m2/toolchains.xml");
> if (tch.exists()) {
>MavenToolchainsXpp3Reader reader = new MavenToolchainsXpp3Reader();
>...
> {code}
> by
> {code}
> private PersistedToolchains readToolchainSettings() throws
> MisconfiguredToolchainException {
> File tch = null;
> tch = new File(System.getProperty("user.home"), ".m2/toolchains.xml");
> if (tch == null || !tch.exists()) {
> tch = new File(System.getProperty("maven.home"),
> "conf/toolchains.xml");
> }
> if (tch.exists()) {
> MavenToolchainsXpp3Reader reader = new MavenToolchainsXpp3Reader();
> ...
> {code}
> I did that on my local environment by compiling this 2.0.11-SNAPSHOT class
> and integrating it in my maven-2.0.9-uber.jar and it works perfectly.
--
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-4611) 3.0-alpha7 password decryption log verbosity
[
http://jira.codehaus.org/browse/MNG-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217010#action_217010
]
Brendan Lawlor commented on MNG-4611:
-
I've raised MNG-4626 as a more general but related point. I think the notion of
encrypting 'properly' as suggested above is a problem in the first place. The
encryption mechanism used by Dale and provided for by Yoav in Artifactory is
clearly the sensible approach to password protection in maven, and maven/nexus
should really be doing the same thing.
> 3.0-alpha7 password decryption log verbosity
>
>
> Key: MNG-4611
> URL: http://jira.codehaus.org/browse/MNG-4611
> Project: Maven 2 & 3
> Issue Type: Bug
>Reporter: Dale Wyttenbach
>Assignee: Benjamin Bentmann
>
> The log verbosity of password decryption in 3.0-alpha7 that makes the mvn -X
> option effectively unusable. The password I've got in my settings.xml file
> looks like this:
> {DESede}y+qq...==
> This is an Artifactory setup password and it does work, however mvn -X logs
> exceptions about it so frequently that it makes -X almost impossible to use.
> Is there some way I can suppress this behavior through configuration? The
> exception that it logs over and over again is:
> [DEBUG] Failed to decrypt password for server central:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException:
> org.sonatype.plexus.components.cipher.PlexusCipherException:
> java.lang.ArrayIndexOutOfBoundsException
> ...
> Caused by: java.lang.ArrayIndexOutOfBoundsException
> at java.lang.System.arraycopy(Native Method)
> at
> org.sonatype.plexus.components.cipher.PBECipher.decrypt64(PBECipher.java:175)
> ... 47 more
--
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: (MNG-4625) Interpolation of settings.xml fails if an expression's value contains XML markup
[
http://jira.codehaus.org/browse/MNG-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4625.
--
Resolution: Fixed
Assignee: Benjamin Bentmann
Fixed in [r931545|http://svn.apache.org/viewvc?view=revision&revision=931545].
> Interpolation of settings.xml fails if an expression's value contains XML
> markup
>
>
> Key: MNG-4625
> URL: http://jira.codehaus.org/browse/MNG-4625
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.0-alpha-7
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-beta-1
>
>
> Using a {{settings.xml}} like
> {code:xml}
>
>
>
> test
>
> ${test.prop}
>
>
>
>
> {code}
> the invocation
> {noformat}
> mvn validate -D "test.prop=&x=y"
> {noformat}
> fails with
> {noformat}
> [ERROR] Error executing Maven.
> [ERROR] 1 problem was encountered while building the effective settings
> [ERROR] Failed to interpolate settings: entity reference name can not contain
> character =' (position: START_TAG seen ...&x=... @7:22) @
> {noformat}
--
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-3835) Incorrect parameter injection
[
http://jira.codehaus.org/browse/MNG-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217017#action_217017
]
Matthew Beermann commented on MNG-3835:
---
Brett, can you clarify a little? I hadn't realized that the nested objects
don't need to have getters and setters... plain old field injection didn't seem
to work when I first tried it, but that's been ages ago now.
> Incorrect parameter injection
> -
>
> Key: MNG-3835
> URL: http://jira.codehaus.org/browse/MNG-3835
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 2.0.9, 2.1.0-M1
> Environment: Maven version: 2.1.0-M1
> Java version: 1.5.0_16
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "x86" family: "windows"
>Reporter: Matthew Beermann
>Assignee: Brett Porter
>Priority: Critical
>
> Consider the following configuration fragment. Header is a bean with a list
> of values; Value is a bean with a map of directives.
>
>
> Bundle-SymbolicName
>
>
> ${project.name}
>
> true
>
>
>
>
>
> Eclipse-LazyStart
>
>
> true
>
>
>
>
> Eclipse-BuddyPolicy
>
>
> registered
>
>
>
>
> Require-Bundle
> true
>
>
>
> com.cerner.client.wrapper.osgi.jaxb
>
>
>
> com.cerner.client.wrapper.osgi.msvc
>
>
>
>
>
> Eclipse-RegisterBuddy
>
>
>
> com.cerner.client.wrapper.osgi.jaxb
>
>
>
>
> But here's what actually gets sent to the mojo (output from mvn -X):
> [DEBUG] (s) name = Bundle-SymbolicName
> [DEBUG] (s) name = jaxb-clinrpt-template
> [DEBUG] (s) directives = {singleton=true}
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@1cb048e]
> [DEBUG] (s) name = Eclipse-LazyStart
> [DEBUG] (s) name = true
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@1983ad7]
> [DEBUG] (s) name = Eclipse-BuddyPolicy
> [DEBUG] (s) name = registered
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@13f348b]
> [DEBUG] (s) name = Require-Bundle
> [DEBUG] (s) append = true
> [DEBUG] (s) name = com.cerner.client.wrapper.osgi.jaxb
> [DEBUG] (s) name = com.cerner.client.wrapper.osgi.msvc
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@92997e,
> com.cerner.engineering.maven.osgi.va...@9b601d]
> [DEBUG] (s) name = Eclipse-RegisterBuddy
> [DEBUG] (s) name = com.cerner.client.wrapper.osgi.jaxb
> [DEBUG] (s) directives = {singleton=true}
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@c3362f]
> Note the second, duplicate occurance of at the end, associated
> with the wrong header. Where on earth did that come from? It wasn't in the
> configuration. Even more mysteriously, if you rearrange the order and put the
> offending at the end of the list, the problem vanishes.
> I'm not quite sure what's going on here, but it's causing some of our custom
> goals to produce invalid output (GIGO).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-279) Javadoc plugin doesn't set dependencies correctly when pom uses classifiers
Javadoc plugin doesn't set dependencies correctly when pom uses classifiers --- Key: MJAVADOC-279 URL: http://jira.codehaus.org/browse/MJAVADOC-279 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.6.1 Environment: Maven 2.2.1, Windows XP Reporter: James Nichols Create a project which has dependencies like: com.xxx mydep 1.3.1 core com.xxx mydep 1.3.1 util This will add dependencies to the javadoc options file something like this: classpath 'C:/dev/target/classes;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar' where it should yield: classpath 'C:/dev/target/classes;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-util.jar' i.e. the classifier for the artifacts is being ignored. This causes various dependencies to be missing from the javadoc task which will eventually fail with: java.lang.NullPointerException at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67) at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29) at com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:441) at com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:386) at com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:424) at com.sun.tools.doclets.internal.toolkit.util.ClassTree.processType(ClassTree.java:162) at com.sun.tools.doclets.internal.toolkit.util.ClassTree.buildTree(ClassTree.java:114) at com.sun.tools.doclets.internal.toolkit.util.ClassTree.(ClassTree.java:73) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:104) at com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) at com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) at com.sun.tools.javadoc.Start.begin(Start.java:128) at com.sun.tools.javadoc.Main.execute(Main.java:41) at com.sun.tools.javadoc.Main.main(Main.java:31) -- 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-4627) error in opening zip file
error in opening zip file - Key: MNG-4627 URL: http://jira.codehaus.org/browse/MNG-4627 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 2.2.1 Reporter: Rafal Rusin Maven sometimes downloads artifact from repository (a jar), but the repository is no longer there (often html page is fetched). Maven thinks it's a proper jar and continues build. Later, it fails with error in opening zip file. Reproduction steps: download: http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X/ rev. 931628 do mvn install. It ends with this: Downloading: https://maven-repository.dev.java.net/nonav/repository//xalan/jars/xalan-2.7.1.jar 347b downloaded (xalan-2.7.1.jar) [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '58bd24b3f26e94ee0bcb402a2abf301d3456e146'; remote = 'https://maven-repository.dev.java.net/nonav/repository//xalan/jars/xalan-2.7.1.jar 347b downloaded (xalan-2.7.1.jar) [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = '58bd24b3f26e94ee0bcb402a2abf301d3456e146'; remote = 'http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4627) error in opening zip file
[
http://jira.codehaus.org/browse/MNG-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4627.
--
Resolution: Duplicate
Assignee: Benjamin Bentmann
> error in opening zip file
> -
>
> Key: MNG-4627
> URL: http://jira.codehaus.org/browse/MNG-4627
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.2.1
>Reporter: Rafal Rusin
>Assignee: Benjamin Bentmann
>
> Maven sometimes downloads artifact from repository (a jar), but the
> repository is no longer there (often html page is fetched).
> Maven thinks it's a proper jar and continues build. Later, it fails with
> error in opening zip file.
> Reproduction steps:
> download:
> http://svn.apache.org/repos/asf/ode/branches/APACHE_ODE_1.X/ rev. 931628
> do mvn install. It ends with this:
> Downloading:
> https://maven-repository.dev.java.net/nonav/repository//xalan/jars/xalan-2.7.1.jar
> 347b downloaded (xalan-2.7.1.jar)
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> '58bd24b3f26e94ee0bcb402a2abf301d3456e146'; remote = ' Downloading:
> https://maven-repository.dev.java.net/nonav/repository//xalan/jars/xalan-2.7.1.jar
> 347b downloaded (xalan-2.7.1.jar)
> [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
> '58bd24b3f26e94ee0bcb402a2abf301d3456e146'; remote = ' [INFO] [compiler:compile {execution: default-compile}]
> [INFO] Compiling 87 source files to /home/joker/ode-1.X/utils/target/classes
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Compilation failure
> error: error reading
> /home/joker/.m2/repository/xalan/xalan/2.7.1/xalan-2.7.1.jar; error in
> opening zip file
--
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: (MCHECKSTYLE-136) Running checkstyle:check on the top-level POM of a multi-module build fails
[
http://jira.codehaus.org/browse/MCHECKSTYLE-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217048#action_217048
]
oliver.burkhalter commented on MCHECKSTYLE-136:
---
With the configuration {{skipExec}} the build doesn't throw anymore this error
message, thanks for the tipp!
> Running checkstyle:check on the top-level POM of a multi-module build fails
> ---
>
> Key: MCHECKSTYLE-136
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-136
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Tim Moore
>
> {noformat}
> [INFO] [checkstyle:check]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] basedir /Users/tmoore/Projects/atlassian/JST/src/main/java does not
> exist
> [INFO]
>
> [INFO] Trace
> java.lang.IllegalStateException: basedir
> /Users/tmoore/Projects/atlassian/JST/src/main/java does not exist
> at
> org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:550)
> at
> org.codehaus.plexus.util.FileUtils.getFileAndDirectoryNames(FileUtils.java:1717)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1645)
> at org.codehaus.plexus.util.FileUtils.getFileNames(FileUtils.java:1627)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1601)
> at org.codehaus.plexus.util.FileUtils.getFiles(FileUtils.java:1584)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.getFilesToProcess(DefaultCheckstyleExecutor.java:407)
> at
> org.apache.maven.plugin.checkstyle.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:89)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:393)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> {noformat}
> This is without an existing report. It appears to be a regression of
> MCHECKSTYLE-25 and MCHECKSTYLE-26
> Probably introduced when the check mojo was refactored to invoke checkstyle
> directly rather than executing the report
> (http://svn.apache.org/viewvc?view=revision&revision=836274)
--
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-4628) ReactorArtifactRepository is not setup soon enough for AbstractMavenLifecycleParticipant#afterProjectsRead
ReactorArtifactRepository is not setup soon enough for AbstractMavenLifecycleParticipant#afterProjectsRead -- Key: MNG-4628 URL: http://jira.codehaus.org/browse/MNG-4628 Project: Maven 2 & 3 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 3.0-alpha-7 Reporter: Igor Fedorenko This was originally reported as https://issues.sonatype.org/browse/TYCHO-404 but will affect other build lifecycle participants as well. In short, ReactorArtifactRepository is setup too late during build bootstrap and AbstractMavenLifecycleParticipant#afterProjectsRead are not able to resolve inter-module dependencies as a result. I will commit trivial patch shortly. -- 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: (MNG-4628) ReactorArtifactRepository is not setup soon enough for AbstractMavenLifecycleParticipant#afterProjectsRead
[ http://jira.codehaus.org/browse/MNG-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Fedorenko closed MNG-4628. --- Resolution: Fixed Fixed in [r931641|http://svn.apache.org/viewvc?view=revision&revision=931641] > ReactorArtifactRepository is not setup soon enough for > AbstractMavenLifecycleParticipant#afterProjectsRead > -- > > Key: MNG-4628 > URL: http://jira.codehaus.org/browse/MNG-4628 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-7 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > > This was originally reported as https://issues.sonatype.org/browse/TYCHO-404 > but will affect other build lifecycle participants as well. In short, > ReactorArtifactRepository is setup too late during build bootstrap and > AbstractMavenLifecycleParticipant#afterProjectsRead are not able to resolve > inter-module dependencies as a result. I will commit trivial patch shortly. -- 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-4628) ReactorArtifactRepository is not setup soon enough for AbstractMavenLifecycleParticipant#afterProjectsRead
[ http://jira.codehaus.org/browse/MNG-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-4628: --- Fix Version/s: 3.0-beta-1 > ReactorArtifactRepository is not setup soon enough for > AbstractMavenLifecycleParticipant#afterProjectsRead > -- > > Key: MNG-4628 > URL: http://jira.codehaus.org/browse/MNG-4628 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-7 >Reporter: Igor Fedorenko >Assignee: Igor Fedorenko > Fix For: 3.0-beta-1 > > > This was originally reported as https://issues.sonatype.org/browse/TYCHO-404 > but will affect other build lifecycle participants as well. In short, > ReactorArtifactRepository is setup too late during build bootstrap and > AbstractMavenLifecycleParticipant#afterProjectsRead are not able to resolve > inter-module dependencies as a result. I will commit trivial patch shortly. -- 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: (MPIR-188) Maven constructs wrong classpath element
[ http://jira.codehaus.org/browse/MPIR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217065#action_217065 ] David Biesack commented on MPIR-188: Thanks for clarifying the version number issue. adding to my confusion was the fact that simply running mvn from a 2.0.9 install worked, then only changing to run from a 2.2.1 install failed; both had the same configuration and ~/.m2/settings.xml My log also showed the failed build was including maven-project-info-reports-plugin/2.1 . [DEBUG] The following artifacts were filtered out for plugin: org.apache.maven.plugins:maven-project-info-reports-plugin:2.1 because they're already in the core of Maven: org.apache.maven:maven-artifact:jar:2.0.6:runtime org.apache.maven:maven-artifact-manager:jar:2.0.6:runtime org.apache.maven:maven-model:jar:2.0.6:runtime org.apache.maven:maven-plugin-api:jar:2.0.6:runtime org.apache.maven:maven-project:jar:2.0.6:runtime org.apache.maven:maven-repository-metadata:jar:2.0.6:runtime org.apache.maven:maven-settings:jar:2.0.6:runtime org.apache.maven.reporting:maven-reporting-api:jar:2.0.6:runtime org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-3:runtime org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-3:runtime org.apache.maven.wagon:wagon-file:jar:1.0-beta-3:runtime org.apache.maven.wagon:wagon-http-lightweight:jar:1.0-beta-3:runtime org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-11:runtime org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:runtime We have an Artifactory server in the middle; it was an old version. I upgraded it to 2.2.2 and also purged its entire repo1-cache and now my build works as expected. > Maven constructs wrong classpath element > > > Key: MPIR-188 > URL: http://jira.codehaus.org/browse/MPIR-188 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Bug > Components: dependencies >Affects Versions: 2.1 >Reporter: David Biesack >Assignee: Benjamin Bentmann > Attachments: MNG-4613.tar > > > We run Maven 2 builds from Cruise Control; the projects each build with the > same targets: > clean jar:test-jar site-deploy deploy > Unfortunately, this causes the unit tests to run twice, once for site-deploy > (surefire reports) and once for deploy. > Under 2.0.9 this was not a problem, but we recently switched to 2.2.1 and > some tests were failing > because the test classpath constructed for the first set of test runs differs > from the classpath for the second. > In the pom file, there is a dependency from the current project to both the > normal jar *and* the test jar of > another project: > > com.sas.other > sas.other > 1.0-SNAPSHOT > test-jar > test > > > com.sas.other > sas.other > 1.0-SNAPSHOT > > The first test run contains > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT-tests.jar > ... > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > However, when we build with Maven 2.2.1, the classpath of the second test run > is different: > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > ... > [DEBUG] > /u/acladmin/.m2/repository/com/sas/other/sas.other/1.0-SNAPSHOT/sas.other-1.0-SNAPSHOT.jar > Because the classpath is missing a jar, the tests fail, and hence the entire > build fails. > If we run the targets separately > mvn clean deploy > mvn site-deploy > then maven only runs the tests once per run, with the correct classpath, so > the test and the entire build passes. > This looks like a regression between 2.0.9 and 2.2.1. Sorry, we did not > install/test other intermediate releases. -- 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-2259) Maven should check the contents of the POMs and jars that it downloads
[ http://jira.codehaus.org/browse/MNG-2259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217066#action_217066 ] Rafal Rusin commented on MNG-2259: -- I used -C option. It worked well. I'd like to use this option and enable checksumPolicy on specified repository to warn. Is this possible? servicemix Apache ServiceMix Repository http://svn.apache.org/repos/asf/servicemix/m2-repo true warn false With -C option, I get "Failed to resolve artifact" net.sf.saxon:saxon:jar:9.1.0.8 This artifact doesn't have checksum. > Maven should check the contents of the POMs and jars that it downloads > -- > > Key: MNG-2259 > URL: http://jira.codehaus.org/browse/MNG-2259 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Alan Cabrera > > Sometimes they are corrupt. -- 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: (MSITE-467) org.apache.maven.plugins.site.SiteMojo#execute() caused a linkage error: java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/AntMain
org.apache.maven.plugins.site.SiteMojo#execute() caused a linkage error:
java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/AntMain
Key: MSITE-467
URL: http://jira.codehaus.org/browse/MSITE-467
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: multi module
Affects Versions: 2.1
Environment: Windows XP SP3, Maven 2.2.1, JDK 1.6.0_18
Reporter: oliver.burkhalter
Attachments: test-app.zip
If I run {{mvn clean site}} on the attached test-app project in the top
directory, I get following error:
{noformat}
[FATAL ERROR] org.apache.maven.plugins.site.SiteMojo#execute() caused a linkage
error (java.lang.NoClassDefFoundError) and may be out-of-date. Check
the realms:
[FATAL ERROR] Plugin realm =
app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1]
urls[0] =
file:/d:/repo/org/apache/maven/plugins/maven-site-plugin/2.1/maven-site-plugin-2.1.jar
urls[1] =
file:/d:/repo/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
urls[2] =
file:/d:/repo/org/apache/maven/doxia/doxia-module-xhtml/1.1.2/doxia-module-xhtml-1.1.2.jar
urls[3] =
file:/d:/repo/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
urls[4] = file:/d:/repo/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
urls[5] = file:/d:/repo/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
urls[6] = file:/d:/repo/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
urls[7] =
file:/d:/repo/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
urls[8] =
file:/d:/repo/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
urls[9] = file:/d:/repo/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
urls[10] =
file:/d:/repo/org/apache/maven/doxia/doxia-module-apt/1.1.2/doxia-module-apt-1.1.2.jar
urls[11] =
file:/d:/repo/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
urls[12] =
file:/d:/repo/org/apache/maven/doxia/doxia-module-fml/1.1.2/doxia-module-fml-1.1.2.jar
urls[13] =
file:/d:/repo/org/apache/maven/doxia/doxia-decoration-model/1.1.2/doxia-decoration-model-1.1.2.jar
urls[14] =
file:/d:/repo/org/apache/maven/doxia/doxia-site-renderer/1.1.2/doxia-site-renderer-1.1.2.jar
urls[15] =
file:/d:/repo/org/codehaus/plexus/plexus-i18n/1.0-beta-7/plexus-i18n-1.0-beta-7.jar
urls[16] =
file:/d:/repo/org/codehaus/plexus/plexus-velocity/1.1.8/plexus-velocity-1.1.8.jar
urls[17] = file:/d:/repo/org/apache/velocity/velocity/1.5/velocity-1.5.jar
urls[18] =
file:/d:/repo/commons-collections/commons-collections/3.2/commons-collections-3.2.jar
urls[19] = file:/d:/repo/oro/oro/2.0.8/oro-2.0.8.jar
urls[20] =
file:/d:/repo/org/apache/maven/shared/maven-doxia-tools/1.2/maven-doxia-tools-1.2.jar
urls[21] = file:/d:/repo/commons-io/commons-io/1.4/commons-io-1.4.jar
urls[22] =
file:/d:/repo/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar
urls[23] = file:/d:/repo/org/mortbay/jetty/jetty/6.1.5/jetty-6.1.5.jar
urls[24] = file:/d:/repo/org/mortbay/jetty/jetty-util/6.1.5/jetty-util-6.1.5.jar
urls[25] =
file:/d:/repo/org/mortbay/jetty/servlet-api-2.5/6.1.5/servlet-api-2.5-6.1.5.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] = file:/C:/maven/lib/maven-2.2.1-uber.jar
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] org/apache/tools/ant/launch/AntMain
org.apache.tools.ant.launch.AntMain
[INFO]
[INFO] Trace
java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/AntMain
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at
org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
at
org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
at
org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.apache.tools.ant.Project.initProperties(Project.java:308)
at org.apache.tools.ant.Project.ini
[jira] Commented: (MJAVADOC-279) Javadoc plugin doesn't set dependencies correctly when pom uses classifiers
[ http://jira.codehaus.org/browse/MJAVADOC-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217068#action_217068 ] James Nichols commented on MJAVADOC-279: this occurs when running site goal; works fine for javadoc:javadoc > Javadoc plugin doesn't set dependencies correctly when pom uses classifiers > --- > > Key: MJAVADOC-279 > URL: http://jira.codehaus.org/browse/MJAVADOC-279 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6.1 > Environment: Maven 2.2.1, Windows XP >Reporter: James Nichols > > Create a project which has dependencies like: > > > com.xxx > mydep > 1.3.1 > core > > > com.xxx > mydep > 1.3.1 > util > > > This will add dependencies to the javadoc options file something like this: > classpath > 'C:/dev/target/classes;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar' > where it should yield: > classpath > 'C:/dev/target/classes;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-core.jar;c:/repository/com/xxx/mydep/1.3.1/mydep-1.3.1-util.jar' > i.e. the classifier for the artifacts is being ignored. This causes various > dependencies to be missing from the javadoc task which will eventually fail > with: > java.lang.NullPointerException > at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:67) > at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:29) > at > com.sun.tools.javadoc.ClassDocImpl.superclassType(ClassDocImpl.java:441) > at > com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:386) > at > com.sun.tools.doclets.internal.toolkit.util.Util.getAllInterfaces(Util.java:424) > at > com.sun.tools.doclets.internal.toolkit.util.ClassTree.processType(ClassTree.java:162) > at > com.sun.tools.doclets.internal.toolkit.util.ClassTree.buildTree(ClassTree.java:114) > at > com.sun.tools.doclets.internal.toolkit.util.ClassTree.(ClassTree.java:73) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:104) > at > com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:64) > at > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:42) > at com.sun.tools.doclets.standard.Standard.start(Standard.java:23) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:215) > at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:91) > at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:340) > at com.sun.tools.javadoc.Start.begin(Start.java:128) > at com.sun.tools.javadoc.Main.execute(Main.java:41) > at com.sun.tools.javadoc.Main.main(Main.java:31) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
Allow creation of aggregated javadocs source bundles from project dependencies -- Key: MJAVADOC-280 URL: http://jira.codehaus.org/browse/MJAVADOC-280 Project: Maven 2.x Javadoc Plugin Issue Type: New Feature Affects Versions: 2.6.1 Reporter: John Casey It would be nice to have the ability to generate an aggregated javadoc set for a distribution project by resolving the -sources and -test-sources bundles of its dependencies (or, correspondingly, the project.compileSourceRoots and project.testCompileSourceRoots for modules in the same reactor). Initially, this might just mean downloading, unpacking, and adding the dependency sources as sourcepaths to the javadoc execution if a flag is set to true (includeDependencySources). Later, we could easily expand this to allow bundling and deployment of the src/main/javadoc directory so that this artifact can be used in the above aggregation approach. I've got an implementation of the first part that I will attach to this issue as a patch to illustrate what I'm talking about. -- 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: (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
[ http://jira.codehaus.org/browse/MJAVADOC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MJAVADOC-280: Attachment: aggregate-from-dependencies.patch > Allow creation of aggregated javadocs source bundles from project dependencies > -- > > Key: MJAVADOC-280 > URL: http://jira.codehaus.org/browse/MJAVADOC-280 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.6.1 >Reporter: John Casey > Fix For: 2.6.2 > > Attachments: aggregate-from-dependencies.patch > > > It would be nice to have the ability to generate an aggregated javadoc set > for a distribution project by resolving the -sources and -test-sources > bundles of its dependencies (or, correspondingly, the > project.compileSourceRoots and project.testCompileSourceRoots for modules in > the same reactor). > Initially, this might just mean downloading, unpacking, and adding the > dependency sources as sourcepaths to the javadoc execution if a flag is set > to true (includeDependencySources). Later, we could easily expand this to > allow bundling and deployment of the src/main/javadoc directory so that this > artifact can be used in the above aggregation approach. > I've got an implementation of the first part that I will attach to this issue > as a patch to illustrate what I'm talking about. -- 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: (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
[ http://jira.codehaus.org/browse/MJAVADOC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MJAVADOC-280: Fix Version/s: 2.6.2 Assignee: John Casey > Allow creation of aggregated javadocs source bundles from project dependencies > -- > > Key: MJAVADOC-280 > URL: http://jira.codehaus.org/browse/MJAVADOC-280 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.6.1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.6.2 > > Attachments: aggregate-from-dependencies.patch > > > It would be nice to have the ability to generate an aggregated javadoc set > for a distribution project by resolving the -sources and -test-sources > bundles of its dependencies (or, correspondingly, the > project.compileSourceRoots and project.testCompileSourceRoots for modules in > the same reactor). > Initially, this might just mean downloading, unpacking, and adding the > dependency sources as sourcepaths to the javadoc execution if a flag is set > to true (includeDependencySources). Later, we could easily expand this to > allow bundling and deployment of the src/main/javadoc directory so that this > artifact can be used in the above aggregation approach. > I've got an implementation of the first part that I will attach to this issue > as a patch to illustrate what I'm talking about. -- 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: (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
[ http://jira.codehaus.org/browse/MJAVADOC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MJAVADOC-280: Patch Submitted: [Yes] > Allow creation of aggregated javadocs source bundles from project dependencies > -- > > Key: MJAVADOC-280 > URL: http://jira.codehaus.org/browse/MJAVADOC-280 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.6.1 >Reporter: John Casey > Fix For: 2.6.2 > > Attachments: aggregate-from-dependencies.patch > > > It would be nice to have the ability to generate an aggregated javadoc set > for a distribution project by resolving the -sources and -test-sources > bundles of its dependencies (or, correspondingly, the > project.compileSourceRoots and project.testCompileSourceRoots for modules in > the same reactor). > Initially, this might just mean downloading, unpacking, and adding the > dependency sources as sourcepaths to the javadoc execution if a flag is set > to true (includeDependencySources). Later, we could easily expand this to > allow bundling and deployment of the src/main/javadoc directory so that this > artifact can be used in the above aggregation approach. > I've got an implementation of the first part that I will attach to this issue > as a patch to illustrate what I'm talking about. -- 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: (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
[ http://jira.codehaus.org/browse/MJAVADOC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217072#action_217072 ] John Casey commented on MJAVADOC-280: - patch was committed in revId: 931686 I'll start working up some tests next, and then get into the javadoc-resources bundling stuff. > Allow creation of aggregated javadocs source bundles from project dependencies > -- > > Key: MJAVADOC-280 > URL: http://jira.codehaus.org/browse/MJAVADOC-280 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Affects Versions: 2.6.1 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.6.2 > > Attachments: aggregate-from-dependencies.patch > > > It would be nice to have the ability to generate an aggregated javadoc set > for a distribution project by resolving the -sources and -test-sources > bundles of its dependencies (or, correspondingly, the > project.compileSourceRoots and project.testCompileSourceRoots for modules in > the same reactor). > Initially, this might just mean downloading, unpacking, and adding the > dependency sources as sourcepaths to the javadoc execution if a flag is set > to true (includeDependencySources). Later, we could easily expand this to > allow bundling and deployment of the src/main/javadoc directory so that this > artifact can be used in the above aggregation approach. > I've got an implementation of the first part that I will attach to this issue > as a patch to illustrate what I'm talking about. -- 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: (MJAVADOC-280) Allow creation of aggregated javadocs source bundles from project dependencies
[
http://jira.codehaus.org/browse/MJAVADOC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217073#action_217073
]
John Casey commented on MJAVADOC-280:
-
This is a configuration I inserted into the apache-maven project in my local
workdir of maven-2, in order to see the new feature in action:
{code:xml}
javadocs
maven-javadoc-plugin
2.6.2-SNAPSHOT
true
false
org.apache.maven:*
distro-javadocs
jar
test-jar
{code}
NOTE: To get the test-jar stuff working when the full maven project structure
isn't built (i.e. building from apache-maven standalone), I had to add the
following to the top-level pom.xml in the maven-2 workdir:
{code:xml}
javadocs
org.apache.maven.plugins
maven-source-plugin
attach-sources
jar
attach-test-sources
test-jar
{code}
> Allow creation of aggregated javadocs source bundles from project dependencies
> --
>
> Key: MJAVADOC-280
> URL: http://jira.codehaus.org/browse/MJAVADOC-280
> Project: Maven 2.x Javadoc Plugin
> Issue Type: New Feature
>Affects Versions: 2.6.1
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.6.2
>
> Attachments: aggregate-from-dependencies.patch
>
>
> It would be nice to have the ability to generate an aggregated javadoc set
> for a distribution project by resolving the -sources and -test-sources
> bundles of its dependencies (or, correspondingly, the
> project.compileSourceRoots and project.testCompileSourceRoots for modules in
> the same reactor).
> Initially, this might just mean downloading, unpacking, and adding the
> dependency sources as sourcepaths to the javadoc execution if a flag is set
> to true (includeDependencySources). Later, we could easily expand this to
> allow bundling and deployment of the src/main/javadoc directory so that this
> artifact can be used in the above aggregation approach.
> I've got an implementation of the first part that I will attach to this issue
> as a patch to illustrate what I'm talking about.
--
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-4626) Avoid cleartext passwords over http
[ http://jira.codehaus.org/browse/MNG-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217075#action_217075 ] Brian Fox commented on MNG-4626: Maven was built assuming no intelligence on the repository side, so it exactly follows the http standards wrt authentication. Simply encrypting the password is a false sense of security, if you really have sensitive data, you should instead be using https to encrypt the whole transfer. The encryption built into Maven 2.1 was intended to provide a way to give some security to your password by obscuring it from the settings.xml. Naturally to conform to http standards, we needed to reverse the encryption before putting in on the wire. There may be some consideration done to define a new repository manager protocol and some password encryption around that, but for the moment, this seems to be out of scope for Maven itself. That said, we have developed this functionality in Nexus Pro, but never shipped it because of some incompatibilities with the sun http provider in some edge cases. It sort of fell off the priority list, but we will be resurrecting and polishing this up soon. > Avoid cleartext passwords over http > --- > > Key: MNG-4626 > URL: http://jira.codehaus.org/browse/MNG-4626 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: General >Affects Versions: 3.0-alpha-7 >Reporter: Brendan Lawlor > > The current encryption scheme implemented by Maven avoids the use of > cleartext passwords on local files by allowing them to be encrypted locally > and decrypted just before the maven client requests from or deploys to a > central artifact repository. > I would like to suggest that the Maven team replicate the idea adopted by > Artifactory, where passwords are _transmitted_ encrypted, and only decrypted > on the server side by the repository. Requests and deployments are made over > http and transmitted in the clear. Where the passwords are system passwords > integrated to Active Directory or similar using LDAP, this is not an option > even within a company's LAN. I like the idea of where Nexus and the Maven > development stack in general is going (I listened to Jason's seminar recently > and I'm keen on much of where you are going). But passwords in the clear over > http is a showstopper and I'm surprised you haven't already borrowed this > idea from the competition. > Another irritating side effect of maven's insistence in using cleartext > passwords has been mentioned by a colleague of mine in MNG-4611. We currently > use Artifactory for EXACTLY this reason (the password encryption) and maven > logs loudly about the fact that the passwords are encrypted. -- 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-4626) Avoid cleartext passwords over http
[ http://jira.codehaus.org/browse/MNG-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217077#action_217077 ] Paul Benedict commented on MNG-4626: Even with an encrypted password sent over HTTP, unless the encryption is time sensitive (nonce?), an intercept could allow its unauthorized reuse. > Avoid cleartext passwords over http > --- > > Key: MNG-4626 > URL: http://jira.codehaus.org/browse/MNG-4626 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: General >Affects Versions: 3.0-alpha-7 >Reporter: Brendan Lawlor > > The current encryption scheme implemented by Maven avoids the use of > cleartext passwords on local files by allowing them to be encrypted locally > and decrypted just before the maven client requests from or deploys to a > central artifact repository. > I would like to suggest that the Maven team replicate the idea adopted by > Artifactory, where passwords are _transmitted_ encrypted, and only decrypted > on the server side by the repository. Requests and deployments are made over > http and transmitted in the clear. Where the passwords are system passwords > integrated to Active Directory or similar using LDAP, this is not an option > even within a company's LAN. I like the idea of where Nexus and the Maven > development stack in general is going (I listened to Jason's seminar recently > and I'm keen on much of where you are going). But passwords in the clear over > http is a showstopper and I'm surprised you haven't already borrowed this > idea from the competition. > Another irritating side effect of maven's insistence in using cleartext > passwords has been mentioned by a colleague of mine in MNG-4611. We currently > use Artifactory for EXACTLY this reason (the password encryption) and maven > logs loudly about the fact that the passwords are encrypted. -- 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-4626) Avoid cleartext passwords over http
[ http://jira.codehaus.org/browse/MNG-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217078#action_217078 ] Brett Porter commented on MNG-4626: --- can I some up, between the two issues, that you want Maven to not decrypt the password in settings.xml, and that Artifactory is using the same algorithm and master key ? So a suitable escaping mechanism (that works as documented on the page) would be sufficient? That should be fine to do, but I otherwise agree using https for your repository is a better option all around. > Avoid cleartext passwords over http > --- > > Key: MNG-4626 > URL: http://jira.codehaus.org/browse/MNG-4626 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: General >Affects Versions: 3.0-alpha-7 >Reporter: Brendan Lawlor > > The current encryption scheme implemented by Maven avoids the use of > cleartext passwords on local files by allowing them to be encrypted locally > and decrypted just before the maven client requests from or deploys to a > central artifact repository. > I would like to suggest that the Maven team replicate the idea adopted by > Artifactory, where passwords are _transmitted_ encrypted, and only decrypted > on the server side by the repository. Requests and deployments are made over > http and transmitted in the clear. Where the passwords are system passwords > integrated to Active Directory or similar using LDAP, this is not an option > even within a company's LAN. I like the idea of where Nexus and the Maven > development stack in general is going (I listened to Jason's seminar recently > and I'm keen on much of where you are going). But passwords in the clear over > http is a showstopper and I'm surprised you haven't already borrowed this > idea from the competition. > Another irritating side effect of maven's insistence in using cleartext > passwords has been mentioned by a colleague of mine in MNG-4611. We currently > use Artifactory for EXACTLY this reason (the password encryption) and maven > logs loudly about the fact that the passwords are encrypted. -- 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-3835) Incorrect parameter injection
[
http://jira.codehaus.org/browse/MNG-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217081#action_217081
]
Brett Porter commented on MNG-3835:
---
In the mojo I added:
{code}
/** @parameter */
private List headers;
{code}
In that package I added the classes:
{code}
public class Header
{
String name;
List values;
boolean append;
}
{code}
and
{code}
public class Value
{
String name;
Map directives;
}
{code}
Using the plugin configuration above, and some toString() methods, I could see
they were populated correctly.
I'm uncertain how exactly you had configured the mojo and what setters were
available. If you can reproduce this with a small mojo that'd be helpful.
> Incorrect parameter injection
> -
>
> Key: MNG-3835
> URL: http://jira.codehaus.org/browse/MNG-3835
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Plugin API
>Affects Versions: 2.0.9, 2.1.0-M1
> Environment: Maven version: 2.1.0-M1
> Java version: 1.5.0_16
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows vista" version: "6.0" arch: "x86" family: "windows"
>Reporter: Matthew Beermann
>Assignee: Brett Porter
>Priority: Critical
>
> Consider the following configuration fragment. Header is a bean with a list
> of values; Value is a bean with a map of directives.
>
>
> Bundle-SymbolicName
>
>
> ${project.name}
>
> true
>
>
>
>
>
> Eclipse-LazyStart
>
>
> true
>
>
>
>
> Eclipse-BuddyPolicy
>
>
> registered
>
>
>
>
> Require-Bundle
> true
>
>
>
> com.cerner.client.wrapper.osgi.jaxb
>
>
>
> com.cerner.client.wrapper.osgi.msvc
>
>
>
>
>
> Eclipse-RegisterBuddy
>
>
>
> com.cerner.client.wrapper.osgi.jaxb
>
>
>
>
> But here's what actually gets sent to the mojo (output from mvn -X):
> [DEBUG] (s) name = Bundle-SymbolicName
> [DEBUG] (s) name = jaxb-clinrpt-template
> [DEBUG] (s) directives = {singleton=true}
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@1cb048e]
> [DEBUG] (s) name = Eclipse-LazyStart
> [DEBUG] (s) name = true
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@1983ad7]
> [DEBUG] (s) name = Eclipse-BuddyPolicy
> [DEBUG] (s) name = registered
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@13f348b]
> [DEBUG] (s) name = Require-Bundle
> [DEBUG] (s) append = true
> [DEBUG] (s) name = com.cerner.client.wrapper.osgi.jaxb
> [DEBUG] (s) name = com.cerner.client.wrapper.osgi.msvc
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@92997e,
> com.cerner.engineering.maven.osgi.va...@9b601d]
> [DEBUG] (s) name = Eclipse-RegisterBuddy
> [DEBUG] (s) name = com.cerner.client.wrapper.osgi.jaxb
> [DEBUG] (s) directives = {singleton=true}
> [DEBUG] (s) values = [com.cerner.engineering.maven.osgi.va...@c3362f]
> Note the second, duplicate occurance of at the end, associated
> with the wrong header. Where on earth did that come from? It wasn't in the
> configuration. Even more mysteriously, if you rearrange the order and put the
> offending at the end of the list, the problem vanishes.
> I'm not quite sure what's going on here, but it's causing some of our custom
> goals to produce invalid outp
[jira] Issue Comment Edited: (MNG-4626) Avoid cleartext passwords over http
[ http://jira.codehaus.org/browse/MNG-4626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=217078#action_217078 ] Brett Porter edited comment on MNG-4626 at 4/7/10 6:24 PM: --- can I sum up, between the two issues, that you want Maven to not decrypt the password in settings.xml, and that Artifactory is using the same algorithm and master key ? So a suitable escaping mechanism (that works as documented on the page) would be sufficient? That should be fine to do, but I otherwise agree using https for your repository is a better option all around. was (Author: brettporter): can I some up, between the two issues, that you want Maven to not decrypt the password in settings.xml, and that Artifactory is using the same algorithm and master key ? So a suitable escaping mechanism (that works as documented on the page) would be sufficient? That should be fine to do, but I otherwise agree using https for your repository is a better option all around. > Avoid cleartext passwords over http > --- > > Key: MNG-4626 > URL: http://jira.codehaus.org/browse/MNG-4626 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: General >Affects Versions: 3.0-alpha-7 >Reporter: Brendan Lawlor > > The current encryption scheme implemented by Maven avoids the use of > cleartext passwords on local files by allowing them to be encrypted locally > and decrypted just before the maven client requests from or deploys to a > central artifact repository. > I would like to suggest that the Maven team replicate the idea adopted by > Artifactory, where passwords are _transmitted_ encrypted, and only decrypted > on the server side by the repository. Requests and deployments are made over > http and transmitted in the clear. Where the passwords are system passwords > integrated to Active Directory or similar using LDAP, this is not an option > even within a company's LAN. I like the idea of where Nexus and the Maven > development stack in general is going (I listened to Jason's seminar recently > and I'm keen on much of where you are going). But passwords in the clear over > http is a showstopper and I'm surprised you haven't already borrowed this > idea from the competition. > Another irritating side effect of maven's insistence in using cleartext > passwords has been mentioned by a colleague of mine in MNG-4611. We currently > use Artifactory for EXACTLY this reason (the password encryption) and maven > logs loudly about the fact that the passwords are encrypted. -- 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: (MSITE-468) Absolute links item href's are stripped to become relative
Absolute links item href's are stripped to become relative
--
Key: MSITE-468
URL: http://jira.codehaus.org/browse/MSITE-468
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: relative links
Affects Versions: 2.0.1
Reporter: Andrew Hughes
When I add the follwing to site.xml:
{noformat}
http://xyz.com/blah"/>
{noformat}
The generated html output is:
{noformat}
BLAH
{noformat}
This is wrong, if I stipulate "http://*"; this should be an external (and
absolute link), the generated html should have an absolute href url, like this:
{noformat}
http://xyz.com/blah";>BLAH
{noformat}
The conditions when this relative href translation occurs is when I have have
${project.url}=="http://xyz.com"; in my pom.xml, like this:
{noformat}
...
http://xyz.com
...
{noformat}
--
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: (MRELEASE-534) Release:branch has new remote tagging failure mode in 2.0
[ http://jira.codehaus.org/browse/MRELEASE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MRELEASE-534. - Resolution: Fixed Fix Version/s: 2.0 Well, I tried using release:branch again, and it worked. > Release:branch has new remote tagging failure mode in 2.0 > - > > Key: MRELEASE-534 > URL: http://jira.codehaus.org/browse/MRELEASE-534 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0 >Reporter: Benson Margulies > Fix For: 2.0 > > Attachments: MRELEASE-534-proj.tgz, MRELEASE-parse-version-error.txt > > > mvn org.apache.maven.plugins:maven-release-plugin:2.0:branch -Prelease > -DbranchName=segmentation -DupdateBranchVersions=true > -DupdateWorkingCopyVersions=false > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to branch SCM > Provider message: > The svn branch command failed. > Command output: > svn: Path 'http://svn.basistech.net/engineering/rse/branches/segmentation' > does not exist in revision 10471 -- 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: (MRELEASE-535) release:branch poked trunk poms
[ http://jira.codehaus.org/browse/MRELEASE-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies closed MRELEASE-535. - Resolution: Not A Bug THis was just stupid. > release:branch poked trunk poms > --- > > Key: MRELEASE-535 > URL: http://jira.codehaus.org/browse/MRELEASE-535 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0 >Reporter: Benson Margulies > > I ran the following: > mvn org.apache.maven.plugins:maven-release-plugin:2.0:branch -Prelease > -DbranchName=segmentation -DupdateBranchVersions=true > -DupdateWorkingCopyVersions=false > It failed. However, before it failed, it checked new poms into the trunk that > had the scm and version info for the branch. > What I expected it to do was (1) create the branch, and (2) edit the poms *in > the branch*, leaving the trunk untouched. > Further, release:rollback failed with an NPE when I ran it after the failure > to try to unwind this mess. -- 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-534) Release:branch has new remote tagging failure mode in 2.0
[ http://jira.codehaus.org/browse/MRELEASE-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRELEASE-534: -- Fix Version/s: (was: 2.0) removing the fix for version as we didn't change anything > Release:branch has new remote tagging failure mode in 2.0 > - > > Key: MRELEASE-534 > URL: http://jira.codehaus.org/browse/MRELEASE-534 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0 >Reporter: Benson Margulies > Attachments: MRELEASE-534-proj.tgz, MRELEASE-parse-version-error.txt > > > mvn org.apache.maven.plugins:maven-release-plugin:2.0:branch -Prelease > -DbranchName=segmentation -DupdateBranchVersions=true > -DupdateWorkingCopyVersions=false > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to branch SCM > Provider message: > The svn branch command failed. > Command output: > svn: Path 'http://svn.basistech.net/engineering/rse/branches/segmentation' > does not exist in revision 10471 -- 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
