[jira] Closed: (MRM-139) scheduler issues
[ http://jira.codehaus.org/browse/MRM-139?page=all ] Edwin Punzalan closed MRM-139. -- Resolution: Fixed Fixed in SVN scheduler issues Key: MRM-139 URL: http://jira.codehaus.org/browse/MRM-139 Project: Archiva Issue Type: Bug Components: scheduling Reporter: Brett Porter Assigned To: Edwin Punzalan Fix For: 1.0-beta-1 the current scheduler has some issues: - it allows a task already in progress to run again (the ability to allow/prevent this should be configurable on a task by task basis - it should be either execute (double up anyway), wait (execute when the last finished), or skip (just wait until next scheduled)) - it appears that the task scheduler is swallowing runtime exceptions - shutdown often throws exceptions because of the way the tasks seem to be shutdown/destroyed after the scheduler itself -- 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: (CONTINUUM-970) Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared
Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared --- Key: CONTINUUM-970 URL: http://jira.codehaus.org/browse/CONTINUUM-970 Project: Continuum Issue Type: Improvement Reporter: Edwin Punzalan -- 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-2258) Wrong execution order of plugins in same phase
[ http://jira.codehaus.org/browse/MNG-2258?page=comments#action_78375 ] Martin Zeltner commented on MNG-2258: - BTW the patches appended to MNG-1412 does also solve the execution order problem of plugins. It does solve the order problem for all artifacts! Until today the HashSets and HashMaps where not replaced by LinkedHashSets and LinkedHashMaps (see SVN repo). I don't understand why commiters from these Maven 2 components don't apply the patches for such an important issue. I would help if I had commit rights but right now i can just watch and claim. Cheers, Martin http://el4j.sf.net Wrong execution order of plugins in same phase -- Key: MNG-2258 URL: http://jira.codehaus.org/browse/MNG-2258 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Environment: N/A Reporter: David J. M. Karlsen Fix For: 2.1 AFAIK plugins should be execute in the same order as they are listed in the POM, when bound to the same phase. This does not happen, the execution order is arbitrary. -- 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: (CONTINUUM-970) Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared
[ http://jira.codehaus.org/browse/CONTINUUM-970?page=all ] Edwin Punzalan updated CONTINUUM-970: - Attachment: CONTINUUM-970.patch Patch attached please apply. Thanks. Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared --- Key: CONTINUUM-970 URL: http://jira.codehaus.org/browse/CONTINUUM-970 Project: Continuum Issue Type: Improvement Reporter: Edwin Punzalan Assigned To: Edwin Punzalan Attachments: CONTINUUM-970.patch -- 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-122) Versionless Extension causes NullPointerException in release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-122?page=comments#action_78381 ] Vinod Panicker commented on MRELEASE-122: - I have the extension *with* a version and the plugin still spits out a NPE - extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ssh-external/artifactId version1.0-beta-1/version /extension /extensions Versionless Extension causes NullPointerException in release:prepare Key: MRELEASE-122 URL: http://jira.codehaus.org/browse/MRELEASE-122 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Stefan Hübner Attachments: patch.txt I'm getting a NullPointerException when invoking mvn release:prepare -DdryRun=true (don't know, if the dryRun-parameter makes any difference). See the stack trace below. My POM does make use of the wagon-ssh-extension, but without declaring a certain version of that extension - which is not necessary, as far as I know. A workaround to this is to declare a version to the extension. See this mail thread for a discussion on this issue: http://www.nabble.com/NullPointerException+in+Release+Plugin+2.0-beta-4-t1637385.html#a4434481 Stefan ava.lang.NullPointerException at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:388) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.rewriteExtensions(AbstractRewritePomsPhase.java:352) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:230) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:165) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:102) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:529) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:135) -- 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-48) eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin
[ http://jira.codehaus.org/browse/MECLIPSE-48?page=all ] fabrizio giustina closed MECLIPSE-48. - Assignee: fabrizio giustina Resolution: Fixed Fix Version/s: 2.3 handling of exclude/include pattern added for 2.3 eclipse:eclipse goal should handle includes and excludes of the maven-compiler-plugin - Key: MECLIPSE-48 URL: http://jira.codehaus.org/browse/MECLIPSE-48 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.0 Reporter: Mark Donszelmann Assigned To: fabrizio giustina Fix For: 2.3 The maven-compiler-plugin allows a configuration such as: plugin artifactIdmaven-compiler-plugin/artifactId configuration excludes exclude**/idl/*Factory.java/exclude /excludes /configuration /plugin the generated .classpath file currently does not mention the excluded part: classpathentry kind=src path=src/main/java/ classpathentry kind=src path=target/generated-sources/idl/ which should be: classpathentry excluding=**/idl/*Factory.java kind=src path=src/main/java/ classpathentry excluding=**/idl/*Factory.java kind=src path=target/generated-sources/idl/ -- 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-122) Versionless Extension causes NullPointerException in release:prepare
[ http://jira.codehaus.org/browse/MRELEASE-122?page=comments#action_78383 ] Vinod Panicker commented on MRELEASE-122: - Sorry abt the previous comment. I'm getting an NPE at a different location, not at the extensions. Versionless Extension causes NullPointerException in release:prepare Key: MRELEASE-122 URL: http://jira.codehaus.org/browse/MRELEASE-122 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Stefan Hübner Attachments: patch.txt I'm getting a NullPointerException when invoking mvn release:prepare -DdryRun=true (don't know, if the dryRun-parameter makes any difference). See the stack trace below. My POM does make use of the wagon-ssh-extension, but without declaring a certain version of that extension - which is not necessary, as far as I know. A workaround to this is to declare a version to the extension. See this mail thread for a discussion on this issue: http://www.nabble.com/NullPointerException+in+Release+Plugin+2.0-beta-4-t1637385.html#a4434481 Stefan ava.lang.NullPointerException at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.updateDomVersion(AbstractRewritePomsPhase.java:388) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.rewriteExtensions(AbstractRewritePomsPhase.java:352) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:230) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:165) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:102) at org.apache.maven.plugins.release.phase.AbstractRewritePomsPhase.simulate(AbstractRewritePomsPhase.java:529) at org.apache.maven.plugins.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:135) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-137) Developed RAD-6 Plugin Extention
[ http://jira.codehaus.org/browse/MECLIPSE-137?page=comments#action_78384 ] Lee Jonas commented on MECLIPSE-137: Unfortunately, I can't seem to get the WebService creation wizard in RAD 6.0.1.1 (Interim fix 002) working with the webSourceDirectory set to src/main/webapp :-(. I have attached an alternative version that works with the WebContent dir. (NB: both warSourceDirectory and webXml configuration properties must be set accordingly on the maven-war-plugin also). regards Lee Developed RAD-6 Plugin Extention Key: MECLIPSE-137 URL: http://jira.codehaus.org/browse/MECLIPSE-137 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Reporter: Richard van Nieuwenhoven Attachments: maven-rad-plugin.tar.gz, maven-rad-plugin.zip I just finisched developing a RAD-6 (IBM Rational Application Developer 6.0) extention to the eclipse plugin. It supports J2EE projects with the websphere development envorment, supported are - EJB projects - Web projects - EAR- projects all these projects are recognized by rad-6 as what they. The websphere development enviorment including hot-deployment features funktions out of the box. i wrote writers for: - the .j2ee files - the application.xml and the modulemaps file - copying the extrenal libs in the ear project root - adapting the MANIFEST.MF of the projects (nessesary for the websphere development enviorment) - the .websettings file - the .websiteconfig file - the .project (only alternative project natures/builders) do you want to include it the the eclipse plugin or sould it be an extra plugin? i should not be complicated to include it because i did the real work in writer-classes. should i add a tgz with the sources? or how do you want the sources? -- 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-137) Developed RAD-6 Plugin Extention
[ http://jira.codehaus.org/browse/MECLIPSE-137?page=all ] Lee Jonas updated MECLIPSE-137: --- Attachment: maven-rad-plugin-WebContent.zip Alternative version of this plugin that uses the WebContent directory for web content files. Developed RAD-6 Plugin Extention Key: MECLIPSE-137 URL: http://jira.codehaus.org/browse/MECLIPSE-137 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Reporter: Richard van Nieuwenhoven Attachments: maven-rad-plugin-WebContent.zip, maven-rad-plugin.tar.gz, maven-rad-plugin.zip I just finisched developing a RAD-6 (IBM Rational Application Developer 6.0) extention to the eclipse plugin. It supports J2EE projects with the websphere development envorment, supported are - EJB projects - Web projects - EAR- projects all these projects are recognized by rad-6 as what they. The websphere development enviorment including hot-deployment features funktions out of the box. i wrote writers for: - the .j2ee files - the application.xml and the modulemaps file - copying the extrenal libs in the ear project root - adapting the MANIFEST.MF of the projects (nessesary for the websphere development enviorment) - the .websettings file - the .websiteconfig file - the .project (only alternative project natures/builders) do you want to include it the the eclipse plugin or sould it be an extra plugin? i should not be complicated to include it because i did the real work in writer-classes. should i add a tgz with the sources? or how do you want the sources? -- 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: (WAGONSSH-54) scp with password in settings.xml still asks password
scp with password in settings.xml still asks password - Key: WAGONSSH-54 URL: http://jira.codehaus.org/browse/WAGONSSH-54 Project: wagon-ssh Issue Type: Bug Affects Versions: 1.0-alpha-5 Environment: java version 1.5.0_07 Maven version: 2.0.4 Linux version 2.6.12-12mdk...(... (4.0.1-5mdk for Mandriva Linux release 2006.0)) #1 Fri Sep 9 18:15:22 CEST 2005 Reporter: marco p Priority: Minor Attachments: attach.tgz SCP deploy always asks me a password on the command line, ignoring the password in settings.xml. If I run with -B, no password is asked, but the process fails. If I don't use -B, I am asked for a password (five times for a single deploy operation). It looks as if the password tag in settings.xml were ignored. On the other hand, an ftp deploy reads the password and asks nothing on the command line. Google suggests that other people experienced the same problem: http://mail-archives.apache.org/mod_mbox/maven-users/200607.mbox/[EMAIL PROTECTED] http://www.mail-archive.com/users@maven.apache.org/msg52463.html http://mail-archives.apache.org/mod_mbox/maven-users/200604.mbox/[EMAIL PROTECTED] But I could not find an answer to the problem, or an explanation of why all these people experienced the same difficulty. I guess it is just a matter of some complex configuration that would benefit from a clearer documentation -- 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-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_78396 ] Bugittaa Pahasti commented on MNG-1577: --- One thing I noticed related to this: if I override a version in dependencies (not in dependencyManagement), the pom of the incorrect version is still needed. This might be a problem, if that incorrent version of the pom can't be downloaded. It would be good not to require and download it at all. This same thing would then be nice to have also this pluginmanagement fix. dependencyManagement does not work for transitive dependencies -- Key: MNG-1577 URL: http://jira.codehaus.org/browse/MNG-1577 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0 Reporter: Joerg Schaible Fix For: 2.1 Attachments: mng1577.patch, mng1577a.patch, mng1577b.patch, mng1577c.patch, mng1577d.patch, mng1577trunk.patch The dependencyManagement does not work for transient dependencies. The specified version is ignored. Use case: Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT and B-SNAPSHOT Project A is child of Main and depends directly on commons-beanutils (version inherited from Main) Project B is child of Main and depends directly on commons-digester (version inherited from Main) Project C is child of Main and depends directly on A B (versions inherited from Main) A is compiled and tests are run using commons-beanutils-1.7.0 B is compiled and tests are run using commons-digester-1.6 and commons-beanutils-1.6, since digester is dependend on this C is compiled and tests are run using commons-beanutils-1.7.0 Integration tests of B did not verify, that B is behaving as expected in this scenario. B might fail with 1.7.0 and it is not even recognized. If I add beanutils also as direct dependency to B, it works fine, but then are transitive dependency useless. It should be possible to define at least in the dependencyManagement, that the versions of transient dependencies also defined in the dependencyManagement have priority. - Jörg -- 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-2145) Plugins' dependencies are not always checked
[ http://jira.codehaus.org/browse/MNG-2145?page=comments#action_78397 ] Bugittaa Pahasti commented on MNG-2145: --- Does that reconfiguration issue have a separate report, or should this be renamed? Plugins' dependencies are not always checked Key: MNG-2145 URL: http://jira.codehaus.org/browse/MNG-2145 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.2 Reporter: Daiyam Priority: Blocker Fix For: 2.1 Attachments: pom-echo.xml, pom-merge.xml, pom-profile.xml, pom.xml, test-suite.zip I want to run two ant task, one on the phase 'generate-sources' which contains a dependency and another on the phase 'package'. When I want to compile with the project like that, maven don't check the dependency. But when I comment the plugin on the phase 'package', maven check it. PS: In the pom.xml in attachement, maven must check the library junit:junit:jar:30.80.10 (which don't exsist) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-137) Developed RAD-6 Plugin Extention
[ http://jira.codehaus.org/browse/MECLIPSE-137?page=comments#action_78401 ] John Casey commented on MECLIPSE-137: - Can you please rework this contribution as a patch to the maven-eclipse-plugin? RAD is based on Eclipse, so it would be best to integrate this support with that plugin. Developed RAD-6 Plugin Extention Key: MECLIPSE-137 URL: http://jira.codehaus.org/browse/MECLIPSE-137 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Reporter: Richard van Nieuwenhoven Attachments: maven-rad-plugin-WebContent.zip, maven-rad-plugin.tar.gz, maven-rad-plugin.zip I just finisched developing a RAD-6 (IBM Rational Application Developer 6.0) extention to the eclipse plugin. It supports J2EE projects with the websphere development envorment, supported are - EJB projects - Web projects - EAR- projects all these projects are recognized by rad-6 as what they. The websphere development enviorment including hot-deployment features funktions out of the box. i wrote writers for: - the .j2ee files - the application.xml and the modulemaps file - copying the extrenal libs in the ear project root - adapting the MANIFEST.MF of the projects (nessesary for the websphere development enviorment) - the .websettings file - the .websiteconfig file - the .project (only alternative project natures/builders) do you want to include it the the eclipse plugin or sould it be an extra plugin? i should not be complicated to include it because i did the real work in writer-classes. should i add a tgz with the sources? or how do you want the sources? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-137) Developed RAD-6 Plugin Extention
[ http://jira.codehaus.org/browse/MECLIPSE-137?page=comments#action_78408 ] Richard van Nieuwenhoven commented on MECLIPSE-137: --- Thats getting difficult... and i do not have the time to do this right now.. (it was based on an 4 months old version of eclipse:eclipse ).. But almost all differences are all in additional workers. (by intended design of the eclipse plugin) . Some of these workers i copied for my wtp 1.5 patch that i posted a while ago, i had the some same problems there as i had in RAD6. When you realy need a rework as a patch, i can send you the contact in the company for whom i made the plugin (UNIQA). maybe they have some resources free for rework (when it realy gets integerated in the official version of eclipse:eclipse). . Developed RAD-6 Plugin Extention Key: MECLIPSE-137 URL: http://jira.codehaus.org/browse/MECLIPSE-137 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Reporter: Richard van Nieuwenhoven Attachments: maven-rad-plugin-WebContent.zip, maven-rad-plugin.tar.gz, maven-rad-plugin.zip I just finisched developing a RAD-6 (IBM Rational Application Developer 6.0) extention to the eclipse plugin. It supports J2EE projects with the websphere development envorment, supported are - EJB projects - Web projects - EAR- projects all these projects are recognized by rad-6 as what they. The websphere development enviorment including hot-deployment features funktions out of the box. i wrote writers for: - the .j2ee files - the application.xml and the modulemaps file - copying the extrenal libs in the ear project root - adapting the MANIFEST.MF of the projects (nessesary for the websphere development enviorment) - the .websettings file - the .websiteconfig file - the .project (only alternative project natures/builders) do you want to include it the the eclipse plugin or sould it be an extra plugin? i should not be complicated to include it because i did the real work in writer-classes. should i add a tgz with the sources? or how do you want the sources? -- 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-114) ${project.artifactId} was replaced with it's value during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-114?page=comments#action_78409 ]
Jurgen Lust commented on MRELEASE-114:
--
I checked out the 2.0-beta-4 tag of the maven-release-plugin and applied the
patch supplied here, but the problem remains: ${user.name} and ${artifactId}
are being replaced in the scm section and committed to svn...
${project.artifactId} was replaced with it's value during release:perform
-
Key: MRELEASE-114
URL: http://jira.codehaus.org/browse/MRELEASE-114
Project: Maven 2.x Release Plugin
Issue Type: Bug
Environment: Windows XP, Java 1.4.2
Reporter: Paul Spencer
Attachments: MRELEASE-128-maven-release-plugin.patch
In release:perform, the variable ${project.artifactId} was replaced with it's
value in the connection and developerConnection tags in the pom. This did NOT
happen in other place in the pom!
Before release:
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/bar:${project.artifactId}/connection
After release:
connectionscm:cvs:pserver:[EMAIL PROTECTED]:/bar:master-pom/connection
BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
related to the above 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: (MRELEASE-114) ${project.artifactId} was replaced with it's value during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-114?page=comments#action_78411 ]
Eric Bernstein commented on MRELEASE-114:
-
Yes, Jurgen, that's where my patch falls short (see point 1 on my notes above).
I knew SVN needed some form of rewrite (for tagging, etc...) and CVS (and
others) did not. Not being very familiar with SVN, I kept the SVN
functionality the same and exempted the other SCMs so that I would, at worst,
do no harm.
If you have a better understanding of SVN, I imagine the patch could be
improved by manipulating the URLs as they should be using the base URLs rather
than the evaluated URLs as I believe they are today.
${project.artifactId} was replaced with it's value during release:perform
-
Key: MRELEASE-114
URL: http://jira.codehaus.org/browse/MRELEASE-114
Project: Maven 2.x Release Plugin
Issue Type: Bug
Environment: Windows XP, Java 1.4.2
Reporter: Paul Spencer
Attachments: MRELEASE-128-maven-release-plugin.patch
In release:perform, the variable ${project.artifactId} was replaced with it's
value in the connection and developerConnection tags in the pom. This did NOT
happen in other place in the pom!
Before release:
connectionscm:cvs:pserver:[EMAIL
PROTECTED]:/bar:${project.artifactId}/connection
After release:
connectionscm:cvs:pserver:[EMAIL PROTECTED]:/bar:master-pom/connection
BTW: The issue http://jira.codehaus.org/browse/MRELEASE-16 may be
related to the above 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] Created: (MAVENUPLOAD-1201) Please upload Connector/J 3.1.14
Please upload Connector/J 3.1.14 Key: MAVENUPLOAD-1201 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1201 Project: maven-upload-requests Issue Type: Task Reporter: Mark Matthews The latest 3.1 version of the JDBC driver for MySQL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1201) Please upload Connector/J 3.1.14
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1201?page=all ] Carlos Sanchez closed MAVENUPLOAD-1201. --- Assignee: Carlos Sanchez Resolution: Fixed You'd probably want to automate these uploads, take a look at Sync'ing your own repository with ibiblio http://maven.apache.org/guides/mini/guide-ibiblio-upload.html Please upload Connector/J 3.1.14 Key: MAVENUPLOAD-1201 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1201 Project: maven-upload-requests Issue Type: Task Reporter: Mark Matthews Assigned To: Carlos Sanchez The latest 3.1 version of the JDBC driver for MySQL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1199) DTDDoc 1.0.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1199?page=all ] Carlos Sanchez closed MAVENUPLOAD-1199. --- Assignee: Carlos Sanchez Resolution: Fixed DTDDoc 1.0.0 Key: MAVENUPLOAD-1199 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1199 Project: maven-upload-requests Issue Type: Task Reporter: Hervé BOUTEMY Assigned To: Carlos Sanchez DTDDoc is a DTD documentation tool a la javadoc -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1198) hibernate-3.2.0.ga sources
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1198?page=all ] Carlos Sanchez closed MAVENUPLOAD-1198. --- Assignee: Carlos Sanchez Resolution: Fixed Next time please provide a bundle with the jar and pom that are already in the repo, but saying that it's only for the sources hibernate-3.2.0.ga sources -- Key: MAVENUPLOAD-1198 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1198 Project: maven-upload-requests Issue Type: Task Reporter: Cameron Ross Assigned To: Carlos Sanchez Attachments: hibernate-3.2.0.ga-sources.jar Here are the hibernate-3.2.0.ga sources -- 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-1191) Upload AjaxAnywhere 1.2-rc2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1191?page=comments#action_78423 ] Carlos Sanchez commented on MAVENUPLOAD-1191: - Then provide some proof (like WHOIS record) that he's the owner and where he's listed as a developer in the project. In whois.net doesn't show up Upload AjaxAnywhere 1.2-rc2 --- Key: MAVENUPLOAD-1191 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1191 Project: maven-upload-requests Issue Type: Wish Reporter: Matt Raible -- 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-1201) Please upload Connector/J 3.1.14
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1201?page=comments#action_78424 ] Mark Matthews commented on MAVENUPLOAD-1201: Carlos, That would be great, but the link to the example script for syncing is busted. Please upload Connector/J 3.1.14 Key: MAVENUPLOAD-1201 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1201 Project: maven-upload-requests Issue Type: Task Reporter: Mark Matthews Assigned To: Carlos Sanchez The latest 3.1 version of the JDBC driver for MySQL. -- 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-1201) Please upload Connector/J 3.1.14
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1201?page=comments#action_78425 ] Carlos Sanchez commented on MAVENUPLOAD-1201: - Thanks for pointing out. it's http://svn.apache.org/viewvc/maven/archiva/trunk/maven-meeper/src/bin/synchronize/m2-sync/conf/ Please upload Connector/J 3.1.14 Key: MAVENUPLOAD-1201 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1201 Project: maven-upload-requests Issue Type: Task Reporter: Mark Matthews Assigned To: Carlos Sanchez The latest 3.1 version of the JDBC driver for MySQL. -- 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-1202) Upload log4j 1.2.14 to central
Upload log4j 1.2.14 to central -- Key: MAVENUPLOAD-1202 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1202 Project: maven-upload-requests Issue Type: Improvement Reporter: David J. M. Karlsen Upload log4j 1.2.14 to central -- 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: (MJAR-28) Using the jar plugin with addClasspath and snapshots can create manifest classpath with incorrect jar versions
[ http://jira.codehaus.org/browse/MJAR-28?page=comments#action_78430 ]
Martin Desruisseaux commented on MJAR-28:
-
Maybe related to this issue: the manifest classpath generated by Maven ignores
the real JAR name as specified in {{finalName}}. For example the Geotools
project tried the following configuration:
{code:xml}
build
finalNamegt-${artifactId}-${version}/finalName
{code}
but the manifest classpath generated by Maven contains only
{{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
*Note:* this problem happen only when the JAR dependencis come from the
repository. The manifest classpath is correct if all dependencies were compiled
in the same {{mvn install}} cycle.
Using the jar plugin with addClasspath and snapshots can create manifest
classpath with incorrect jar versions
--
Key: MJAR-28
URL: http://jira.codehaus.org/browse/MJAR-28
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.0
Reporter: Mark J. Titorenko
Attachments: MJAR-28-patch.txt
When the POM contains dependencies to snapshot versions of jars, and snapshot
versions of those jars are downloaded from a remote repository, the name of
the jar contained in the classpath added to the manifest, of the form
artifactID-X.X-SNAPSHOT.jar, does not match the actual name of the jar
downloaded, which contains version information of the form
artifactID-X.X-MMDD.HHmmss-V.jar.
This does not affect snapshot versions which have been directly installed
into a local repository and have no uploaded version within the remote
repository, as these jars are named using the artifactID-X.X-SNAPSHOT.jar
form.
--
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: (MJAR-61) Manifest classpath ignores the real JAR filenames specified in finalName
Manifest classpath ignores the real JAR filenames specified in finalName
Key: MJAR-61
URL: http://jira.codehaus.org/browse/MJAR-61
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.1
Reporter: Martin Desruisseaux
The manifest classpath generated by Maven ignores the real JAR name as
specified in {{finalName}}. For example the Geotools project tried the
following configuration:
{code:xml}
build
finalNamegt-${artifactId}-${version}/finalName
{code}
but the manifest classpath generated by Maven contains only
{{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
*Note:* this problem happen only when the JAR dependencis come from the
repository. The manifest classpath is correct if all dependencies were compiled
in the same {{mvn install}} cycle. However this workaround is applicable only
to Geotools developpers (in our case), because users of the Geotools library
usually download the dependencies from a repository.
This bug may be related to MJAR-28.
--
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: (CONTINUUM-970) Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared
[ http://jira.codehaus.org/browse/CONTINUUM-970?page=all ] Jesse McConnell closed CONTINUUM-970. - Resolution: Fixed Fix Version/s: 1.1 patch applied, anyone building this might need to build the release manager in maven-shared until the apache snapshot repo comes back on line thanks edwin Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared --- Key: CONTINUUM-970 URL: http://jira.codehaus.org/browse/CONTINUUM-970 Project: Continuum Issue Type: Improvement Reporter: Edwin Punzalan Assigned To: Edwin Punzalan Fix For: 1.1 Attachments: CONTINUUM-970.patch -- 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: (MPMD-46) Add ability to choose priority for failure
[ http://jira.codehaus.org/browse/MPMD-46?page=comments#action_78433 ] Anthony Whitford commented on MPMD-46: -- I think this is more of an _Improvement_ rather than a _New Feature_ because it would be an extension to the existing [pmd:check|http://maven.apache.org/plugins/maven-pmd-plugin/check-mojo.html] goal. Add ability to choose priority for failure -- Key: MPMD-46 URL: http://jira.codehaus.org/browse/MPMD-46 Project: Maven 2.x Pmd Plugin Issue Type: New Feature Affects Versions: 2.1 Reporter: Brian Fox Assigned To: Brian Fox Need to add the ability to run the rules but only fail above a certain priority level. -- 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: (MPMD-17) Add report summary
[ http://jira.codehaus.org/browse/MPMD-17?page=comments#action_78437 ] Anthony Whitford commented on MPMD-17: -- Could a summary page be generated based on the XML result file? I was thinking that XSL could be used to take the same XML input, but create various reports: * summary report * violations by package, class, line * violations by priority, package, class, line A report organized by _priority_ is really valuable to me because while I love PMD's thoroughness, we sometimes need to focus on addressing issues in priority order. Add report summary -- Key: MPMD-17 URL: http://jira.codehaus.org/browse/MPMD-17 Project: Maven 2.x Pmd Plugin Issue Type: Improvement Reporter: Nick Giles Priority: Minor Add a summary of the PMD report to the top of the report page, in the same manner as Checkstyle. This should include information such as the total number of violations, number of violations by priority, and optionally number of violations by file and rule -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-150) Clarify or fix file relative scoping in assembly descriptor to be module centric or location of mvn execution
Clarify or fix file relative scoping in assembly descriptor to be module centric or location of mvn execution --- Key: MASSEMBLY-150 URL: http://jira.codehaus.org/browse/MASSEMBLY-150 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.1 Environment: windows xp Reporter: Harold Shinsato According to http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html, the assembly descriptor's file source is supposed to be absolute or relative from the module's directory. This works when I execute mvn in the module directory. But when I run it from a top level super project, it seems to run from that higher level project. This isn't how the fileSet works, which we were using before, but we needed to set filtering to true, which caused this to break. So this is how we have to write this to make this work from the top level, but it breaks when running the assembly from this directory. files file sourcefileutil/src/main/scripts/FileUploadUtility.bat/source outputDirectoryfile-utility/outputDirectory filteredtrue/filtered /file /files This is how it used to be specified, where it worked both from the top level and from the subdirectory: fileSets fileSet directory../fileutil/directory outputDirectoryfile-utility/outputDirectory includes includeFileUploadUtility.bat/include /includes /fileSet /fileSets Hopefully this won't make a difference, but we've plugged our assembly into the execution of the package phase. This is copied from the pom.xml of the module. build plugins plugin artifactIdmaven-assembly-plugin/artifactId configuration descriptors descriptorsrc/main/assembly/dist.xml/descriptor /descriptors /configuration executions execution goals goalattached/goal /goals phasepackage/phase /execution /executions /plugin /plugins /build -- 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-2630) This is a question on how to extract the groupid,artifactid and other values of the artifact from its pom using a java code
This is a question on how to extract the groupid,artifactid and other values of the artifact from its pom using a java code --- Key: MNG-2630 URL: http://jira.codehaus.org/browse/MNG-2630 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.4 Environment: We use Maven in sun solaris environment Reporter: sharda sheshabhattar Using a java program I want to extract the details of an artifact from a pom.How can I do that? Please help.Also point me to some docs and examples on doing this Thanks, Sharda -- 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-1203) maven-oaw-plugin-1.0.1-bundle.jar
maven-oaw-plugin-1.0.1-bundle.jar - Key: MAVENUPLOAD-1203 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1203 Project: maven-upload-requests Issue Type: Task Reporter: Dominik Winter The maven-oaw-plugin helps the developer to integrate the openArchitectureWare workflow in a Maven based build. It runs the workflow and puts the generated artifact to the maven source file list, so it can be compiled later. This release includes debug support for the workflow runner. Running Maven in debug mode runs the workflow runner in debug mode, too. More information about openArchitectureWare can be found on their site http://www.openarchitectureware.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78447 ] Ryan Daum commented on SCM-230: --- I have made all the unit tests pass, except one (HgCheckoutCommandTest), which has some heisenbug which causes it to fail inconsistently. Running it in the debugger and putting breakpoints in... causes it to pass. mvn test succeeds about 50% of the time. mercurial plugin Key: SCM-230 URL: http://jira.codehaus.org/browse/SCM-230 Project: Maven SCM Issue Type: New Feature Reporter: solo turn Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tgz it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation. mercurial is (currently) much faster than bzr and therefor really useable. -- 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-1204) JSON Tools 1.4 - Core
JSON Tools 1.4 - Core - Key: MAVENUPLOAD-1204 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1204 Project: maven-upload-requests Issue Type: Task Reporter: Bruno Ranschaert JSON Tools is a Java library to manipulate JSON text. The core library contains the core functionality: parser/renderer/serializer/mapper/validator. Note: * The package name (com.sdicons) was registered by me. The URL http://jsontools.sdicons.com is redirected to the berlios project page. -- 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: (MRESOURCES-35) targetPath doesn't accept absolute paths
targetPath doesn't accept absolute paths
Key: MRESOURCES-35
URL: http://jira.codehaus.org/browse/MRESOURCES-35
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: linux, windows
Reporter: Paul Jungwirth
Priority: Minor
targetPath is always relative to target/classes, even if you pass it an
absolute path. This happens if the path is from a variable, like this:
targetPath${basedir}/scripts/targetPath
It also happens if you write the path directly:
targetPath/home/pjungwir/src/encc/scripts/targetPath
or on windows:
targetPathC:/home/pjungwir/src/encc/scripts/targetPath
Your resources wind up in directories like this:
/home/pjungwir/src/encc/target/classes/home/pjungwir/src/encc/scripts
--
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: (MRESOURCES-35) targetPath doesn't accept absolute paths
[ http://jira.codehaus.org/browse/MRESOURCES-35?page=all ]
Paul Jungwirth updated MRESOURCES-35:
-
Attachment: absolute-resource-outputs.patch
Here is a patch to fix the problem. It is against trunk.
targetPath doesn't accept absolute paths
Key: MRESOURCES-35
URL: http://jira.codehaus.org/browse/MRESOURCES-35
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Environment: linux, windows
Reporter: Paul Jungwirth
Priority: Minor
Attachments: absolute-resource-outputs.patch
targetPath is always relative to target/classes, even if you pass it an
absolute path. This happens if the path is from a variable, like this:
targetPath${basedir}/scripts/targetPath
It also happens if you write the path directly:
targetPath/home/pjungwir/src/encc/scripts/targetPath
or on windows:
targetPathC:/home/pjungwir/src/encc/scripts/targetPath
Your resources wind up in directories like this:
/home/pjungwir/src/encc/target/classes/home/pjungwir/src/encc/scripts
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78456 ] Ryan Daum commented on SCM-230: --- Found the source of the problem. It is in HgChangeLogCommandTckTest, and is actually a problem in the last test in the base ChangeLogCommandTckTest. Basically it checks in two revisions then tries, using date/time filtering to retrieve only the later one. This may work fine for slow network based revision control systems, but for Mercurial, the creation of the file and its checkin happens within the same second, so the log reports the same time for creation of both revisions, and nothing fits within the date filter range. In some cases, if the checkin happens of the second file happens to occur after the second value of the date increments, the test passes. I am unable to fix this, it is IMHO a defect in the base ChangeLogCommandTckTest. mercurial plugin Key: SCM-230 URL: http://jira.codehaus.org/browse/SCM-230 Project: Maven SCM Issue Type: New Feature Reporter: solo turn Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tgz it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation. mercurial is (currently) much faster than bzr and therefor really useable. -- 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-244) In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and fails for some SCM systems
In maven-scm-test, ChangeLogCommandTckTest relies on unreliable timing and fails for some SCM systems - Key: SCM-244 URL: http://jira.codehaus.org/browse/SCM-244 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Environment: Linux 2.6, JDK 1.5, Maven 2 Reporter: Ryan Daum I encountered this problem while fixing a new Mercurial SCM provider so that all its unit tests pass. A Mercurial repository which can reproduce the bug can be found at http://darksleep.com/~ryan/maven-scm-provider-hg.cgi -- use the mercurial client to clone this repository. The problem manifests itself in HgChangeLogCommandTckTest. ChangeLogCommandTckTestchecks in two revisions in sequence, and records the time between them. It then tries, using date/time filtering to retrieve only the later one. This may work fine for slower network based revision control systems where there is an appreciable pause between checkins, but for Mercurial, the creation of the file and its checkin often happens within the same second and so the log reports the same time for creation of both revisions. Therefore during the date-time range query, nothing fits _between_ the date filter range. In _some_ cases, if the checkin happens of the second file happens to occur after the second value of the date increments, the test passes, but this is the exception to the rule. The fix would be to modify ChangeLogCommandTckTest to perform a sleep of at least 1 second between checkins. To reproduce, checkout (as mentioned above) the Mercurial SCM provider and run the unit tests. You will see HgChangeLogCommandTckTest fail in the manner described above. -- 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-1178) Upload Ajax4JSF 1.0.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1178?page=comments#action_78460 ] Matt Raible commented on MAVENUPLOAD-1178: -- Should be fixed now in the bundle. Upload Ajax4JSF 1.0.2 - Key: MAVENUPLOAD-1178 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1178 Project: maven-upload-requests Issue Type: Wish Reporter: Matt Raible Please upload this kick-ass Ajax library for JSF applications. ;-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78461 ] Alain Hoang commented on SCM-230: - If you want the test to pass now. It might be possible to override ChangeLongCommandTckTest to perform the behavior that you want with a huge caveat and link to the issues at hand. This should work as a workaround until upstream decides what they want to do with this test. While working on the Mercurial plugin I found a couple of other crappy assumptions in the TckTest Suite which caused me some aggravation. mercurial plugin Key: SCM-230 URL: http://jira.codehaus.org/browse/SCM-230 Project: Maven SCM Issue Type: New Feature Reporter: solo turn Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tgz it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation. mercurial is (currently) much faster than bzr and therefor really useable. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-230) mercurial plugin
[ http://jira.codehaus.org/browse/SCM-230?page=comments#action_78462 ] Ryan Daum commented on SCM-230: --- I will give SCM-244 a few days to gel, and see if anybody looks like they'll move on it. If not, I may do as you say. I am new to the Maven community, and do not know how I would go about getting the Mercurial plugin included in the Maven 2 distribution, and also if it's permissible to just get SVN access and fix the ChangeLongCommandTckTest base class myself. Any ideas? The company I work for is making use of Mercurial, as well as Maven, and I want to be able to use Continuum and other features of Maven that rely on SCM support. mercurial plugin Key: SCM-230 URL: http://jira.codehaus.org/browse/SCM-230 Project: Maven SCM Issue Type: New Feature Reporter: solo turn Attachments: maven-scm-hg.tar.gz, maven-scm-provider-hg-0.09.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg-0.8.tbz, maven-scm-provider-hg.diff.gz, maven-scm-provider-hg.tgz it would be nice to have a mercurial source provider. and if not, it would be nice to update the documentation on http://maven.apache.org/scm/ so that anybody could just copy the bzr provider and make a mercurial provider out of it. it should be nearly the same implementation. mercurial is (currently) much faster than bzr and therefor really useable. -- 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-2558) Expanded POM and Settings files documentation
[ http://jira.codehaus.org/browse/MNG-2558?page=all ] Jason van Zyl closed MNG-2558. -- Resolution: Fixed Patch applied. Expanded POM and Settings files documentation - Key: MNG-2558 URL: http://jira.codehaus.org/browse/MNG-2558 Project: Maven 2 Issue Type: New Feature Components: Documentation: General Affects Versions: 2.0.5 Reporter: Eric Redmond Assigned To: Jason van Zyl Priority: Minor Attachments: pom_settings_docs.patch I've created a couple of docs expanding on the POM and settings.xml reference/user guides, viewable here: http://www.propellors.net/maven/site/pom.html http://www.propellors.net/maven/site/settings.html -- 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-2616) Guide to Being a Good Maven Citizen
[ http://jira.codehaus.org/browse/MNG-2616?page=all ] Jason van Zyl closed MNG-2616. -- Resolution: Fixed Patch applied. Guide to Being a Good Maven Citizen --- Key: MNG-2616 URL: http://jira.codehaus.org/browse/MNG-2616 Project: Maven 2 Issue Type: New Feature Components: Documentation: Introductions Reporter: Eric Redmond Assigned To: Jason van Zyl Priority: Trivial Attachments: community.patch Beginning a guide with information on being a good member of the Maven community. This was created out of a need to tell people not to do things like wget the entire central repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2615) 5 minute guide
[ http://jira.codehaus.org/browse/MNG-2615?page=all ] Jason van Zyl closed MNG-2615. -- Resolution: Fixed Patch applied. 5 minute guide -- Key: MNG-2615 URL: http://jira.codehaus.org/browse/MNG-2615 Project: Maven 2 Issue Type: New Feature Components: Documentation: Guides Reporter: Eric Redmond Assigned To: Jason van Zyl Priority: Trivial Attachments: quickstart.patch Although I like the quickstart guide, Maven needs the quintessential 5 minute guide. This may be expanded to a slightly more comprehensive 10 minutes guide. -- 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-2614) Updated site feel with custom VM
[ http://jira.codehaus.org/browse/MNG-2614?page=all ] Jason van Zyl closed MNG-2614. -- Resolution: Fixed Patch applied. Updated site feel with custom VM Key: MNG-2614 URL: http://jira.codehaus.org/browse/MNG-2614 Project: Maven 2 Issue Type: Bug Components: Documentation: General Reporter: Eric Redmond Assigned To: Jason van Zyl Attachments: custom_vm.patch Replaced the absolute px positioning with more fluid ems. Added LHS menu collapsability with a custom vm. -- 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-1540) ability to categorise guides in the maven site
[ http://jira.codehaus.org/browse/MNG-1540?page=all ] Jason van Zyl closed MNG-1540. -- Resolution: Fixed Patch applied. We can automate later. ability to categorise guides in the maven site -- Key: MNG-1540 URL: http://jira.codehaus.org/browse/MNG-1540 Project: Maven 2 Issue Type: Improvement Components: Documentation: Guides Reporter: Brett Porter Assigned To: Jason van Zyl Priority: Critical Fix For: 2.0.5 Attachments: guides_index.patch -- 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-2623) New LHS Menu
[ http://jira.codehaus.org/browse/MNG-2623?page=all ] Eric Redmond updated MNG-2623: -- Attachment: lhs_menu.patch updated LHS New LHS Menu Key: MNG-2623 URL: http://jira.codehaus.org/browse/MNG-2623 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Eric Redmond Priority: Trivial Attachments: lhs_menu.patch, lhs_menu.patch Reformatted the left-hand side menu to help new and existing user navigation. http://www.propellors.net/maven/site/index.html -- 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-2623) New LHS Menu
[ http://jira.codehaus.org/browse/MNG-2623?page=all ] Jason van Zyl closed MNG-2623. -- Resolution: Fixed Patch applied. New LHS Menu Key: MNG-2623 URL: http://jira.codehaus.org/browse/MNG-2623 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Eric Redmond Assigned To: Jason van Zyl Priority: Trivial Attachments: lhs_menu.patch, lhs_menu.patch Reformatted the left-hand side menu to help new and existing user navigation. http://www.propellors.net/maven/site/index.html -- 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] Reopened: (CONTINUUM-970) Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared
[ http://jira.codehaus.org/browse/CONTINUUM-970?page=all ] Edwin Punzalan reopened CONTINUUM-970: -- Thanks, jesse. But I think you forgot to commit my revision in the parent pom's depMngt. Remove release-plugin dependency from continuum-release and instead use maven-release-manager from maven-shared --- Key: CONTINUUM-970 URL: http://jira.codehaus.org/browse/CONTINUUM-970 Project: Continuum Issue Type: Improvement Reporter: Edwin Punzalan Assigned To: Edwin Punzalan Fix For: 1.1 Attachments: CONTINUUM-970.patch -- 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-2538) Improve plugin documentation on http://maven.apache.org/plugins/index.html.
[ http://jira.codehaus.org/browse/MNG-2538?page=all ] Eric Redmond updated MNG-2538: -- Attachment: catagorized_plugins_index.patch Added catagorized_plugins_index.patch. Improved from previous patch. Improve plugin documentation on http://maven.apache.org/plugins/index.html. --- Key: MNG-2538 URL: http://jira.codehaus.org/browse/MNG-2538 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Davy Toch Priority: Minor Attachments: catagorized_plugins_index.patch, plugin_index.patch On http://maven.apache.org/plugins/index.html, the following text is available: To see the most up-to-date list of available plugins, browse the Maven 2 plugin repository at http://www.ibiblio.org/maven2/.; However in this folder you have: 1. maven-plugins : apparently contains only M1 plugins 2. plugins : contains base M2 plugins and one codehaus plugin 3. plugin : empty, so can be deleted 4. maven-torque-plugin : only metadata files, so can be deleted 5. maven-xdoclet2-plugin : empty, so can be deleted To avoid confusion for novice M2 users, I think it's best to: a. delete the unnecessary folders (3, 4, 5) b. document in the website that http://www.ibiblio.org/maven2/plugins; should be verified for the latest versions of M2 plugins instead of http://www.ibiblio.org/maven2;. c. add a remark to state that http://www.ibiblio.org/maven2/maven-plugins; is only for M1 and should be ignored for M2. -- 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-2538) Improve plugin documentation on http://maven.apache.org/plugins/index.html.
[ http://jira.codehaus.org/browse/MNG-2538?page=all ] Jason van Zyl closed MNG-2538. -- Resolution: Fixed Patch applied. Improve plugin documentation on http://maven.apache.org/plugins/index.html. --- Key: MNG-2538 URL: http://jira.codehaus.org/browse/MNG-2538 Project: Maven 2 Issue Type: Improvement Components: Documentation: General Reporter: Davy Toch Assigned To: Jason van Zyl Priority: Minor Attachments: catagorized_plugins_index.patch, plugin_index.patch On http://maven.apache.org/plugins/index.html, the following text is available: To see the most up-to-date list of available plugins, browse the Maven 2 plugin repository at http://www.ibiblio.org/maven2/.; However in this folder you have: 1. maven-plugins : apparently contains only M1 plugins 2. plugins : contains base M2 plugins and one codehaus plugin 3. plugin : empty, so can be deleted 4. maven-torque-plugin : only metadata files, so can be deleted 5. maven-xdoclet2-plugin : empty, so can be deleted To avoid confusion for novice M2 users, I think it's best to: a. delete the unnecessary folders (3, 4, 5) b. document in the website that http://www.ibiblio.org/maven2/plugins; should be verified for the latest versions of M2 plugins instead of http://www.ibiblio.org/maven2;. c. add a remark to state that http://www.ibiblio.org/maven2/maven-plugins; is only for M1 and should be ignored for M2. -- 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-2468) Categorize the plugin links
[ http://jira.codehaus.org/browse/MNG-2468?page=all ] Jason van Zyl closed MNG-2468. -- Resolution: Duplicate Already done by Eric Redmond. Categorize the plugin links --- Key: MNG-2468 URL: http://jira.codehaus.org/browse/MNG-2468 Project: Maven 2 Issue Type: Improvement Reporter: Marvin King Assigned To: Marvin King Attachments: index.html, MNG-2468-site.patch Categories -j2ee -ide -artifact handling -test -packaging -CI -archetypes -source generators -reports -- 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-1213) more info on the plugin summary
[ http://jira.codehaus.org/browse/MNG-1213?page=all ] Jason van Zyl closed MNG-1213. -- Resolution: Duplicate Superceded by Eric Redmond's work. more info on the plugin summary --- Key: MNG-1213 URL: http://jira.codehaus.org/browse/MNG-1213 Project: Maven 2 Issue Type: Task Components: Documentation: General Reporter: Brett Porter Assigned To: Marvin King Fix For: 2.0.5 include: - mojo.codehaus.org released plugins links - versions/quality of release m2 plugins -- 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: (CONTINUUM-971) Symbolic links are traversed on deletion
Symbolic links are traversed on deletion Key: CONTINUUM-971 URL: http://jira.codehaus.org/browse/CONTINUUM-971 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Environment: Reproduced on Redhat Enterprise 4 but applicable to all forms of UNIX Reporter: Uri Moszkowicz Priority: Critical To reproduce: 1. Create a project that checks out files from some SCM 2. Create a build script that creates symbolic links outside of the checked out project sandbox. This is often done to bring outside libraries into the project. 3. Delete the created project from the Continuum website. Notice how all kinds of files disappear from your file system! From looking at the release logs it looks like someone added follow symbolic links as the default and mentioned that at some point in the future an option should be added to disable this behavior. Following symbolic links is very dangerous and if supported it should be disabled by default, not the reverse. A warning should be posted in a visible place for the existing versions until this can be fixed as it can result in significant data loss outside of the Continuum program. -- 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
