[jira] Commented: (MNG-553) Secure Storage of Server Passwords
[ http://jira.codehaus.org/browse/MNG-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145297#action_145297 ] Brett Porter commented on MNG-553: -- as long as one implementation uses a Java keystore, you can use the Keychain on OS X: http://developer.apple.com/documentation/Java/Conceptual/Java14Development/04-JavaUIToolkits/JavaUIToolkits.html#//apple_ref/doc/uid/TP40001901-210260 However, I don't believe this will give access to existing internet passwords, etc. It just allows you to store keys in there. > Secure Storage of Server Passwords > -- > > Key: MNG-553 > URL: http://jira.codehaus.org/browse/MNG-553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0-alpha-3 > Environment: Although it may not be relevant since this is a general > improvement issue, Windows XP, JDK 1.4.1. >Reporter: J. Michael McGarr >Assignee: Brett Porter >Priority: Critical > Fix For: 3.0 > > > This was a question pose to the Maven User's Group and it was suggested I add > it here. > It would be benefitial to provide a more secure means of storing password's > to the servers listed in the .m2/settings.xml. They are currently being > stored as plain text and could definately be considered a security breach. > Numerous organizations would undoubtedly considered this an unacceptable > security risk, and this could prevent widespread adoption of Maven2. > I would suggest leaving an option to encrypt the password into the settings > file (more secure, but not foolproof) or even requiring the password to be > manually provided per build (would prevent automation of builds). I am sure > that there is a secure solution to this problem and it should be part of the > 2.0 release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3314) offline build not running, when having SNAPSHOT dependencies
[
http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145306#action_145306
]
henrik242 edited comment on MNG-3314 at 8/18/08 4:06 AM:
The problem seems to be related to the ctime of the SNAPSHOT artifacts.
I have a hierarchal project where sub project B depend on subproject A. A and
B are modules in the root pom:
{code}
root-+--A
|
+--B
{code}
Here are the scenarios (with maven 2.0.9):
- If I build the full project offline from the root project, everything works
fine.
- If I build project B immediately afterwards (offline), everything works fine.
- If I wait awhile (an hour? a day? I can't remember) and build project B
again (offline), it complains about a missing snapshot dependency to the A
project. Now for the fix: If I touch the "missing" snapshot jars ({{touch
~/.m2/repository/myproject/A/1.0-SNAPSHOT/*}}) and build project B offline
again, everything works fine again.
It seems that the snapshot artifacts have a maximum availability lifetime in
offline mode.
was (Author: henrik242):
The problem seems to be related to the filectime of the SNAPSHOT artifacts.
I have a hierarchal project where sub project B depend on subproject A. A and
B are modules in the root pom:
{code}
root-+--A
|
+--B
{code}
Here are the scenarios (with maven 2.0.9):
- If I build the full project offline from the root project, everything works
fine.
- If I build project B immediately afterwards (offline), everything works fine.
- If I wait awhile (an hour? a day? I can't remember) and build project B
again (offline), it complains about a missing snapshot dependency to the A
project. Now for the fix: If I touch the "missing" snapshot jars ({{touch
~/.m2/repository/myproject/A/1.0-SNAPSHOT/*}}) and build project B offline
again, everything works fine again.
It seems that the snapshot artifacts have a maximum availability lifetime in
offline mode.
> offline build not running, when having SNAPSHOT dependencies
>
>
> Key: MNG-3314
> URL: http://jira.codehaus.org/browse/MNG-3314
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.7
>Reporter: Matthias Weßendorf
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.11
>
> Attachments: maven-offline-snapshot-failure.log,
> maven-offline-snapshot-problem.tar
>
>
> am having troubles with
> mvn ... -o
> (with maven 2.0.7)
> says not able to download (but, really, the file is in my local repo)
> The dependency is a -SNAPSHOT (for what's worth)
> Luckily, when traveling by train, I had maven 2.0.4 on my box as well.
> A change to use 2.0.4 works fine.
> So, is this an already know bug in 2.0.7 ?
> To my understanding it is a bug, since offline just shouldn't try to get a
> newer
> SNAPSHOT, perhaps I am wrong.
> I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect
> just not checking for new stuff.
> and... for some reasons, sometimes,
> it just downloads a new SNAPSHOT.
> That is a pain, when you are "maintaining" the same snapshot on your
> box, but the build just goes ahead and actually downloads a version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3314) offline build not running, when having SNAPSHOT dependencies
[
http://jira.codehaus.org/browse/MNG-3314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145306#action_145306
]
Henrik Brautaset Aronsen commented on MNG-3314:
---
The problem seems to be related to the filectime of the SNAPSHOT artifacts.
I have a hierarchal project where sub project B depend on subproject A. A and
B are modules in the root pom:
{code}
root-+--A
|
+--B
{code}
Here are the scenarios (with maven 2.0.9):
- If I build the full project offline from the root project, everything works
fine.
- If I build project B immediately afterwards (offline), everything works fine.
- If I wait awhile (an hour? a day? I can't remember) and build project B
again (offline), it complains about a missing snapshot dependency to the A
project. Now for the fix: If I touch the "missing" snapshot jars ({{touch
~/.m2/repository/myproject/A/1.0-SNAPSHOT/*}}) and build project B offline
again, everything works fine again.
It seems that the snapshot artifacts have a maximum availability lifetime in
offline mode.
> offline build not running, when having SNAPSHOT dependencies
>
>
> Key: MNG-3314
> URL: http://jira.codehaus.org/browse/MNG-3314
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.7
>Reporter: Matthias Weßendorf
>Assignee: John Casey
>Priority: Critical
> Fix For: 2.0.11
>
> Attachments: maven-offline-snapshot-failure.log,
> maven-offline-snapshot-problem.tar
>
>
> am having troubles with
> mvn ... -o
> (with maven 2.0.7)
> says not able to download (but, really, the file is in my local repo)
> The dependency is a -SNAPSHOT (for what's worth)
> Luckily, when traveling by train, I had maven 2.0.4 on my box as well.
> A change to use 2.0.4 works fine.
> So, is this an already know bug in 2.0.7 ?
> To my understanding it is a bug, since offline just shouldn't try to get a
> newer
> SNAPSHOT, perhaps I am wrong.
> I know that relying on SNAPSHOTs can be dangerous, but from -o I would expect
> just not checking for new stuff.
> and... for some reasons, sometimes,
> it just downloads a new SNAPSHOT.
> That is a pain, when you are "maintaining" the same snapshot on your
> box, but the build just goes ahead and actually downloads a version.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-401) Fix parseHostAndPort() for Bazaar too
Fix parseHostAndPort() for Bazaar too - Key: SCM-401 URL: http://jira.codehaus.org/browse/SCM-401 Project: Maven SCM Issue Type: Sub-task Components: maven-scm-provider-bazaar Affects Versions: 1.1 Reporter: Vincent Siveton parseHostAndPort() in Bazaar has the same error. -- 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: (SCM-401) Fix parseHostAndPort() for Bazaar too
[ http://jira.codehaus.org/browse/SCM-401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-401. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1 Fixed in [r686736|http://svn.apache.org/viewvc?rev=686736&view=rev] > Fix parseHostAndPort() for Bazaar too > - > > Key: SCM-401 > URL: http://jira.codehaus.org/browse/SCM-401 > Project: Maven SCM > Issue Type: Sub-task > Components: maven-scm-provider-bazaar >Affects Versions: 1.1 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 1.1 > > > parseHostAndPort() in Bazaar has the same error. -- 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: (SCM-391) urls without subfolders were not parsed correctly.
[
http://jira.codehaus.org/browse/SCM-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-391.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1
Fixed in [r6867356|http://svn.apache.org/viewvc?rev=686735&view=rev]
Added a test case.
> urls without subfolders were not parsed correctly.
> --
>
> Key: SCM-391
> URL: http://jira.codehaus.org/browse/SCM-391
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-mercurial (hg)
>Reporter: Stefan Ackermann
>Assignee: Vincent Siveton
> Fix For: 1.1
>
>
> Following configuration within pom.xml failed to do checkins:
> {code:xml}
>
> scm:hg:file:///${basedir}
> scm:hg:http://localhost:8000/
>
> {code}
> The error is that it is trying to push to a wrong location.
> [INFO] EXECUTING: hg push http://localhost8000/
> I have traced it down to this function of this file:
> http://svn.apache.org/viewvc/maven/scm/trunk/maven-scm-providers/maven-scm-provider-hg/src/main/java/org/apache/maven/scm/provider/hg/repository/HgScmProviderRepository.java?revision=528416&view=markup
> Here is a proposal from me on how to fix that.
> {code}
> private String parseHostAndPort( String url )
> {
> if ( protocol != FILE )
> {
> String[] split = url.split( ":" );
> if ( split.length == 2 )
> {
> setHost( split[0] );
> url = url.substring( split[0].length() + 1 );
> split = split[1].split( "/" );
> if ( split.length == 2 )
> {
> url = url.substring( split[0].length() );
> try
> {
> setPort( Integer.valueOf( split[0] ).intValue() );
> }
> catch ( NumberFormatException e )
> {
> //Ignore - error will manifest itself later.
> }
> }
> else if (url.matches("\\d+/?"))
> {
> url = url.replaceAll("/", "");
> try {
> setPort(Integer.valueOf(url));
> } catch (NumberFormatException e) {
> //Ignore - error will manifest itself later.
> }
> }
> }
> else
> {
> split = url.split( "/" );
> if ( split.length > 1 )
> {
> url = url.substring( split[0].length() );
> setHost( split[0] );
> }
> else if (url.matches("[^/]+/?"))
> {
> url = url.replaceAll("/", "");
> setHost(url);
> }
> }
> }
> return url;
> }
> {code}
> I have not run any unit tests, but I did run some tests against this function
> with some input strings. Seems to work.
> A URL like this is default if you just use hg serve so it is kind of common.
--
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: (SCM-390) scm:branch gives misleading error when branch name parameter is missing
[
http://jira.codehaus.org/browse/SCM-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-390.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1
Patch applied in [r686738|http://svn.apache.org/viewvc?rev=686738&view=rev].
Thanks!
> scm:branch gives misleading error when branch name parameter is missing
> ---
>
> Key: SCM-390
> URL: http://jira.codehaus.org/browse/SCM-390
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-plugin
>Affects Versions: 1.0
>Reporter: Mark Hobson
>Assignee: Vincent Siveton
>Priority: Minor
> Fix For: 1.1
>
> Attachments: SCM-390.patch
>
>
> Running scm:branch without a branch name results in the misleading error:
> {noformat}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Cannot run branch command :
> Embedded error: Exception while executing SCM command.
> Missing parameter: 'branchName'.
> [INFO]
>
> {noformat}
> The actual branch name parameter is called 'branch', but the error message
> complains about a missing 'branchName' parameter. This is due to the
> discrepancy between scm command and mojo parameter names.
> A good fix would be to mark the branch name mojo parameter as required, since
> the goal is pretty useless without it. This gives a better error message:
> {noformat}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] One or more required plugin parameters are invalid/missing for
> 'scm:branch'
> [0] Inside the definition for plugin 'maven-scm-plugin' specify the following:
>
> ...
> VALUE
>
> -OR-
> on the command line, specify: '-Dbranch=VALUE'
> [INFO]
>
> {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: (MANTTASKS-73) miss RemoteRepository sub-element for tasks pom and install-provider
[
http://jira.codehaus.org/browse/MANTTASKS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145327#action_145327
]
MArtin Schumacher commented on MANTTASKS-73:
the documentation at http://maven.apache.org/ant-tasks.html should be completed
> miss RemoteRepository sub-element for tasks pom and install-provider
>
>
> Key: MANTTASKS-73
> URL: http://jira.codehaus.org/browse/MANTTASKS-73
> Project: Maven 2.x Ant Tasks
> Issue Type: Wish
> Components: install-provider task, POM Integration
>Affects Versions: 2.0.6
> Environment: Ant 1.6.5 / Maven Ant Task 2.0.6
>Reporter: David N'DIAYE
> Fix For: 2.0.7
>
> Attachments: MANTTASKS-73.diff, MANTTASKS-73.tgz
>
>
> My pom have parent pom which is not in the {{repo1.maven.org}}. And i can't
> initialize it because maven task ant {{pom}} doesn't find parent pom.
> I need to have possibility to specify the remote repository like in the
> dependencies task
> {code:xml}
>
> **
>
>
> {code}
> I have the same problem with the {{install-provider}} to download my
> dependencies. I can't specify the remote repository, so i can't download all
> dependencies which is not in {{repo1.maven.org}}.
> {code:xml}
>
> **
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-516) Definition of multiple Suite-Files not working
Definition of multiple Suite-Files not working -- Key: SUREFIRE-516 URL: http://jira.codehaus.org/browse/SUREFIRE-516 Project: Maven Surefire Issue Type: Bug Components: TestNG support Affects Versions: 2.4.2 Environment: maven 2.0.9 Reporter: Andreas Höhmann maven-surefire-plugin /src/test/resources/Testsuite1.xml /src/test/resources/Testsuite2.xml /src/test/resources/Testsuite3.xml Will raise the error [INFO] Surefire report directory: d:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase\target\surefire-reports org.apache.maven.surefire.booter.SurefireExecutionException: Suite file d:\ws_sid\spice-sid\sid-base\sid-base-knowledgeb ase\src\test\resources\Testsuite1.xmld:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase\src\test\resources\Testsuite2.xml is not a valid file; nested exception is org.apache.maven.surefire.testset.TestSetFailedException: Suite file d: \ws_sid\spice-sid\sid-base\sid-base-knowledgebase\src\test\resources\Testsuite1.xmld:\ws_sid\spice-sid\sid-base\sid-ba se-knowledgebase\src\test\resources\Testsuite2.xml is not a valid file org.apache.maven.surefire.testset.TestSetFailedException: Suite file d:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase \src\test\resources\Testsuite1.xmld:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase\src\test\resources\Testsuite2.xml is not a valid file at org.apache.maven.surefire.testng.TestNGXmlTestSuite.locateTestSets(TestNGXmlTestSuite.java:129) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Workaround (put a ',' behind every suiteXmlFile): maven-surefire-plugin /src/test/resources/Testsuite1.xml, /src/test/resources/Testsuite2.xml, /src/test/resources/Testsuite3.xml, -- 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-2178) Please upload jSSLutils 0.5
Please upload jSSLutils 0.5 --- Key: MAVENUPLOAD-2178 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2178 Project: Maven Upload Requests Issue Type: Wish Reporter: Bruno Harbulot Hello, I'm the developer and project owner of jsslutils. Could you please upload this project in the repository? There is a test dependency to: * org.jsslutils:jsslutils-test-certificates:1.0.2 http://jsslutils.googlecode.com/files/jsslutils-test-certificates-1.0.2-bundle.jar * org.jsslutils:jsslutils-test-helpers:0.5 http://jsslutils.googlecode.com/files/jsslutils-test-helpers-0.5-bundle.jar There is also this related module: * org.jsslutils:jsslutils-extra-apachehttpclient3:0.5 http://jsslutils.googlecode.com/files/jsslutils-extra-apachehttpclient3-0.5-bundle.jar Thank you. Bruno. -- 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: (SCM-386) SCM plugin fails on "bootstrap" goal when shell environment has functions definitions
[ http://jira.codehaus.org/browse/SCM-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-386. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1 Fixed in [r686774|http://svn.apache.org/viewvc?rev=686774&view=rev] Using methods form [plexus-utils|http://plexus.codehaus.org/plexus-utils/] > SCM plugin fails on "bootstrap" goal when shell environment has functions > definitions > - > > Key: SCM-386 > URL: http://jira.codehaus.org/browse/SCM-386 > Project: Maven SCM > Issue Type: Bug > Components: maven-plugin >Reporter: LEONID ILYEVSKY >Assignee: Vincent Siveton > Fix For: 1.1 > > > When using scm:bootstrap, with goals to do after checkout: > mvn -Dgoals=compile scm:bootstrap > maven apparently spawns another process that will execute mvn command for > that goal. To set up the environment for the child process, it runs external > command (in case of Linux it is "env"), and tries to parse it, assuming that > every line of the output has "KEY=VALUE" format. However, when the > environment has shell functions in it, this logic fails. > I see two ways of fixing this. > 1. Just fix the parsing logic. > Pros: this will be compatible with everything it is compatible today. > Cons: parsing logic will be essentially more complex, because you need to > figure out multiline functions definitions. > 2. Use System.getEnv() to get the environment, make array of strings > containing "KEY=VALUE" expressions, and use it for the child process. > Pros: very clean and simple solution. I actually tested it, took 10 minutes > to do. > Cons: System.getEnv() became available as of JDK 1.5. Seems like all Maven2 > is supposed to be compatible with JDK 1.4, this might be a problem. -- 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-60) wagon-webdav fails with commons-logging classloader issues
[ http://jira.codehaus.org/browse/WAGON-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145340#action_145340 ] Fabrice Daugan commented on WAGON-60: - Also this problem causes an issue in dashboard plugin, since there is no way to constraint commons-logging artifact version inside the extension node. > wagon-webdav fails with commons-logging classloader issues > -- > > Key: WAGON-60 > URL: http://jira.codehaus.org/browse/WAGON-60 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-webdav >Affects Versions: 1.0-beta-1 > Environment: maven 2.0.4 >Reporter: Yuri Schimke >Assignee: Carlos Sanchez >Priority: Critical > > I tried it with a build extension and also putting jars in $M2_HOME/lib, but > both ways I get classloader issues with commons-logging. > My project uses commons logging and I've seen at least one other report that > it can be a problem. > with things in lib: > Caused by: org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.) (Caused by > org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.)) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:543) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235) > at > org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209) > at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351) > at > org.apache.commons.httpclient.HttpClient.(HttpClient.java:69) > ... 30 more > Caused by: org.apache.commons.logging.LogConfigurationException: > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. (Caused by > org.apache.commons.logging.LogConfigurationException: Invalid class loader > hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed.) > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:397) > at > org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529) > ... 34 more > Caused by: org.apache.commons.logging.LogConfigurationException: Invalid > class loader hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. > at > org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:385) > using build extension: > java.lang.ExceptionInInitializerError > at > org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:145) > at > org.apache.webdav.lib.WebdavSession.getSessionInstance(WebdavSession.java:127) > at > org.apache.webdav.lib.WebdavResource.setClient(WebdavResource.java:1273) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1298) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1320) > at > org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1408) > at > org.apache.webdav.lib.WebdavResource.(WebdavResource.java:290) > at > org.apache.maven.wagon.providers.webdav.CorrectedWebdavResource.(CorrectedWebdavResource.java:52) > at > org.apache.maven.wagon.providers.webdav.WebDavWagon.openConnection(WebDavWagon.java:139) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) > at > org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106) > at > org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:132) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLif
[jira] Created: (MECLIPSE-479) More "contaigner" entries
More "contaigner" entries - Key: MECLIPSE-479 URL: http://jira.codehaus.org/browse/MECLIPSE-479 Project: Maven 2.x Eclipse Plugin Issue Type: Sub-task Affects Versions: 2.5.1 Environment: N/A Reporter: David J. M. Karlsen Priority: Trivial Attachments: MECLIPSE-479.patch There are more entries containing "contaigner" as shown: :~/projects/asf/maven/trunks/plugins/maven-eclipse-plugin$ find . -type f |xargs fgrep -li contaigner|grep -v svn ./src/main/java/org/apache/maven/plugin/eclipse/writers/rad/RadEjbClasspathWriter.java ./src/main/java/org/apache/maven/plugin/eclipse/reader/ReadWorkspaceLocations.java -- 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-479) More "contaigner" entries
[ http://jira.codehaus.org/browse/MECLIPSE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David J. M. Karlsen updated MECLIPSE-479: - Attachment: MECLIPSE-479.patch > More "contaigner" entries > - > > Key: MECLIPSE-479 > URL: http://jira.codehaus.org/browse/MECLIPSE-479 > Project: Maven 2.x Eclipse Plugin > Issue Type: Sub-task >Affects Versions: 2.5.1 > Environment: N/A >Reporter: David J. M. Karlsen >Priority: Trivial > Attachments: MECLIPSE-479.patch > > > There are more entries containing "contaigner" as shown: > :~/projects/asf/maven/trunks/plugins/maven-eclipse-plugin$ find . -type f > |xargs fgrep -li contaigner|grep -v svn > ./src/main/java/org/apache/maven/plugin/eclipse/writers/rad/RadEjbClasspathWriter.java > ./src/main/java/org/apache/maven/plugin/eclipse/reader/ReadWorkspaceLocations.java -- 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-2179) Upload Stripes-1.5 to Maven Repository
Upload Stripes-1.5 to Maven Repository -- Key: MAVENUPLOAD-2179 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2179 Project: Maven Upload Requests Issue Type: Wish Reporter: Tim Fennell Could you please upload the stripes-1.5 bundle to the public maven repository. Thank! -- 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: (MECLIPSE-479) More "contaigner" entries
[ http://jira.codehaus.org/browse/MECLIPSE-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MECLIPSE-479. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 2.5.2 Applied in [r686814|http://svn.apache.org/viewvc?view=rev&revision=686814], thanks David! > More "contaigner" entries > - > > Key: MECLIPSE-479 > URL: http://jira.codehaus.org/browse/MECLIPSE-479 > Project: Maven 2.x Eclipse Plugin > Issue Type: Sub-task >Affects Versions: 2.5.1 > Environment: N/A >Reporter: David J. M. Karlsen >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: 2.5.2 > > Attachments: MECLIPSE-479.patch > > > There are more entries containing "contaigner" as shown: > :~/projects/asf/maven/trunks/plugins/maven-eclipse-plugin$ find . -type f > |xargs fgrep -li contaigner|grep -v svn > ./src/main/java/org/apache/maven/plugin/eclipse/writers/rad/RadEjbClasspathWriter.java > ./src/main/java/org/apache/maven/plugin/eclipse/reader/ReadWorkspaceLocations.java -- 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-3721) Qualified and unqualified actifact does not resolve dependencies identically
Qualified and unqualified actifact does not resolve dependencies identically Key: MNG-3721 URL: http://jira.codehaus.org/browse/MNG-3721 Project: Maven 2 Issue Type: Bug Components: Bootstrap & Build Affects Versions: 2.0.9 Environment: 2.0.9, JDK 1.6_07, Windows XPSP3 Reporter: Fabrice Daugan Priority: Blocker Attachments: output-qualified-offline.txt, output-qualified.txt, output-unqualified-offline.txt, output-unqualified.txt, pom.xml >mvn org.codehaus.mojo:dashboard-maven-plugin:1.0.0-beta-1:dashboard and >mvn dashboard:dashboard executions does not output same things : First output : Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. Second output : No error This is not a plugin dependant issue, but a maven one.The dependencies are not resolved the same way. Qualified as blocker since we are using two different dashbord plugins : "org.codehaus.mojo:dashboard-maven-plugin" and "com.xebia.mojo:maven-dashboard-plugin" So we need the qualified name to differenciate them, and also fails our site generation. As attachment the two outputs in debug mode for offline and not offline versions and the pom to reproduce the error. You'll see the "commons-logging:commons-logging:jar:1.1:compile" line in the "[DEBUG] Plugin dependencies for:" section, present in the unqualified output, but not in qualified output for offline/online version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3721) Qualified and unqualified actifact does not resolve dependencies identically
[ http://jira.codehaus.org/browse/MNG-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice Daugan updated MNG-3721: Attachment: pom.xml > Qualified and unqualified actifact does not resolve dependencies identically > > > Key: MNG-3721 > URL: http://jira.codehaus.org/browse/MNG-3721 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.9 > Environment: 2.0.9, JDK 1.6_07, Windows XPSP3 >Reporter: Fabrice Daugan >Priority: Blocker > Attachments: output-qualified-offline.txt, output-qualified.txt, > output-unqualified-offline.txt, output-unqualified.txt, pom.xml > > > >mvn org.codehaus.mojo:dashboard-maven-plugin:1.0.0-beta-1:dashboard > and > >mvn dashboard:dashboard > executions does not output same things : > First output : > Invalid class loader hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. > Second output : > No error > This is not a plugin dependant issue, but a maven one.The dependencies are > not resolved the same way. > Qualified as blocker since we are using two different dashbord plugins : > "org.codehaus.mojo:dashboard-maven-plugin" and > "com.xebia.mojo:maven-dashboard-plugin" > So we need the qualified name to differenciate them, and also fails our site > generation. > As attachment the two outputs in debug mode for offline and not offline > versions and the pom to reproduce the error. > You'll see the "commons-logging:commons-logging:jar:1.1:compile" line in the > "[DEBUG] Plugin dependencies for:" section, present in the unqualified > output, but not in qualified output for offline/online version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3721) Qualified and unqualified actifact does not resolve dependencies identically
[ http://jira.codehaus.org/browse/MNG-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice Daugan updated MNG-3721: Attachment: output-unqualified-offline.txt > Qualified and unqualified actifact does not resolve dependencies identically > > > Key: MNG-3721 > URL: http://jira.codehaus.org/browse/MNG-3721 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.9 > Environment: 2.0.9, JDK 1.6_07, Windows XPSP3 >Reporter: Fabrice Daugan >Priority: Blocker > Attachments: output-qualified-offline.txt, output-qualified.txt, > output-unqualified-offline.txt, output-unqualified.txt, pom.xml > > > >mvn org.codehaus.mojo:dashboard-maven-plugin:1.0.0-beta-1:dashboard > and > >mvn dashboard:dashboard > executions does not output same things : > First output : > Invalid class loader hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. > Second output : > No error > This is not a plugin dependant issue, but a maven one.The dependencies are > not resolved the same way. > Qualified as blocker since we are using two different dashbord plugins : > "org.codehaus.mojo:dashboard-maven-plugin" and > "com.xebia.mojo:maven-dashboard-plugin" > So we need the qualified name to differenciate them, and also fails our site > generation. > As attachment the two outputs in debug mode for offline and not offline > versions and the pom to reproduce the error. > You'll see the "commons-logging:commons-logging:jar:1.1:compile" line in the > "[DEBUG] Plugin dependencies for:" section, present in the unqualified > output, but not in qualified output for offline/online version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3721) Qualified and unqualified actifact does not resolve dependencies identically
[ http://jira.codehaus.org/browse/MNG-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145357#action_145357 ] Fabrice Daugan commented on MNG-3721: - The way to reproduce this error is simple, even with an empty repository executing the these command with the given pom : mvn org.codehaus.mojo:dashboard-maven-plugin:1.0.0-beta-1:dashboard mvn dashboard:dashboard > Qualified and unqualified actifact does not resolve dependencies identically > > > Key: MNG-3721 > URL: http://jira.codehaus.org/browse/MNG-3721 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.9 > Environment: 2.0.9, JDK 1.6_07, Windows XPSP3 >Reporter: Fabrice Daugan >Priority: Blocker > Attachments: output-qualified-offline.txt, output-qualified.txt, > output-unqualified-offline.txt, output-unqualified.txt, pom.xml > > > >mvn org.codehaus.mojo:dashboard-maven-plugin:1.0.0-beta-1:dashboard > and > >mvn dashboard:dashboard > executions does not output same things : > First output : > Invalid class loader hierarchy. You have more than one version of > 'org.apache.commons.logging.Log' visible, which is not allowed. > Second output : > No error > This is not a plugin dependant issue, but a maven one.The dependencies are > not resolved the same way. > Qualified as blocker since we are using two different dashbord plugins : > "org.codehaus.mojo:dashboard-maven-plugin" and > "com.xebia.mojo:maven-dashboard-plugin" > So we need the qualified name to differenciate them, and also fails our site > generation. > As attachment the two outputs in debug mode for offline and not offline > versions and the pom to reproduce the error. > You'll see the "commons-logging:commons-logging:jar:1.1:compile" line in the > "[DEBUG] Plugin dependencies for:" section, present in the unqualified > output, but not in qualified output for offline/online version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2180) please upload the new jdeb 0.7 release
please upload the new jdeb 0.7 release -- Key: MAVENUPLOAD-2180 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2180 Project: Maven Upload Requests Issue Type: Task Reporter: Torsten Curdt A new release -- 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: (MPIR-133) OutOfMemort when generating site
OutOfMemort when generating site Key: MPIR-133 URL: http://jira.codehaus.org/browse/MPIR-133 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.1 Environment: redhat linux, jdk 1.5, maven 2.0.9 Reporter: Lars Vonk Following exception occurs when running "mvn clean site" on project info reports plugin. 18-Aug-2008 14:49:04[INFO] 18-Aug-2008 14:49:04[ERROR] FATAL ERROR 18-Aug-2008 14:49:04[INFO] 18-Aug-2008 14:49:04[INFO] Java heap space 18-Aug-2008 14:49:04[INFO] 18-Aug-2008 14:49:04[DEBUG] Trace 18-Aug-2008 14:49:04java.lang.OutOfMemoryError: Java heap space 18-Aug-2008 14:49:04at java.util.zip.ZipEntry.initFields(Native Method) 18-Aug-2008 14:49:04at java.util.zip.ZipEntry.(ZipEntry.java:100) 18-Aug-2008 14:49:04at java.util.zip.ZipFile$3.nextElement(ZipFile.java:437) 18-Aug-2008 14:49:04at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415) 18-Aug-2008 14:49:04at java.util.jar.JarFile$1.nextElement(JarFile.java:221) 18-Aug-2008 14:49:04at java.util.jar.JarFile$1.nextElement(JarFile.java:220) 18-Aug-2008 14:49:04at java.util.Collections.list(Collections.java:3406) 18-Aug-2008 14:49:04at org.apache.maven.shared.jar.JarAnalyzer.(JarAnalyzer.java:105) 18-Aug-2008 14:49:04at org.apache.maven.report.projectinfo.dependencies.Dependencies.getJarDependencyDetails(Dependencies.java:282) 18-Aug-2008 14:49:04at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.hasSealed(DependenciesRenderer.java:1278) 18-Aug-2008 14:49:04at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderSectionDependencyFileDetails(DependenciesRenderer.java:423) 18-Aug-2008 14:49:04at org.apache.maven.report.projectinfo.dependencies.renderer.DependenciesRenderer.renderBody(DependenciesRenderer.java:268) This only occurs with 2.1, using 2.0.1 explicitly works fine. I increased the Xmx to 1024m, but the problem persists. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1968) JDom 1.1 is out
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145366#action_145366 ] Vincent Massol commented on MAVENUPLOAD-1968: - Would be nice to see jdom 1.1 in a maven repo... after all those years... ;) > JDom 1.1 is out > --- > > Key: MAVENUPLOAD-1968 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1968 > Project: Maven Upload Requests > Issue Type: New Feature >Reporter: Mirko Steinle >Assignee: Carlos Sanchez > Attachments: jdom-1.1-bundle.jar, pom-relocation.xml > > > Hello! > JDom has released a major version (1.1) last november. Could you please > upload it? > All files can be found at http://www.jdom.org/ > Thank you very much. > Mirko > P.S. I am only a user of JDom, but I guess the team won't have anything > against seeing their latest release uploaded... -- 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: (ARCHETYPE-199) Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes
[ http://jira.codehaus.org/browse/ARCHETYPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated ARCHETYPE-199: -- Summary: Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes (was: Missing archetypes for Struts2) 'mvn archetype:generate' tries to download 2.0.9-SNAPSHOT of the Struts 2 blank archetype. A released version of a Maven plugin should not have snapshot dependencies. (The Struts archetypes have not been officially released and should not be in the list the Archetype plugin presents to users.) > Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes > > > Key: ARCHETYPE-199 > URL: http://jira.codehaus.org/browse/ARCHETYPE-199 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_03 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Lukasz Lenart > > All archetypes to generate Struts2 application are missing from repo > http://people.apache.org/repo/m2-snapshot-repository/ but are still listed > when you launch mvn archetype:create > I think, they should be temporally removed from list till there be final > release. > Regards > -- > Lukasz > http://www.lenart.org.pl/ -- 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
