[jira] Created: (WAGON-56) WebDAV Wagon putDirectory fails when multiple directories in path don't exist
WebDAV Wagon putDirectory fails when multiple directories in path don't exist - Key: WAGON-56 URL: http://jira.codehaus.org/browse/WAGON-56 Project: wagon Type: Bug Components: wagon-webdav Versions: 1.0-beta-2, 1.0-beta-1 Reporter: Nathan Beyer (Cerner) Priority: Blocker Attachments: webdavwagon_putdirectory.diff The implementation of the 'putDirectory' method isn't properly checking that all directories (WebDAV collections) have been created. I've attached a patch that reworks the 'putDirectory' such that it relies on the 'put' method for each upload. This will guarantee that all file uploads are treated the same way and resolves this issue, as the 'put' method implements the appropriate directory checks. -- 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: (WAGON-56) WebDAV Wagon putDirectory fails when multiple directories in path don't exist
[ http://jira.codehaus.org/browse/WAGON-56?page=all ] Nathan Beyer (Cerner) updated WAGON-56: --- Attachment: wagontestcase_deepdest.diff > WebDAV Wagon putDirectory fails when multiple directories in path don't exist > - > > Key: WAGON-56 > URL: http://jira.codehaus.org/browse/WAGON-56 > Project: wagon > Type: Bug > Components: wagon-webdav > Versions: 1.0-beta-2, 1.0-beta-1 > Reporter: Nathan Beyer (Cerner) > Priority: Blocker > Attachments: wagontestcase_deepdest.diff, webdavwagon_putdirectory.diff > > > The implementation of the 'putDirectory' method isn't properly checking that > all directories (WebDAV collections) have been created. I've attached a patch > that reworks the 'putDirectory' such that it relies on the 'put' method for > each upload. This will guarantee that all file uploads are treated the same > way and resolves this issue, as the 'put' method implements the appropriate > directory checks. -- 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_72040 ] Nathan Beyer (Cerner) commented on MNG-1577: +1 for Craig's suggestion. The deterministic and user-controlled resolution of dependencies is a must in developing and testing any complex system, especially those that depend on projects that may be out of a user's control, such as open-source projects. > 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 > > > 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: (SUREFIRE-318) Fails to run build on Windows Server 2003
[ http://jira.codehaus.org/browse/SUREFIRE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104765 ] Nathan Beyer (Cerner) commented on SUREFIRE-318: I'm noticing some seemingly significant issues between running Maven on Windows 2003 and other Windows versions (XP and Vista). I'm seeing a difference in the ordering of the classpath for compilation and test runs. Here's some log comparisons between a run of the exact same build using Maven 2.0.7, Sun JDK 1.5.0u12 on Windows Vista x86 and then again using Maven 2.0.7, Sun JDK 1.5.0u12 on Windows 2003. Compilation Differences -- --- Windows Vista +++ Windows 2003 @@ -756,21 +756,21 @@ c:\temp\m2\repo\com\cerner\system\instrument\system-instrument\2.0\system-instrument-2.0.jar c:\temp\m2\repo\com\cerner\system\system-i18n\2.0\system-i18n-2.0.jar + c:\temp\m2\repo\com\cerner\system\system-core\2.0\system-core-2.0.jar c:\temp\m2\repo\com\cerner\system\system-jdbc\1.1.3\system-jdbc-1.1.3.jar c:\temp\m2\repo\cerner\system-cache-jetstream\1.3.2\system-cache-jetstream-1.3.2.jar - c:\temp\m2\repo\com\cerner\system\system-core\2.0\system-core-2.0.jar + c:\temp\m2\repo\cerner\dataobject-core\1.1.4\dataobject-core-1.1.4.jar c:\temp\m2\repo\cerner\dataaccess-core\1.1.2\dataaccess-core-1.1.2.jar - c:\temp\m2\repo\cerner\dataobject-core\1.1.4\dataobject-core-1.1.4.jar c:\temp\m2\repo\com\cerner\mmf\mmf-dataaccess-jdbc\1.0-RC1\mmf-dataaccess-jdbc-1.0-RC1.jar c:\temp\m2\repo\com\cerner\mmf\xds\mmf-xds-person\1.0-SNAPSHOT\mmf-xds-person-1.0-SNAPSHOT.jar c:\temp\m2\repo\cerner\universal-id\1.3.0\universal-id-1.3.0.jar - c:\temp\m2\repo\com\cerner\system\transaction\system-transaction\1.2\system-transaction-1.2.jar c:\temp\m2\repo\cerner\system-bootstrap\1.1.1\system-bootstrap-1.1.1.jar + c:\temp\m2\repo\com\cerner\system\transaction\system-transaction\1.2\system-transaction-1.2.jar c:\temp\m2\repo\cerner\system-concurrency\1.3\system-concurrency-1.3.jar c:\temp\m2\repo\cerner\system-management\1.1.1\system-management-1.1.1.jar c:\temp\m2\repo\com\cerner\mmf\mmf-factory\1.0-RC1\mmf-factory-1.0-RC1.jar c:\temp\m2\repo\cerner\system-cache\1.7.2\system-cache-1.7.2.jar c:\temp\m2\repo\cerner\system-registry\1.4.1\system-registry-1.4.1.jar c:\temp\m2\repo\cerner\system-event\1.0.3\system-event-1.0.3.jar c:\temp\m2\repo\cerner\system-urn\1.1.1\system-urn-1.1.1.jar] Surefire launch -- --- Windows Vista +++ Windows 2003 @@ -2022 +2022 @@ -Forking command line: C:\Users\Public\jdk\sun\5_12\jre\bin\java -classpath c:\temp\m2\repo\org\codehaus\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar;c:\temp\m2\repo\junit\junit\3.8.1\junit-3.8.1.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-api\2.3\surefire-api-2.3.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-container-default\1.0-alpha-8\plexus-container-default-1.0-alpha-8.jar;c:\temp\m2\repo\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;c:\temp\m2\repo\commons-lang\commons-lang\2.1\commons-lang-2.1.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-booter\2.3\surefire-booter-2.3.jar org.apache.maven.surefire.booter.SurefireBooter C:\Users\xxx\AppData\Local\Temp\surefire7271tmp C:\Users\xxx\AppData\Local\Temp\surefire7272tmp +Forking command line: c:\install\jdk\sun\5_12\jre\bin\java -classpath c:\temp\m2\repo\org\codehaus\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar;c:\temp\m2\repo\junit\junit\3.8.1\junit-3.8.1.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-container-default\1.0-alpha-8\plexus-container-default-1.0-alpha-8.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-api\2.3\surefire-api-2.3.jar;c:\temp\m2\repo\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;c:\temp\m2\repo\commons-lang\commons-lang\2.1\commons-lang-2.1.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-booter\2.3\surefire-booter-2.3.jar org.apache.maven.surefire.booter.SurefireBooter c:\temp\xxx\2\surefire34874tmp c:\temp\xxx\2\surefire34875tmp Notice how the surefire-api JAR is in a different location this time. > Fails to run build on Windows Server 2003 > - > > Key: SUREFIRE-318 > URL: http://jira.codehaus.org/browse/SUREFIRE-318 > Project: Maven Surefire > Issue Type: Bug >Affects Versions: 2.3 > Environment: Maven 2.0.5 or 2.0.6 , Windows Server 2003, Java 1.5 or > 1.6 >Reporter: Vlad Skarzhevskyy >Assignee: Brett Porter > Fix For: 2.3.1 > > Attachments: build-log.txt > > > After Upgrade to Surefire 2.3 our build server fails to run tests on any > project. > Get the message: > [ERROR] BUILD FAILURE > [INFO] > -
[jira] Issue Comment Edited: (SUREFIRE-318) Fails to run build on Windows Server 2003
[ http://jira.codehaus.org/browse/SUREFIRE-318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104765 ] Nathan Beyer (Cerner) edited comment on SUREFIRE-318 at 8/13/07 4:02 PM: - I'm noticing some seemingly significant issues between running Maven on Windows 2003 and other Windows versions (XP and Vista). I'm seeing a difference in the ordering of the classpath for compilation and test runs. Here's some log comparisons between a run of the exact same build using Maven 2.0.7, Sun JDK 1.5.0u12 on Windows Vista x86 and then again using Maven 2.0.7, Sun JDK 1.5.0u12 on Windows 2003. Compilation Differences -- --- Windows Vista +++ Windows 2003 @@ -756,21 +756,21 @@ c:\temp\m2\repo\com\cerner\system\instrument\system-instrument\2.0\system-instrument-2.0.jar c:\temp\m2\repo\com\cerner\system\system-i18n\2.0\system-i18n-2.0.jar + c:\temp\m2\repo\com\cerner\system\system-core\2.0\system-core-2.0.jar c:\temp\m2\repo\com\cerner\system\system-jdbc\1.1.3\system-jdbc-1.1.3.jar c:\temp\m2\repo\cerner\system-cache-jetstream\1.3.2\system-cache-jetstream-1.3.2.jar - c:\temp\m2\repo\com\cerner\system\system-core\2.0\system-core-2.0.jar + c:\temp\m2\repo\cerner\dataobject-core\1.1.4\dataobject-core-1.1.4.jar c:\temp\m2\repo\cerner\dataaccess-core\1.1.2\dataaccess-core-1.1.2.jar - c:\temp\m2\repo\cerner\dataobject-core\1.1.4\dataobject-core-1.1.4.jar c:\temp\m2\repo\com\cerner\mmf\mmf-dataaccess-jdbc\1.0-RC1\mmf-dataaccess-jdbc-1.0-RC1.jar c:\temp\m2\repo\com\cerner\mmf\xds\mmf-xds-person\1.0-SNAPSHOT\mmf-xds-person-1.0-SNAPSHOT.jar c:\temp\m2\repo\cerner\universal-id\1.3.0\universal-id-1.3.0.jar - c:\temp\m2\repo\com\cerner\system\transaction\system-transaction\1.2\system-transaction-1.2.jar c:\temp\m2\repo\cerner\system-bootstrap\1.1.1\system-bootstrap-1.1.1.jar + c:\temp\m2\repo\com\cerner\system\transaction\system-transaction\1.2\system-transaction-1.2.jar c:\temp\m2\repo\cerner\system-concurrency\1.3\system-concurrency-1.3.jar c:\temp\m2\repo\cerner\system-management\1.1.1\system-management-1.1.1.jar c:\temp\m2\repo\com\cerner\mmf\mmf-factory\1.0-RC1\mmf-factory-1.0-RC1.jar c:\temp\m2\repo\cerner\system-cache\1.7.2\system-cache-1.7.2.jar c:\temp\m2\repo\cerner\system-registry\1.4.1\system-registry-1.4.1.jar c:\temp\m2\repo\cerner\system-event\1.0.3\system-event-1.0.3.jar c:\temp\m2\repo\cerner\system-urn\1.1.1\system-urn-1.1.1.jar] Surefire launch -- --- Windows Vista +++ Windows 2003 @@ -2022 +2022 @@ -Forking command line: C:\Users\Public\jdk\sun\5_12\jre\bin\java -classpath c:\temp\m2\repo\org\codehaus\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar;c:\temp\m2\repo\junit\junit\3.8.1\junit-3.8.1.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-api\2.3\surefire-api-2.3.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-container-default\1.0-alpha-8\plexus-container-default-1.0-alpha-8.jar;c:\temp\m2\repo\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;c:\temp\m2\repo\commons-lang\commons-lang\2.1\commons-lang-2.1.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-booter\2.3\surefire-booter-2.3.jar org.apache.maven.surefire.booter.SurefireBooter C:\Users\xxx\AppData\Local\Temp\surefire7271tmp C:\Users\xxx\AppData\Local\Temp\surefire7272tmp +Forking command line: c:\install\jdk\sun\5_12\jre\bin\java -classpath c:\temp\m2\repo\org\codehaus\plexus\plexus-archiver\1.0-alpha-7\plexus-archiver-1.0-alpha-7.jar;c:\temp\m2\repo\junit\junit\3.8.1\junit-3.8.1.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-container-default\1.0-alpha-8\plexus-container-default-1.0-alpha-8.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-api\2.3\surefire-api-2.3.jar;c:\temp\m2\repo\classworlds\classworlds\1.1-alpha-2\classworlds-1.1-alpha-2.jar;c:\temp\m2\repo\org\codehaus\plexus\plexus-utils\1.1\plexus-utils-1.1.jar;c:\temp\m2\repo\commons-lang\commons-lang\2.1\commons-lang-2.1.jar;c:\temp\m2\repo\org\apache\maven\surefire\surefire-booter\2.3\surefire-booter-2.3.jar org.apache.maven.surefire.booter.SurefireBooter c:\temp\xxx\2\surefire34874tmp c:\temp\xxx\2\surefire34875tmp Notice how the surefire-api JAR is in a different location this time. was: I'm noticing some seemingly significant issues between running Maven on Windows 2003 and other Windows versions (XP and Vista). I'm seeing a difference in the ordering of the classpath for compilation and test runs. Here's some log comparisons between a run of the exact same build using Maven 2.0.7, Sun JDK 1.5.0u12 on Windows Vista x86 and then again using Maven 2.0.7, Sun JDK 1.5.0u12 on Windows 2003. Compilation Differences -- --- Windows Vista +++ Windows 2003 @@ -756,21 +756,21 @@ c:\temp\m2\repo\com\cerner\system\instrument\system-instrument\2.0\system-instrument-2.0.jar c:\temp\m2\repo\com\cerner\system
[jira] Commented: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112592 ] Nathan Beyer (Cerner) commented on MECLIPSE-172: Is there anything that can be done to help get this patch applied and released? This is a huge pain for people working with multiple projects that have different JRE requirements (1.4 and 1.5 development concurrently). > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder > Attachments: EclipsePlugin.java.patch, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- 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-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Beyer (Cerner) updated MECLIPSE-172: --- Attachment: MECLIPSE-172-fix-and-test.patch Ask and you'll receive ... The file "MECLIPSE-172-fix-and-test.patch" includes the previously posted fix and an update to the unit tests to verify the behavior. If you apply the test bits first, you can observe the test failure before applying the fix. > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-342) Found an equals call to check unrelated types
Found an equals call to check unrelated types - Key: MECLIPSE-342 URL: http://jira.codehaus.org/browse/MECLIPSE-342 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: RAD support Reporter: Nathan Beyer (Cerner) Attachments: rad-writer-invalid-equals.patch While working on an unrelated fix, I noticed FindBugs warning in RadManifestWriter.getMetaInfBaseDirectory(MavenProject). I'm attaching the patch that should correct this warning and implement the intended functionality. -- 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-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114340 ] Nathan Beyer (Cerner) commented on MECLIPSE-172: Can someone set the "test case" and "patch available" flags for this issue? Thanks. > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- 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-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114949 ] Nathan Beyer (Cerner) commented on MECLIPSE-172: Regarding the last few comments: I don't think reading the workspace preferences would be the best route for this plugin, long term. It's difficult to find the workspace and there's practical way to configure it in a portable fashion, so you'd have to point to it ever time you run 'eclipse:eclipse' and that's a pain. I would suggest taking advantage of the inclusion of the OSGi Execution Environment enumeration that's included in the JRE management and point to the best matching Execution Environment, rather than just the default. For example: If the compiler is setup for 1.4, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4. If the compiler is setup for 1.5/5, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5 If the compiler is setup for 1.6/6, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6 Otherwise use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, org.eclipse.jdt.launching.prefs, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- 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: (MECLIPSE-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114949 ] nbeyer_cerner edited comment on MECLIPSE-172 at 11/26/07 1:25 PM: -- Regarding the last few comments: I don't think reading the workspace preferences would be the best route for this plugin, long term. It's difficult to find the workspace and there's no practical way to configure it in a portable fashion, so you'd have to point to it ever time you run 'eclipse:eclipse' via an argument and that's a pain. I would suggest taking advantage of the inclusion of the OSGi Execution Environment enumeration that's included in the JRE management and point to the best matching Execution Environment, rather than just the default. For example: If the compiler is setup for 1.4, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4. If the compiler is setup for 1.5/5, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5 If the compiler is setup for 1.6/6, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6 Otherwise use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType was (Author: nbeyer_cerner): Regarding the last few comments: I don't think reading the workspace preferences would be the best route for this plugin, long term. It's difficult to find the workspace and there's practical way to configure it in a portable fashion, so you'd have to point to it ever time you run 'eclipse:eclipse' and that's a pain. I would suggest taking advantage of the inclusion of the OSGi Execution Environment enumeration that's included in the JRE management and point to the best matching Execution Environment, rather than just the default. For example: If the compiler is setup for 1.4, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.4. If the compiler is setup for 1.5/5, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5 If the compiler is setup for 1.6/6, then use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.6 Otherwise use this - org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, org.eclipse.jdt.launching.prefs, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- 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-172) Don't add Default ClasspathContainer if a alternate JRE or a "Execution Environment" is configured as ClasspathContainer.
[ http://jira.codehaus.org/browse/MECLIPSE-172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_115248 ] Nathan Beyer (Cerner) commented on MECLIPSE-172: Try searching for "Execution Environment" in the help (http://help.eclipse.org/). http://help.eclipse.org/help33/topic/org.eclipse.jdt.doc.user/reference/preferences/java/debug/ref-execution_environments.htm http://help.eclipse.org/help33/topic/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/launching/environments/package-summary.html http://help.eclipse.org/help33/topic/org.eclipse.jdt.doc.isv/reference/extension-points/org_eclipse_jdt_launching_executionEnvironments.html > Don't add Default ClasspathContainer if a alternate JRE or a "Execution > Environment" is configured as ClasspathContainer. > - > > Key: MECLIPSE-172 > URL: http://jira.codehaus.org/browse/MECLIPSE-172 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.2, 2.3 > Environment: Maven 2.0.4, Eclipse 3.2.1, Windows XP >Reporter: Markus Grieder >Assignee: Arnaud Heritier > Fix For: 2.5 > > Attachments: EclipsePlugin.java.patch, > MECLIPSE-172-fix-and-test.patch, org.eclipse.jdt.launching.prefs, patch.txt > > > If have a Eclipse Workspace with Projects where some use Java 1.5 (Default > JRE) and some Java 1.3 > For 1.3-Projects i have configured the following ClasspathContainer: > > org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre > > This generates in ".classpath": > > path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/server_jre"/> > Which is wrong, because the Default JRE is Java 1.5, but the Project should > only see Java 1.3-Libraries and not both. > -> The Default ClasspathContainer should only be added if no JRE_CONTAINER > (alternate JRE or a Execution Environment (>=Eclipse 3.2)) was specified. The > attached Patch replace the "contains"-match with a "starts-with"-match, which > only adds the Default ClasspathContainer if no classpathContainer is > configured which starts with the "JRE_CONTAINER"-Path. -- 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-3713) Remove all references to org.apache.maven:maven:2.04 - cvs.apache.org
Remove all references to org.apache.maven:maven:2.04 - cvs.apache.org - Key: MNG-3713 URL: http://jira.codehaus.org/browse/MNG-3713 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.9, 2.0.8, 2.0.7, 2.0.6, 2.0.5 Reporter: Nathan Beyer (Cerner) Priority: Critical I don't know the complete picture, but here is what I do know. - maven-invoker-plugin + it tests pulls in maven-reporting-impl 2.0.4 during 'test:testCompile' - maven-reporting-impl 2.0.4 [1] has the parent maven-reporting 2.0.4 - maven-reporting 2.0.4 [2] has the parent maven 2.0.4 - maven 2.0.4 contains a repository with the ID, apache.snapshots, and URL, http://cvs.apache.org/maven-snapshot-repository - cvs.apache.org no longer exists The result of this is that every time a build with integration tests is run, there are multiple pauses like cvs.apache.org is looked up and times out. Though this happens consistently, the server is never mentioned for blacklisting. There are plenty of newer versions of maven-reporting, so it seems reasonable to just find these dependencies and upgrade them. [1] http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.pom [2] http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting/2.0.4/maven-reporting-2.0.4.pom [3] http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.4/maven-2.0.4.pom -- 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-3713) Remove all references to org.apache.maven:maven:2.04 - cvs.apache.org
[ http://jira.codehaus.org/browse/MNG-3713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145064#action_145064 ] Nathan Beyer (Cerner) commented on MNG-3713: A temporary work around for this is to setup the following mirror. people.apache.snapshots http://people.apache.org/repo/m2-snapshot-repository apache.snapshots > Remove all references to org.apache.maven:maven:2.04 - cvs.apache.org > - > > Key: MNG-3713 > URL: http://jira.codehaus.org/browse/MNG-3713 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9 >Reporter: Nathan Beyer (Cerner) >Priority: Critical > > I don't know the complete picture, but here is what I do know. > - maven-invoker-plugin + it tests pulls in maven-reporting-impl 2.0.4 during > 'test:testCompile' > - maven-reporting-impl 2.0.4 [1] has the parent maven-reporting 2.0.4 > - maven-reporting 2.0.4 [2] has the parent maven 2.0.4 > - maven 2.0.4 contains a repository with the ID, apache.snapshots, and URL, > http://cvs.apache.org/maven-snapshot-repository > - cvs.apache.org no longer exists > The result of this is that every time a build with integration tests is run, > there are multiple pauses like cvs.apache.org is looked up and times out. > Though this happens consistently, the server is never mentioned for > blacklisting. > There are plenty of newer versions of maven-reporting, so it seems reasonable > to just find these dependencies and upgrade them. > [1] > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting-impl/2.0.4/maven-reporting-impl-2.0.4.pom > [2] > http://repo1.maven.org/maven2/org/apache/maven/reporting/maven-reporting/2.0.4/maven-reporting-2.0.4.pom > [3] http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.4/maven-2.0.4.pom -- 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: (MCLOVER-71) Cannot resolve license file
[ http://jira.codehaus.org/browse/MCLOVER-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96119 ] Nathan Beyer (Cerner) commented on MCLOVER-71: -- I believe the problem was introduced here [1], when the mojo was converted to use ResourceManager instead of Locator. I don't think the ResourceManager performs what the documentation of this particular method says that it will. " * Registers the license file for Clover runtime by setting the clover.license.path system property. * If the user has configured the licenseLocation parameter the plugin tries to resolve it first as a * resource, then as a URL, and then as a file location on the filesystem. If the licenseLocation * parameter has not been defined by the user we look up a default Clover license in the classpath in * /clover.license. " [1] http://svn.apache.org/viewvc/maven/plugins/trunk/maven-clover-plugin/src/main/java/org/apache/maven/plugin/clover/internal/AbstractCloverMojo.java?r1=417137&r2=481679 > Cannot resolve license file > --- > > Key: MCLOVER-71 > URL: http://jira.codehaus.org/browse/MCLOVER-71 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Bryan Madsen > > The license file cannot be found when the license location is a URL. This > works with version 2.3. > [INFO] [clover:instrumentInternal] > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to load license file > [http://scm.apparch.cerner.corp/svn/apparch/licenses/clover.license] > Embedded error: Could not find resource > 'http://scm.apparch.cerner.corp/svn/apparch/licenses/clover.license'. > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to load > license file > [http://scm.apparch.cerner.corp/svn/apparch/licenses/clover.license] > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecycle(DefaultLifecycleExecutor.java:896) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(DefaultLifecycleExecutor.java:739) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:510) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to load > license file > [http://scm.apparch.cerner.corp/svn/apparch/licenses/clover.license] > at > org.apache.maven.plugin.clover.internal.AbstractCloverMojo.registerLicenseFile(AbstractCloverMojo.java:164) > at > org.apache.maven.plugin.clover.internal.AbstractCloverMojo.registerLicenseFile(AbstractCloverMojo.java:134) > at > org.apache.maven.plugin.clover.internal.AbstractCloverMojo.execute(AbstractCloverMojo.java:119) > at > org.apache.maven.plugin.clover.CloverInstrumentInternalMojo.execute(CloverInstrumentInternalMojo.java:132) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) > at > org.apache.mav
[jira] Commented: (SUREFIRE-257) surefire-report reruns tests
[ http://jira.codehaus.org/browse/SUREFIRE-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99904 ] Nathan Beyer (Cerner) commented on SUREFIRE-257: If this isn't available with v2.3, then there's a documentation problem, as the "report-only" goal is advertised as available now and available since 2.3. See the following URLs, which as of this posting say 'report-only' is available. http://maven.apache.org/plugins/maven-surefire-report-plugin/ http://maven.apache.org/plugins/maven-surefire-report-plugin/report-only-mojo.html > surefire-report reruns tests > > > Key: SUREFIRE-257 > URL: http://jira.codehaus.org/browse/SUREFIRE-257 > Project: Maven Surefire > Issue Type: Bug > Components: report plugin > Environment: maven 2.0 >Reporter: Dirk Sturzebecher > Fix For: 2.4 > > Attachments: MSUREFIREREP-6-patch.txt > > > surefire-report reruns the tests. In my case this is not just annoying, but > leads to a failure, as the VM (probably) is reused and leftovers from the > first tests are (definitly) still present. > I run maven with: clean package site -- 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-201) Deployed POM is not valid XML
[ http://jira.codehaus.org/browse/MRELEASE-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_116377 ] Nathan Beyer (Cerner) commented on MRELEASE-201: +1 for ALWAYS including an XML prolog that includes the encoding. Since the POM file are often retrieve via HTTP, the lack of the encoding in the POM can be even more troublesome, as the encoding can be determined by the transport [1] if it's not in the XML prolog, so the "default" of UTF-8 doesn't always apply. This means that the encoding maybe determined by default content-type values set in the web server's configuration. This adds a significant amount of variability, which would be eliminated by explicitly setting the encoding in the prolog. [1] http://www.w3.org/TR/2006/REC-xml-20060816/#sec-prolog-dtd > Deployed POM is not valid XML > - > > Key: MRELEASE-201 > URL: http://jira.codehaus.org/browse/MRELEASE-201 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Reporter: Joerg Schaible > Attachments: MNG-2362.zip > > > If the POM has utf-8 encoding and you make usage of entities to support > extended characters, these characters are no longer encoded as entities in > the repository (well, the effect is already visible in > target/effective-pom.xml). This is not a rule of general, POMs with packaging > "pom" are installed and deployed correctly. > Multi module example. The attached archive contains a parent POM and a POM > for a jar. Both UTF-8 encoded POMs contain a developer with a name using an > entitiy. Releasing the POMs they are written with the expanded entitiy making > the XML invalid. -- 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-300) Regression: release:prepare fails for svn
[ http://jira.codehaus.org/browse/MRELEASE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_120091 ] Nathan Beyer (Cerner) commented on MRELEASE-300: I just ran into this exact same error on Windows Vista, Sun JDK 5u14, SVN 1.4.5. I've been releasing code with 2.0-beta-7 since it was released, so I didn't think it was that. The only thing I could narrow it down to is the cobertura plugin in the POM build and reporting sections. I just started using it and this was the first project I was going to release with it. I have no idea what the root problem is, but removing cobertura from the POM did fix the problem and I was able to release. For whatever that's worth ... > Regression: release:prepare fails for svn > - > > Key: MRELEASE-300 > URL: http://jira.codehaus.org/browse/MRELEASE-300 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 > Environment: Windows, M205, JDK 1.4.2, svn 1.4.2 >Reporter: Joerg Schaible >Priority: Blocker > > After the upgrade to 2.0-beta-7 from 2.0-beta-6 the release:prepare fails at > the last step: > == %< === > $ mvn release:prepare > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'release'. > [INFO] > > [INFO] Building Elsag Master Project > [INFO]task-segment: [release:prepare] (aggregator-style) > [INFO] > > [INFO] [release:prepare] > [INFO] Resuming release from phase 'scm-commit-release' > [INFO] Checking in modified POMs... > [INFO] Executing: svn --non-interactive commit --file > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-84899240.commit --targets > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-13397-targets > [INFO] Working directory: D:\work\standard\master-pom > [INFO] Tagging release with the label v_117... > [INFO] Executing: svn --non-interactive copy --file > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-1381395764.commit . > http://websvn/svn/essvn/development/buildsystem/maven-2/master-pom/tags/v_117 > [INFO] Working directory: D:\work\standard\master-pom > [INFO] Transforming 'Elsag Master Project'... > [INFO] Not removing release POMs > [INFO] Checking in modified POMs... > [INFO] Executing: svn --non-interactive commit --file > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-1672780400.commit --targets > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-13398-targets > [INFO] Working directory: D:\work\standard\master-pom > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The svn command failed. > Command output: > svn: Commit succeeded, but other errors follow: > svn: Error bumping revisions post-commit (details follow): > svn: In directory 'D:\work\standard\master-pom' > svn: Error processing command 'committed' in 'D:\work\standard\master-pom' > svn: Error replacing text-base of 'pom.xml' > svn: Can't move 'D:\work\standard\master-pom\.svn\tmp\pom.xml.tmp' to > 'D:\work\standard\master-pom\pom.xml': Zugriff verweigert > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 21 seconds > [INFO] Finished at: Tue Nov 27 11:59:30 CET 2007 > [INFO] Final Memory: 5M/10M > [INFO] > > == %< === > After switching back to 2.0.-beta-6, the step works flawlessly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-87) doc-files ignored if they reside in the resources directory
[ http://jira.codehaus.org/browse/MJAVADOC-87?page=comments#action_77471 ]
Nathan Beyer (Cerner) commented on MJAVADOC-87:
---
I've found a workaround for the configuration of the javadoc plugin. The
"-sourcepath" that's generated by default is this
"${project.basedir}/src/main/java;${project.basedir}/src/main/javadoc" (with
the properties resolved to their absolute value. If you put the 'javadoc'
folder first, everything is copied as expected. Below is a configuration
snippet that copies all the doc-files correctly.
org.apache.maven.plugins
maven-javadoc-plugin
${project.basedir}/src/main/javadoc;${project.basedir}/src/main/java
true
I do think this needs to be reopened, but I don't think non-commiters can do
that. At least I know my user can't do that.
> doc-files ignored if they reside in the resources directory
> ---
>
> Key: MJAVADOC-87
> URL: http://jira.codehaus.org/browse/MJAVADOC-87
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Matthew Beermann
> Assigned To: Vincent Siveton
> Fix For: 2.1
>
> Attachments: my-app.zip
>
>
> It looks like MJAVADOC-76 was closed prematurely, or maybe it just had a bad
> summary. The bug is this: if you have a "doc-files" folder in the
> "src/main/resources" branch of your project, its contents will be omitted
> from the Javadoc output. However, if you move the same folder over to
> "src/main/java", it will be included in the output. This bug is present in
> the released (2.0) version of the plugin.
> The file "package.html", by comparison, will be included in the Javadoc
> output no matter where it is. This is the expected behavior, AFAICT. More
> information about the "doc-files" directory can be found here:
> http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html#unprocessed
--
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-243) SVN provider reports a warning for 'X' status as unknown, but it's an external link
SVN provider reports a warning for 'X' status as unknown, but it's an external link --- Key: SCM-243 URL: http://jira.codehaus.org/browse/SCM-243 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0-beta-3 Environment: Windows XP SP2, Sun JDK 1.4.2_12, Maven 2.0.4, SVN 1.4.0 Reporter: Nathan Beyer (Cerner) Priority: Minor When performing a 'release:prepare' on a project that contains an 'svn:externals' linked folder, the following warnings and messages are produced. [INFO] Unknown file status: 'X'. [WARNING] Unexpected input, the line must be at least seven characters long. Line: ''. [INFO] Unknown file status: 'P'. I'm not sure what's causing the "unexpected input" and "P" message, but the "X" message is from a folder in the project that is pulled into the working copy via the svn:externals property [1]. This is an SVN property that's set on a folder and makes the SVN client perform an additional "unversioned" checkout of a URL. The externals will only exist in the working copy. When the "svn status" is run on a project an external item is given the status "X". As such, the status X can safely be ignored and treated as either "no modification" or "ignored" would be. Here's a dump of the help from svn status for more information. C:\temp>svn help status status (stat, st): Print the status of working copy files and directories. usage: status [PATH...] With no args, print only locally modified items (no network access). With -u, add working revision and server out-of-date information. With -v, print full revision information on every item. The first six columns in the output are each one character wide: First column: Says if item was added, deleted, or otherwise changed ' ' no modifications 'A' Added 'C' Conflicted 'D' Deleted 'I' Ignored 'M' Modified 'R' Replaced 'X' item is unversioned, but is used by an externals definition '?' item is not under version control [1] http://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.special.externals -- 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: (MEV-468) FindBugs metadata doesn't include 1.1.1 release
FindBugs metadata doesn't include 1.1.1 release --- Key: MEV-468 URL: http://jira.codehaus.org/browse/MEV-468 Project: Maven Evangelism Issue Type: Bug Reporter: Nathan Beyer (Cerner) The following FindBugs-relate metadata files don't include the 1.1.1 versions. http://repo1.maven.org/maven2/net/sourceforge/findbugs/findbugs/maven-metadata.xml http://repo1.maven.org/maven2/net/sourceforge/findbugs/coreplugin/maven-metadata.xml http://repo1.maven.org/maven2/net/sourceforge/findbugs/annotations/maven-metadata.xml http://repo1.maven.org/maven2/net/sourceforge/findbugs/findbugs-ant/maven-metadata.xml http://repo1.maven.org/maven2/net/sourceforge/findbugs/findbugsGUI/maven-metadata.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] Commented: (MEV-443) Several projects have maven-metadata.xml files that are missing released versions
[ http://jira.codehaus.org/browse/MEV-443?page=comments#action_81727 ] Nathan Beyer (Cerner) commented on MEV-443: --- What's a pragmatic time frame for Archiva being used by the central repo and having these issues resolved? The last comment on this issue was 3 months ago. Is it still practical to postpone these metadata fixes? What can the community do to help? If we posted updated metadata files, could these be uploaded? What can we do to push Archiva over the line? > Several projects have maven-metadata.xml files that are missing released > versions > - > > Key: MEV-443 > URL: http://jira.codehaus.org/browse/MEV-443 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Patrick Moore > Attachments: maven-metadata.xml > > > I am trying to use the version range feature that is talked about in Better > builds with Maven. I am specifying the commons-httpclient dependency as > > commons-httpclient > commons-httpclient > [3.1-alpha1,) > > Unfortunately, the usefulness of this feature is being sabotaged because the > latest version of artificat is not listed in the maven-metadata.xml. > Please update the maven-metadata.xml in this project and others. In > particular > hsqldb, > commons-*, > rhino/js > htmlunit > When updating those files, please do not list the versions using dates as > their version id as it screws up the maven feature that allows dependencies > to specify a version range. -- 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-1360) JUnit 4.1 and 4.2 Uploads
JUnit 4.1 and 4.2 Uploads - Key: MAVENUPLOAD-1360 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1360 Project: maven-upload-requests Issue Type: Task Reporter: Nathan Beyer (Cerner) Attachments: junit-4.1-bundle.jar, junit-4.2-bundle.jar Upload bundles for JUnit 4.1 and 4.2. The 4.1 bundle is re-upload, so that the "junit/junit/maven-metadata.xml" file is updated. The 4.2 bundle is new. The bundles were "manually" created, but match the JARs created by "mvn repository:create-bundle". I don't have a public URL for downloading the bundles, so I've posted them as attachments to this issue. -- 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-1360) JUnit 4.1 and 4.2 Uploads
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86875 ] Nathan Beyer (Cerner) commented on MAVENUPLOAD-1360: Looks great. Thanks. > JUnit 4.1 and 4.2 Uploads > - > > Key: MAVENUPLOAD-1360 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1360 > Project: maven-upload-requests > Issue Type: Task >Reporter: Nathan Beyer (Cerner) > Assigned To: Carlos Sanchez > Attachments: junit-4.1-bundle.jar, junit-4.2-bundle.jar > > > Upload bundles for JUnit 4.1 and 4.2. > The 4.1 bundle is re-upload, so that the "junit/junit/maven-metadata.xml" > file is updated. The 4.2 bundle is new. The bundles were "manually" created, > but match the JARs created by "mvn repository:create-bundle". > I don't have a public URL for downloading the bundles, so I've posted them as > attachments to this issue. -- 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
