[jira] Commented: (MECLIPSE-554) [regression] Order of source folders in build classpath reversed
[ http://jira.codehaus.org/browse/MECLIPSE-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174563#action_174563 ] Joerg Schaible commented on MECLIPSE-554: - Why not introduce an order like src/test/resources src/main/java src/main/resources src/test/java as it is not possible to generate two Java files with the same name in src/main/java and src/test/java without Eclipse complaining anyway. All issues related classpath ordering are due to the test resources only that should be located first. If no test resources are available, the order in Eclipse will be quite like it was with 2.5.x. > [regression] Order of source folders in build classpath reversed > > > Key: MECLIPSE-554 > URL: http://jira.codehaus.org/browse/MECLIPSE-554 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.6 >Reporter: Gregor Heine >Assignee: Arnaud Heritier > > Up to version 2.5.1 the order of source folders was: > src/main/java > src/main/resources > src/test/java > src/test/resources > In 2.6 the test folders now appear before the main folders: > src/test/java > src/test/resources > src/main/java > src/main/resources -- 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-2022) What is the Difference between project.getDependencies() and project.getDependencyArtifacts?
[ http://jira.codehaus.org/browse/MNG-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174562#action_174562 ] Anders Kr. Andersen commented on MNG-2022: -- I thought that getDependencies() was getting the pom.xml's dependency list and get getDependencyArtifacts() would relate to the artifact as well.? Never less: Could we not just add this to the javadoc and close the case ? > What is the Difference between project.getDependencies() and > project.getDependencyArtifacts? > > > Key: MNG-2022 > URL: http://jira.codehaus.org/browse/MNG-2022 > Project: Maven 2 > Issue Type: Improvement > Components: Documentation: Faqs >Reporter: Natalie Burdick > Fix For: Documentation Deficit > > > The difference between project.getDependencies() and > project.getDependencyArtifacts() is that project.getDependencies() > also returns transitive dependencies, while project.getDependencyArtifacts > returns only the direct dependencies, and also includes things in the test > scope. -- 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-4133) ssh-external wagon can not be overridden on its own
[ http://jira.codehaus.org/browse/MNG-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174547#action_174547 ] Brett Porter commented on MNG-4133: --- the exception is in the linked issue. I'm not sure why the shade plugin wouldn't be rewriting components.xml > ssh-external wagon can not be overridden on its own > --- > > Key: MNG-4133 > URL: http://jira.codehaus.org/browse/MNG-4133 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading >Affects Versions: 2.1.0 >Reporter: Brett Porter > Fix For: 2.1.1 > > > when a project only overrides the ssh-external wagon, it causes the wagon-ssh > that is built in to fail to load (probably because of a classloading conflict > with ssh-common). See the linked issue for details. > A couple of fixes are needed here: > - don't crash the entire extension loading mechanism because one extension > failed to load > - possibly shade the common ssh JAR in the core so it doesn't cause the > conflict in the first place. -- 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-4133) ssh-external wagon can not be overridden on its own
[ http://jira.codehaus.org/browse/MNG-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174546#action_174546 ] John Casey commented on MNG-4133: - Okay, I'm sure this is what you were talking about, but it seems that the shade plugin isn't rewriting the components.xml file correctly. I can add more excludes for the components listed there, but that may erase the benefit of shading this stuff in the first place. What is the exception you've seen, and do you know of any good way to rewrite the components.xml file? > ssh-external wagon can not be overridden on its own > --- > > Key: MNG-4133 > URL: http://jira.codehaus.org/browse/MNG-4133 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading >Affects Versions: 2.1.0 >Reporter: Brett Porter > Fix For: 2.1.1 > > > when a project only overrides the ssh-external wagon, it causes the wagon-ssh > that is built in to fail to load (probably because of a classloading conflict > with ssh-common). See the linked issue for details. > A couple of fixes are needed here: > - don't crash the entire extension loading mechanism because one extension > failed to load > - possibly shade the common ssh JAR in the core so it doesn't cause the > conflict in the first place. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2442) Add easyb.org to syncrhonized repository
Add easyb.org to syncrhonized repository Key: MAVENUPLOAD-2442 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2442 Project: Maven Upload Requests Issue Type: Wish Reporter: Rod Coffin Please add the following to the sync.csv file to automatically synchronize the easyb repository to central: "org.easyb","ma...@easyb.org:/var/maven/repo/release","rsync_ssh","Rod Coffin","r...@rodcoffin.com",, I am a committer on easyb and identified on the easyb google code page (http://code.google.com/p/easyb/) under the project owner section as rfciii. -- 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: (SCM-463) Allow builds with Modello 1.0
Allow builds with Modello 1.0 - Key: SCM-463 URL: http://jira.codehaus.org/browse/SCM-463 Project: Maven SCM Issue Type: Improvement Components: Technical tasks Affects Versions: 1.2 Environment: Debian Reporter: Ludovic Claude Priority: Trivial Attachments: modello-xsd.diff The Debian project packages a minimal set of Java software and tries to keep only one version of each library in its repository. The latest version of Modello packaged for Debian is 1.0, and when building Maven SCM against this version, the build fails when generating the XSD files from Modello. I have made a patch which fixes this issue, it tries to follow the conventions used in Doxia, but you'd better have a look at my choice of namespaces. Ludovic -- 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-4147) very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header
[ http://jira.codehaus.org/browse/MNG-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174541#action_174541 ] Brett Porter commented on MNG-4147: --- a workaround is to use dav:// instead of http:// for the URL > very long passwords cause LightweightHTTP wagon to line-wrap the > Base64-encoded Authorization header > > > Key: MNG-4147 > URL: http://jira.codehaus.org/browse/MNG-4147 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1.1 > > > I'll cross-file (and link) this issue into wagon, but Sun's HTTPURLConnection > implementation uses a line-wrapping Base64 implementation. When passwords are > very long, this causes an invalid HTTP request, since the Authorization > header's value is line-wrapped. -- 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-2502) mvn package does not work on J2EE multi module build
[ http://jira.codehaus.org/browse/MNG-2502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174538#action_174538 ] John Casey commented on MNG-2502: - Can you re-check this using Maven 2.1.0? I put in a fix for similar situations...ejb-client and other types of secondary artifacts are called "attachments", and I added some code to search the reactor projects for attached artifacts in 2.1.0... > mvn package does not work on J2EE multi module build > > > Key: MNG-2502 > URL: http://jira.codehaus.org/browse/MNG-2502 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.4 > Environment: Linux, J2SE 1.4 >Reporter: Heinrich Nirschl > Fix For: 2.1.x > > Attachments: maven_multimodule_ejb.zip > > > In a multi module build consisting of an ejb.jar (with an ejb-client.jar), a > war, and an ear where the war depends on the ejb-client.jar and the ear > depends on the ejb.jar and the war, a reactor build with > mvn package > fails. The war build tries to download the ejb-client.jar from the repository > instead of using the just built version. > If I first run 'mvn install' in the ejb module the following multi module > 'mvn package' succeeds. > This issue causes also problems for the realease plugin since the sub build > fails. -- 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-2971) Variables are not replaced into installed pom file
[
http://jira.codehaus.org/browse/MNG-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174537#action_174537
]
John Casey commented on MNG-2971:
-
expressions in elements within the POM are interpolated since Maven
2.1.0. I've actually just introduced some more code to improve that behavior.
Is the above problem still present in 2.1.0??
> Variables are not replaced into installed pom file
> --
>
> Key: MNG-2971
> URL: http://jira.codehaus.org/browse/MNG-2971
> Project: Maven 2
> Issue Type: Bug
> Components: Deployment, Inheritance and Interpolation
> Environment: Windows, Solaris
> Maven version 2.0.4
>Reporter: Laurent Dauvilaire
>Assignee: Ralph Goers
> Fix For: 2.1.x
>
>
> Variables are not replaced into installed pom file.
> Here is a sample pom file
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> com.xxx.root
> root
> pom
> ${prop.version}
> My Project
> ...
>
> 3.0.20
>
>
> The installed pom is into
> ${localRepository}/com/xxx/root/root/3.0.20/root-3.0.20.pom
> is the same as the project pom file but the version referenced into the
> installed pom file is ${prop.version} instead of 3.0.20
> which creates problem to artifacts depending of this one.
> Thanks in advance
--
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: (MCHANGELOG-86) Error with outputEncoding parameter set to UTF-8
[
http://jira.codehaus.org/browse/MCHANGELOG-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174535#action_174535
]
Olivier Lamy commented on MCHANGELOG-86:
fix apply in rev 769578.
Can you test with trunk or last SNAPSHOT ?
> Error with outputEncoding parameter set to UTF-8
>
>
> Key: MCHANGELOG-86
> URL: http://jira.codehaus.org/browse/MCHANGELOG-86
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP Pro SP2, Maven 2.0.9, Java SE 1.5.0 Update
> 15, Subversion 1.4.6
>Reporter: Joël Royer
>Assignee: Olivier Lamy
> Fix For: 2.2
>
> Attachments: ScreenShot_2008-06-04_140551.png
>
>
> When using UTF-8 as setting for the parameter outputEncoding, we've got this
> error:
> [INFO] Generating "Change Log" report.
> [INFO] Generating changed sets xml to:
> D:\devs\projects\Test\workspace\TestWebapp\target\changelog.xml
> [INFO] Executing: svn --non-interactive log -v -r "{2008-05-05 11:45:19
> +}:{
> 2008-06-05 11:45:19 +}"
> https://mysubversionsrv/svndev/test/trunk/TestWebapp
> [INFO] Working directory: D:\devs\projects\Test\workspace\TestWebapp
> [INFO] Generating "Developer Activity" report.
> [INFO] Using existing changelog.xml...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error occurred while parsing
> D:
> \devs\projects\Test\workspace\TestWebapp\target\changelog.xml
> Invalid byte 1 of 1-byte UTF-8 sequence.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 39 seconds
> [INFO] Finished at: Wed Jun 04 13:45:23 CEST 2008
> [INFO] Final Memory: 41M/63M
> [INFO]
>
> The file changelog.xml contains the good header line ( encoding="UTF-8"?>), but the file is encoded with ANSI UNIX charset
--
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: (MCHANGELOG-86) Error with outputEncoding parameter set to UTF-8
[
http://jira.codehaus.org/browse/MCHANGELOG-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MCHANGELOG-86:
---
Assignee: Olivier Lamy
Fix Version/s: 2.2
> Error with outputEncoding parameter set to UTF-8
>
>
> Key: MCHANGELOG-86
> URL: http://jira.codehaus.org/browse/MCHANGELOG-86
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP Pro SP2, Maven 2.0.9, Java SE 1.5.0 Update
> 15, Subversion 1.4.6
>Reporter: Joël Royer
>Assignee: Olivier Lamy
> Fix For: 2.2
>
> Attachments: ScreenShot_2008-06-04_140551.png
>
>
> When using UTF-8 as setting for the parameter outputEncoding, we've got this
> error:
> [INFO] Generating "Change Log" report.
> [INFO] Generating changed sets xml to:
> D:\devs\projects\Test\workspace\TestWebapp\target\changelog.xml
> [INFO] Executing: svn --non-interactive log -v -r "{2008-05-05 11:45:19
> +}:{
> 2008-06-05 11:45:19 +}"
> https://mysubversionsrv/svndev/test/trunk/TestWebapp
> [INFO] Working directory: D:\devs\projects\Test\workspace\TestWebapp
> [INFO] Generating "Developer Activity" report.
> [INFO] Using existing changelog.xml...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error occurred while parsing
> D:
> \devs\projects\Test\workspace\TestWebapp\target\changelog.xml
> Invalid byte 1 of 1-byte UTF-8 sequence.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 39 seconds
> [INFO] Finished at: Wed Jun 04 13:45:23 CEST 2008
> [INFO] Final Memory: 41M/63M
> [INFO]
>
> The file changelog.xml contains the good header line ( encoding="UTF-8"?>), but the file is encoded with ANSI UNIX charset
--
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-4133) ssh-external wagon can not be overridden on its own
[ http://jira.codehaus.org/browse/MNG-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174534#action_174534 ] Brett Porter commented on MNG-4133: --- I wouldn't change something that hasn't been experienced. I'm not 100% sure the shading will work yet, either. The old container has a couple of problems in this regard. > ssh-external wagon can not be overridden on its own > --- > > Key: MNG-4133 > URL: http://jira.codehaus.org/browse/MNG-4133 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading >Affects Versions: 2.1.0 >Reporter: Brett Porter > Fix For: 2.1.1 > > > when a project only overrides the ssh-external wagon, it causes the wagon-ssh > that is built in to fail to load (probably because of a classloading conflict > with ssh-common). See the linked issue for details. > A couple of fixes are needed here: > - don't crash the entire extension loading mechanism because one extension > failed to load > - possibly shade the common ssh JAR in the core so it doesn't cause the > conflict in the first place. -- 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: (MCHANGELOG-86) Error with outputEncoding parameter set to UTF-8
[
http://jira.codehaus.org/browse/MCHANGELOG-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174532#action_174532
]
Olivier Lamy commented on MCHANGELOG-86:
could you attach the generated changelog.xml and a log with running mvn with -e
?
> Error with outputEncoding parameter set to UTF-8
>
>
> Key: MCHANGELOG-86
> URL: http://jira.codehaus.org/browse/MCHANGELOG-86
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP Pro SP2, Maven 2.0.9, Java SE 1.5.0 Update
> 15, Subversion 1.4.6
>Reporter: Joël Royer
> Attachments: ScreenShot_2008-06-04_140551.png
>
>
> When using UTF-8 as setting for the parameter outputEncoding, we've got this
> error:
> [INFO] Generating "Change Log" report.
> [INFO] Generating changed sets xml to:
> D:\devs\projects\Test\workspace\TestWebapp\target\changelog.xml
> [INFO] Executing: svn --non-interactive log -v -r "{2008-05-05 11:45:19
> +}:{
> 2008-06-05 11:45:19 +}"
> https://mysubversionsrv/svndev/test/trunk/TestWebapp
> [INFO] Working directory: D:\devs\projects\Test\workspace\TestWebapp
> [INFO] Generating "Developer Activity" report.
> [INFO] Using existing changelog.xml...
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error occurred while parsing
> D:
> \devs\projects\Test\workspace\TestWebapp\target\changelog.xml
> Invalid byte 1 of 1-byte UTF-8 sequence.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 39 seconds
> [INFO] Finished at: Wed Jun 04 13:45:23 CEST 2008
> [INFO] Final Memory: 41M/63M
> [INFO]
>
> The file changelog.xml contains the good header line ( encoding="UTF-8"?>), but the file is encoded with ANSI UNIX charset
--
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: (MCHANGELOG-87) Wrong svn path if artifactid != directory
[
http://jira.codehaus.org/browse/MCHANGELOG-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCHANGELOG-87.
--
Resolution: Won't Fix
Add a scm element in your pom and everything will work.
> Wrong svn path if artifactid != directory
> -
>
> Key: MCHANGELOG-87
> URL: http://jira.codehaus.org/browse/MCHANGELOG-87
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: windows, Subversion 1.5
>Reporter: Kuno Baeriswyl
>
> site generate fails, since artifactId and directory name are not equal
> (project-foo != project_foo) :
> [INFO] Executing: svn --non-interactive log -v -r "{2008-09-22 14:39:55
> +}:{2008-10-23 14:39:55 +}" http://$repo$/trunk/sub1/project-foo
> [INFO] Working directory: d:\maven-projects\bats-upgrade\sub1\project_foo
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: '/mcs/bats-upgrade/!svn/bc/18337/trunk/sub1/project-foo' path
> not found
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: An error has occurred during
> changelog command :
> Command failed.
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 28 seconds
> [INFO] Finished at: Wed Oct 22 16:39:56 CEST 2008
> [INFO] Final Memory: 35M/512M
> [INFO]
>
--
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: (SCM-462) Unparseable date exception if the date format is other than yyyy-MM-dd for the date range
[ http://jira.codehaus.org/browse/SCM-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy moved MCHANGELOG-81 to SCM-462: Affects Version/s: (was: 2.1) 1.2 Complexity: Intermediate Key: SCM-462 (was: MCHANGELOG-81) Project: Maven SCM (was: Maven 2.x Changelog Plugin) > Unparseable date exception if the date format is other than -MM-dd for > the date range > - > > Key: SCM-462 > URL: http://jira.codehaus.org/browse/SCM-462 > Project: Maven SCM > Issue Type: Bug >Affects Versions: 1.2 > Environment: Perforce SCM >Reporter: Sudharma Rao >Priority: Critical > > Getting following error if the date format is other than -MM-dd as in > case of Perforce SCM > Embedded error: An error has occurred during changelog command : > Unparseable date: "2008/02/08 01:01:01" > Following is the plugin configuration and I'm using Perforce SCM. > > org.apache.maven.plugins > maven-changelog-plugin > > /MM/dd HH:mm:ss > date > > 2008/02/08 01:01:01 > 2008/02/01 01:01:01 > > > > Cause: > The date format is hardcoded to "-MM-dd" at line 572 in > org/apache/maven/plugin/changelog/ChangeLogReport.java > Solution: > The SCM plugin uses ' /MM/dd HH:mm:ss' > for the start and end date. The Changelog plugin doesn't use this. Please > make it use either 'userDateFormat' or 'dateFormat' for parsing date. -- 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: (MCHANGELOG-91) mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5 (svn: PROPFIND authorization failed)
[
http://jira.codehaus.org/browse/MCHANGELOG-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174526#action_174526
]
Olivier Lamy commented on MCHANGELOG-91:
Have you tested with last deployed SNAPSHOT ? Can you confirm it's fixed ?
> mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5 (svn:
> PROPFIND authorization failed)
> ---
>
> Key: MCHANGELOG-91
> URL: http://jira.codehaus.org/browse/MCHANGELOG-91
> Project: Maven 2.x Changelog Plugin
> Issue Type: Bug
> Environment: OSX 10.5
>Reporter: Laurent Perez
>Priority: Critical
>
> hi
> mvn changelog:changelog svn --non-interactive fails under Mac OSX 10.5, stack
> below :
> [INFO] Executing: svn --non-interactive log -v -r "{2008-11-12 22:21:45
> +}:{2008-12-13 22:21:45 +}" http://xx/
> [INFO] Working directory: /Users/laurent/Desktop/x
> [ERROR] Provider message:
> [ERROR] The svn command failed.
> [ERROR] Command output:
> [ERROR] svn: PROPFIND request failed on '/'
> svn: PROPFIND of '/x': authorization failed (http://x)
> I believe this may be linked to http://jira.codehaus.org/browse/SCM-402 ,
> however, I am using maven-scm-plugin version 1.1 in my pom.xml, but perhaps
> the changelog plugin does not use this 1.1 version.
> Can anyone confirm ?
> thanks
> laurent
--
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-4137) NPE in DefaultLIfecycleExecutor when run from within Hudson builds
[ http://jira.codehaus.org/browse/MNG-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-4137. --- Resolution: Fixed > NPE in DefaultLIfecycleExecutor when run from within Hudson builds > -- > > Key: MNG-4137 > URL: http://jira.codehaus.org/browse/MNG-4137 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1.0 > Environment: Hudson ver. 1.299 > Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) > Java version: 1.6.0_12 > Java home: /usr/java/jdk1.6.0_12/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.18-92.1.18.el5" arch: "i386" Family: "unix" >Reporter: Jonathan Johnson >Assignee: John Casey > Fix For: 2.1.1 > > > Since upgrading from Maven 2.0.10 to 2.1.0 my Hudson midnight job that runs > "clean site" fails with a NullPointerException at > DefaultLifecycleExecutor.java:747 exception. See below. > This is related, if not the same bug that was claimed fixed in 2.1.0 M1 - > http://jira.codehaus.org/browse/MNG-3704 > I though its was an issue with the Cobertura plugin - See > https://hudson.dev.java.net/issues/show_bug.cgi?id=3468 but once I remove > Cobertura I now get the same stack trace after "[INFO] Preparing > surefire-report:report": > [INFO] Preparing surefire-report:report > [HUDSON] Archiving [...omittted for this posting...] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.calculateConcreteConfiguration(DefaultLifecycleExecutor.java:747) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:578) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1168) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1009) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:647) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > 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.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65) > 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 hudson.maven.agent.Main.launch(Main.java:158) > at hudson.maven.MavenBuilder.call(MavenBuilder.java:162) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:578) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:524) > at hudson.remoting.UserRequest.perform(UserRequest.java:97) > at hudson.remoting.UserRequest.perform(UserRequest.java:46) > at hudson.remoting.Request$2.run(Request.java:236) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at
[jira] Closed: (MNG-4146) password security doesn't work with custom password providers
[ http://jira.codehaus.org/browse/MNG-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-4146. --- Resolution: Fixed > password security doesn't work with custom password providers > - > > Key: MNG-4146 > URL: http://jira.codehaus.org/browse/MNG-4146 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.0 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1.1 > > > The _decryptors field is not populated in the component descriptor definition > for ...SecDispatcher:maven. Since plexus-sec-dispatcher provides a correct > component definition for this, maybe we can do away with the maven > role-hinted component, and use the default instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4054) Command Line interprets bogus options
[ http://jira.codehaus.org/browse/MNG-4054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4054: Fix Version/s: (was: 2.1.1) 2.x > Command Line interprets bogus options > - > > Key: MNG-4054 > URL: http://jira.codehaus.org/browse/MNG-4054 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.10, 2.1.0-M1, 3.0-alpha-1, 3.0-alpha-2 >Reporter: Paul Benedict >Assignee: John Casey >Priority: Minor > Fix For: 2.x > > > The command line interpreter obviously only matches against the starting > portion of a known option. > To execute offline, this is acceptable: mvn -outside > To execute in debug mode, this is acceptable mvn -XOXOXOXOXOX > You can do this with any option. Get the first couple letters right and > you'll trigger perhaps an unintended option. -- 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-4133) ssh-external wagon can not be overridden on its own
[ http://jira.codehaus.org/browse/MNG-4133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174523#action_174523 ] John Casey commented on MNG-4133: - doesn't this affect any extension that could possibly share one of the shared/common dependencies? In other words, anybody who implemented their own http wagon that depended on http-shared should run into this same problem, right? I'm just saying...while we're here. > ssh-external wagon can not be overridden on its own > --- > > Key: MNG-4133 > URL: http://jira.codehaus.org/browse/MNG-4133 > Project: Maven 2 > Issue Type: Bug > Components: Class Loading >Affects Versions: 2.1.0 >Reporter: Brett Porter > Fix For: 2.1.1 > > > when a project only overrides the ssh-external wagon, it causes the wagon-ssh > that is built in to fail to load (probably because of a classloading conflict > with ssh-common). See the linked issue for details. > A couple of fixes are needed here: > - don't crash the entire extension loading mechanism because one extension > failed to load > - possibly shade the common ssh JAR in the core so it doesn't cause the > conflict in the first place. -- 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: (WAGON-260) very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header
[ http://jira.codehaus.org/browse/WAGON-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174512#action_174512 ] John Casey commented on WAGON-260: -- I haven't tried all JDKs, only on 1.5 so far. I'll try to extract the unit tests I wrote up, and post it here. IMO, there is very little reason not to decommission the lightweight http wagon...particularly now that the webdav wagon uses httpclient. > very long passwords cause LightweightHTTP wagon to line-wrap the > Base64-encoded Authorization header > > > Key: WAGON-260 > URL: http://jira.codehaus.org/browse/WAGON-260 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0-beta-5 >Reporter: John Casey > > this is because of Sun's Base64 and HTTPURLConnection implementations, which > the lightweight http wagon depends upon. -- 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: (MINSTALL-54) [INFO] Error installing artifact's metadata
[ http://jira.codehaus.org/browse/MINSTALL-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174510#action_174510 ] Erik Husby commented on MINSTALL-54: I've just started seeing this same problem. I am running Maven builds from the Bamboo build server on a faster machine than I was on and am running multiple builds simultaneously. > [INFO] Error installing artifact's metadata > --- > > Key: MINSTALL-54 > URL: http://jira.codehaus.org/browse/MINSTALL-54 > Project: Maven 2.x Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.2 > Environment: Windows XP >Reporter: geoff simpson > > [INFO] Error installing artifact's metadata: Error installing metadata: Error > updating group repository metadata > end tag not allowed in epilog but got / (position: END_TAG seen ...\n > Looks like there might be an issue with updates to maven-metadata-local.xml > during the mvn install task. we have a build server that is multi threaded. > we often see this in the > > > > maven-metadata-local.xml. > maybe a solution is to add maven-metadata-local.xml.lock to ensure two > threads don't update the file at the same time -- 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: (WAGON-260) very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header
[ http://jira.codehaus.org/browse/WAGON-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174507#action_174507 ] Brett Porter commented on WAGON-260: is this something that can be fixed in the lightweight wagon, or is the resolution just "use httpclient"? does this exhibit in all versions of the JDK? > very long passwords cause LightweightHTTP wagon to line-wrap the > Base64-encoded Authorization header > > > Key: WAGON-260 > URL: http://jira.codehaus.org/browse/WAGON-260 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http-lightweight >Affects Versions: 1.0-beta-5 >Reporter: John Casey > > this is because of Sun's Base64 and HTTPURLConnection implementations, which > the lightweight http wagon depends upon. -- 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-4137) NPE in DefaultLIfecycleExecutor when run from within Hudson builds
[ http://jira.codehaus.org/browse/MNG-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4137: Fix Version/s: 2.1.1 This is easy enough to take care of; I'll add similar code for the configInterpolator field as I did for the modelInterpolator field. > NPE in DefaultLIfecycleExecutor when run from within Hudson builds > -- > > Key: MNG-4137 > URL: http://jira.codehaus.org/browse/MNG-4137 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1.0 > Environment: Hudson ver. 1.299 > Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) > Java version: 1.6.0_12 > Java home: /usr/java/jdk1.6.0_12/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.18-92.1.18.el5" arch: "i386" Family: "unix" >Reporter: Jonathan Johnson >Assignee: John Casey > Fix For: 2.1.1 > > > Since upgrading from Maven 2.0.10 to 2.1.0 my Hudson midnight job that runs > "clean site" fails with a NullPointerException at > DefaultLifecycleExecutor.java:747 exception. See below. > This is related, if not the same bug that was claimed fixed in 2.1.0 M1 - > http://jira.codehaus.org/browse/MNG-3704 > I though its was an issue with the Cobertura plugin - See > https://hudson.dev.java.net/issues/show_bug.cgi?id=3468 but once I remove > Cobertura I now get the same stack trace after "[INFO] Preparing > surefire-report:report": > [INFO] Preparing surefire-report:report > [HUDSON] Archiving [...omittted for this posting...] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.calculateConcreteConfiguration(DefaultLifecycleExecutor.java:747) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:578) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1168) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1009) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:647) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > 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.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65) > 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 hudson.maven.agent.Main.launch(Main.java:158) > at hudson.maven.MavenBuilder.call(MavenBuilder.java:162) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:578) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:524) > at hudson.remoting.UserRequest.perform(UserRequest.java:97) > at hudson.remoting.UserRequest.perform(UserRequest.java:46) > at hudson.remoting.Request$2.run(Request.java:236) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.
[jira] Commented: (MNG-4137) NPE in DefaultLIfecycleExecutor when run from within Hudson builds
[
http://jira.codehaus.org/browse/MNG-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174496#action_174496
]
John Casey commented on MNG-4137:
-
The problem seems to be that Hudson provides its own version of the
LifecycleExecutor, component descriptor; when the component descriptor or the
class itself changes, there may be NPE's or CompositionExceptions that result,
since the class and component descriptor may not match up anymore.
This happened in the previous issue when we added a new field to the
DefaultLifecycleExecutor. Since Hudson's version of the component descriptor
hadn't changed accordingly, the new field was never populated, and a NPE was
generated. The "solution" was to warn the user that the new part of the build
couldn't be executed:
>From DefaultLifecycleExecutor.java, line 1962:
{code}
private void warnOfIncompleteComponentConfiguration( String role )
{
StringBuffer buffer = new StringBuffer();
buffer.append( "\n WARNING " );
buffer.append( "\n\nThis Maven runtime contains a LifecycleExecutor
component with an incomplete configuration." );
buffer.append( "\n\nLifecycleExecutor class: " ).append(
getClass().getName() );
buffer.append( "\nMissing component requirement: " ).append( role );
buffer.append( "\n" );
buffer.append( "\nNOTE: This seems to be a third-party Maven derivative
you are using. If so, please" );
buffer.append( "\nnotify the developers for this derivative project of
the problem. The Apache Maven team is not" );
buffer.append( "\nresponsible for maintaining the integrity of
third-party component overrides." );
buffer.append( "\n\n" );
getLogger().warn( buffer.toString() );
}
{code}
> NPE in DefaultLIfecycleExecutor when run from within Hudson builds
> --
>
> Key: MNG-4137
> URL: http://jira.codehaus.org/browse/MNG-4137
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.1.0
> Environment: Hudson ver. 1.299
> Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400)
> Java version: 1.6.0_12
> Java home: /usr/java/jdk1.6.0_12/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux" version: "2.6.18-92.1.18.el5" arch: "i386" Family: "unix"
>Reporter: Jonathan Johnson
>
> Since upgrading from Maven 2.0.10 to 2.1.0 my Hudson midnight job that runs
> "clean site" fails with a NullPointerException at
> DefaultLifecycleExecutor.java:747 exception. See below.
> This is related, if not the same bug that was claimed fixed in 2.1.0 M1 -
> http://jira.codehaus.org/browse/MNG-3704
> I though its was an issue with the Cobertura plugin - See
> https://hudson.dev.java.net/issues/show_bug.cgi?id=3468 but once I remove
> Cobertura I now get the same stack trace after "[INFO] Preparing
> surefire-report:report":
> [INFO] Preparing surefire-report:report
> [HUDSON] Archiving [...omittted for this posting...]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.calculateConcreteConfiguration(DefaultLifecycleExecutor.java:747)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:578)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1168)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1009)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:647)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
> 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.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
>
[jira] Updated: (MJAR-118) Upgrade maven-archiver dependency to 2.4
[
http://jira.codehaus.org/browse/MJAR-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MJAR-118:
-
Summary: Upgrade maven-archiver dependency to 2.4 (was: Please release a
version that supports from maven-archiver 2.4)
> Upgrade maven-archiver dependency to 2.4
>
>
> Key: MJAR-118
> URL: http://jira.codehaus.org/browse/MJAR-118
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Sören Chittka
>Priority: Critical
>
> Hi,
> currently I am using the maven-jar-plugin 2.2.
> One of my project-teams really has the need to specify the
> introduced with maven-archiver 2.4.
> Just adding maven-archiver 2.4 to the dependencies of the maven-jar-plugin
> did not help.
> What I am trying is to use following -entry in maven-jar-plugin:
>
> true
> custom
>
> ${artifact.artifactId}.${artifact.extension}
>
> But the classpath-entries are only resolved to null.null, I guess 'artifact'
> is not resolved to anything.
--
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-4137) NPE in DefaultLIfecycleExecutor when run from within Hudson builds
[ http://jira.codehaus.org/browse/MNG-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174495#action_174495 ] Jonathan Johnson commented on MNG-4137: --- Some people are tracking the same issue here. https://hudson.dev.java.net/issues/show_bug.cgi?id=2373 > NPE in DefaultLIfecycleExecutor when run from within Hudson builds > -- > > Key: MNG-4137 > URL: http://jira.codehaus.org/browse/MNG-4137 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.1.0 > Environment: Hudson ver. 1.299 > Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) > Java version: 1.6.0_12 > Java home: /usr/java/jdk1.6.0_12/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.18-92.1.18.el5" arch: "i386" Family: "unix" >Reporter: Jonathan Johnson > > Since upgrading from Maven 2.0.10 to 2.1.0 my Hudson midnight job that runs > "clean site" fails with a NullPointerException at > DefaultLifecycleExecutor.java:747 exception. See below. > This is related, if not the same bug that was claimed fixed in 2.1.0 M1 - > http://jira.codehaus.org/browse/MNG-3704 > I though its was an issue with the Cobertura plugin - See > https://hudson.dev.java.net/issues/show_bug.cgi?id=3468 but once I remove > Cobertura I now get the same stack trace after "[INFO] Preparing > surefire-report:report": > [INFO] Preparing surefire-report:report > [HUDSON] Archiving [...omittted for this posting...] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.calculateConcreteConfiguration(DefaultLifecycleExecutor.java:747) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:578) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:1168) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:1009) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:647) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > 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.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65) > 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 hudson.maven.agent.Main.launch(Main.java:158) > at hudson.maven.MavenBuilder.call(MavenBuilder.java:162) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:578) > at > hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:524) > at hudson.remoting.UserRequest.perform(UserRequest.java:97) > at hudson.remoting.UserRequest.perform(UserRequest.java:46) > at hudson.remoting.Request$2.run(Request.java:236) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.ut
[jira] Created: (ARCHETYPE-242) The "remote" archchetype-catalog doesn't really exist.
The "remote" archchetype-catalog doesn't really exist. -- Key: ARCHETYPE-242 URL: http://jira.codehaus.org/browse/ARCHETYPE-242 Project: Maven Archetype Issue Type: Bug Reporter: Jörg Henne Priority: Minor This page http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-catalog.html states that the default "remote" catalog is located at http://repo1.maven.org/maven2/archetype-catalog.xml. However, there is no such file on repo1.maven.org and thus the remote catalog is useless. -- 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-4147) very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header
[ http://jira.codehaus.org/browse/MNG-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174490#action_174490 ] John Casey commented on MNG-4147: - We should move to the httpclient-based http wagon to avoid problems in Sun's HTTPURLConnection code. > very long passwords cause LightweightHTTP wagon to line-wrap the > Base64-encoded Authorization header > > > Key: MNG-4147 > URL: http://jira.codehaus.org/browse/MNG-4147 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1.1 > > > I'll cross-file (and link) this issue into wagon, but Sun's HTTPURLConnection > implementation uses a line-wrapping Base64 implementation. When passwords are > very long, this causes an invalid HTTP request, since the Authorization > header's value is line-wrapped. -- 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-4147) very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header
[ http://jira.codehaus.org/browse/MNG-4147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-4147: Assignee: John Casey Affects Version/s: 2.1.0 Fix Version/s: 2.1.1 Component/s: Artifacts and Repositories We're already using httpclient for the webdav wagon in maven 2.1.0, so the main reason for using HTTPURLConnection historically is moot. > very long passwords cause LightweightHTTP wagon to line-wrap the > Base64-encoded Authorization header > > > Key: MNG-4147 > URL: http://jira.codehaus.org/browse/MNG-4147 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1.0 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.1.1 > > > I'll cross-file (and link) this issue into wagon, but Sun's HTTPURLConnection > implementation uses a line-wrapping Base64 implementation. When passwords are > very long, this causes an invalid HTTP request, since the Authorization > header's value is line-wrapped. -- 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: (WAGON-260) very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header
very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header Key: WAGON-260 URL: http://jira.codehaus.org/browse/WAGON-260 Project: Maven Wagon Issue Type: Bug Components: wagon-http-lightweight Affects Versions: 1.0-beta-5 Reporter: John Casey this is because of Sun's Base64 and HTTPURLConnection implementations, which the lightweight http wagon depends upon. -- 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-4147) very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header
very long passwords cause LightweightHTTP wagon to line-wrap the Base64-encoded Authorization header Key: MNG-4147 URL: http://jira.codehaus.org/browse/MNG-4147 Project: Maven 2 Issue Type: Bug Reporter: John Casey I'll cross-file (and link) this issue into wagon, but Sun's HTTPURLConnection implementation uses a line-wrapping Base64 implementation. When passwords are very long, this causes an invalid HTTP request, since the Authorization header's value is line-wrapped. -- 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: (MPDF-10) Support menu sub-items in table of contents
Support menu sub-items in table of contents --- Key: MPDF-10 URL: http://jira.codehaus.org/browse/MPDF-10 Project: Maven 2.x PDF Plugin Issue Type: New Feature Reporter: Lukas Theussl Currently, every source document starts a new chapter. -- 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: (MPDF-9) Use site.xml for PDF document structure
Use site.xml for PDF document structure --- Key: MPDF-9 URL: http://jira.codehaus.org/browse/MPDF-9 Project: Maven 2.x PDF Plugin Issue Type: New Feature Reporter: Lukas Theussl Currently a pdf.xml is required, if there is none then all documents are processed in unspecified order. -- 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: (MPDF-8) Create one PDF from a multi module project
Create one PDF from a multi module project -- Key: MPDF-8 URL: http://jira.codehaus.org/browse/MPDF-8 Project: Maven 2.x PDF Plugin Issue Type: New Feature Reporter: Lukas Theussl -- 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: (MDEP-210) Support includes/excludes configuration in analyze
Support includes/excludes configuration in analyze -- Key: MDEP-210 URL: http://jira.codehaus.org/browse/MDEP-210 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: analyze Reporter: Paul Gier Assignee: Brian Fox Sometimes there are dependencies present in the project that are required but analyze reports that they are not used. An example would be a jar that is used sometimes at runtime, but not always. There should be a way to configure the plugin so that these dependencies can be excluded from the analysis and will not show up in the warning list. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-443) Add a mojo parameter for using the new remote tagging for svn scm provider (to prevent issue with svn > 1.5.0 in release:branch)
[ http://jira.codehaus.org/browse/MRELEASE-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174451#action_174451 ] Wojtas Koziej commented on MRELEASE-443: Sorry. There is already an issue MRELEASE-433. We can reject this issue. > Add a mojo parameter for using the new remote tagging for svn scm provider > (to prevent issue with svn > 1.5.0 in release:branch) > > > Key: MRELEASE-443 > URL: http://jira.codehaus.org/browse/MRELEASE-443 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-7, 2.0-beta-9 >Reporter: Wojtas Koziej > -- 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: (MCHANGELOG-85) Use the members Name in the changelog.html
[ http://jira.codehaus.org/browse/MCHANGELOG-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=174436#action_174436 ] Arnaud commented on MCHANGELOG-85: -- am I alone :-) > Use the members Name in the changelog.html > -- > > Key: MCHANGELOG-85 > URL: http://jira.codehaus.org/browse/MCHANGELOG-85 > Project: Maven 2.x Changelog Plugin > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Maven 2.0.8 >Reporter: Arnaud >Priority: Minor > > Why doesn't replace the member ID in the changelog.html by the member Name > when its possible (like it is in the dev-activity.html) > Or if it's was not possible, juste add a link to team-list.html like this : > team-list.html #IDnumber -- 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: (MECLIPSE-178) symbolic links need to able to be specified in the pom
[ http://jira.codehaus.org/browse/MECLIPSE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-178: - Attachment: MECLIPSE-178.patch The patch corresponding to modified files > symbolic links need to able to be specified in the pom > -- > > Key: MECLIPSE-178 > URL: http://jira.codehaus.org/browse/MECLIPSE-178 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Jim Sellers > Attachments: EclipseProjectWriter.java, LinkedResourceCommand.java, > MECLIPSE-178.patch, mylyn-context.zip > > > In eclipse, you can make a symbolic link to a file. > create new file -> advanced -> "link to file in the system". > This will create a part in the .project file like this: > > > src/test/resources/oracle-ds.xml > 1 > > C://jboss/server/default/deploy/oracle-ds.xml > > > When you run "mvn eclipse:eclipse" this gets wipped out. It would be great > if this soft link didn't have to be re-created someone runs the command. -- 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: (MECLIPSE-178) symbolic links need to able to be specified in the pom
[ http://jira.codehaus.org/browse/MECLIPSE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-178: - Attachment: mylyn-context.zip > symbolic links need to able to be specified in the pom > -- > > Key: MECLIPSE-178 > URL: http://jira.codehaus.org/browse/MECLIPSE-178 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Jim Sellers > Attachments: EclipseProjectWriter.java, LinkedResourceCommand.java, > MECLIPSE-178.patch, mylyn-context.zip > > > In eclipse, you can make a symbolic link to a file. > create new file -> advanced -> "link to file in the system". > This will create a part in the .project file like this: > > > src/test/resources/oracle-ds.xml > 1 > > C://jboss/server/default/deploy/oracle-ds.xml > > > When you run "mvn eclipse:eclipse" this gets wipped out. It would be great > if this soft link didn't have to be re-created someone runs the command. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2441) rsync part of the scala-tools.org repository - not working
rsync part of the scala-tools.org repository - not working -- Key: MAVENUPLOAD-2441 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2441 Project: Maven Upload Requests Issue Type: Bug Reporter: Anthony Whitford I don't think the rsync for the Scala-Tools.org, requested by issue MAVENUPLOAD-2344, is working. I say this because version 2.7.4 (for example) is available at: http://scala-tools.org/repo-releases/org/scala-lang/scala-library/ but this version is not available on central: http://repo1.maven.org/maven2/org/scala-lang/scala-library/ There is a subtle error on the original issue that I think might be intefering with the rsync... http://scala-tools.org/repo-releases does not work, but http://scala-tools.org/repo-releases/ does work. (The trailing slash is required.) -- 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
