[jira] Created: (SUREFIRE-388) JUnit4 not activated when using junit-dep
JUnit4 not activated when using junit-dep - Key: SUREFIRE-388 URL: http://jira.codehaus.org/browse/SUREFIRE-388 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.3.1 Reporter: Martin Gilday In the central repo there is now a copy of JUnit 4 which is correctly Mavenised, it has a dependency tree rather than one single uber-jar. This artifact is used by the JMock 2 artifacts. Ideally the presence of this artifact should activate JUnit4 runner as well as the original. -- 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-388) JUnit4 not activated when using junit-dep
[ http://jira.codehaus.org/browse/SUREFIRE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114662 ] Martin Gilday commented on SUREFIRE-388: junit junit-dep 4.4 > JUnit4 not activated when using junit-dep > - > > Key: SUREFIRE-388 > URL: http://jira.codehaus.org/browse/SUREFIRE-388 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.3.1 >Reporter: Martin Gilday > > In the central repo there is now a copy of JUnit 4 which is correctly > Mavenised, it has a dependency tree rather than one single uber-jar. This > artifact is used by the JMock 2 artifacts. Ideally the presence of this > artifact should activate JUnit4 runner as well as the original. -- 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-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106366
]
Martin Gilday commented on SUREFIRE-298:
Thanks Julian, I had forgotten to activate the Apache profile. I would suggest
using ${settings.localRepository} rather than ${user.home} on the javaagent
path line to allow for non-standard repo locations.
> Problem using -javaagent
>
>
> Key: SUREFIRE-298
> URL: http://jira.codehaus.org/browse/SUREFIRE-298
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP
>Reporter: Bård Dybwad Kristensen
> Fix For: 2.4
>
>
> I try to run the JMockit framework in my tests to do some mocking of static
> classes.
> I supply the argLine arguments as follows (some spaces added to avoid
> smileys):
>
> -javaagent:D : \
> .m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar
> once
>
> This does not work. The problem is that the Mockit class is not able to find
> neither the class it is suppose to mock nor the class to use as a mock. I
> have made two small classes, Math and MockMath each with one similar method
> and one static String constant. My setup-method in the testclass is as
> follows:
> protected void setUp() throws Exception {
> super.setUp();
> System.out.println(Math.TEST);
> System.out.println(MockMath.TEST);
> Mockit.redefineMethods(Math.class, MockMath.class);
> }
> When I run this, the two System.out.printlns runs Ok, and prints what it
> should, but the Mockit class returns the following error:
> java.lang.RuntimeException: Failed to read class file for
> no.ergo.ec.vaktplan.MockMath
> at mockit.Mockit.readClassFile(Mockit.java:228)
> at mockit.Mockit.collectMockMethods(Mockit.java:191)
> at mockit.Mockit.redefineMethods(Mockit.java:176)
> at mockit.Mockit.redefineMethods(Mockit.java:162)
> at no.ergo.ec.vaktplan.TestMain.setUp(TestMain.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> Caused by: java.io.IOException: Class not found
> at org.objectweb.asm2.ClassReader.readClass(ClassReader.java:259)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:236)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:246)
> at mockit.Mockit.readClassFile(Mockit.java:225)
> It is not able to find the class, which was ok in the System.out run just
> before.
> If I do a mvn eclipse:eclipse and create an eclipse project, I can run the
> test class without any problems in Eclipse (with exactly tha same VM
> arguments as I use in the pom.xml)
> So I guess it is some issue with which classloader that loads the Mockit
> class when it is supplied as the instrumentation class via the -javaagent
> switch.
> Anybody experience any problems like this using the -javaagent switch?
> Any feedback would be greatly appreciated.
> regards,
> bdk
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
[jira] Commented: (SUREFIRE-298) Problem using -javaagent
[
http://jira.codehaus.org/browse/SUREFIRE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106300
]
Martin Gilday commented on SUREFIRE-298:
I am attempting this with 2.4-SNAPSHOT and getting the error "Exception in
thread "Main Thread" java.lang.NoClassDefFoundError:
org/codehaus/plexus/util/cli/StreamConsumer". Please could you post a full
example POM?
> Problem using -javaagent
>
>
> Key: SUREFIRE-298
> URL: http://jira.codehaus.org/browse/SUREFIRE-298
> Project: Maven Surefire
> Issue Type: Bug
> Components: classloading
>Affects Versions: 2.0 (2.2 plugin)
> Environment: Windows XP
>Reporter: Bård Dybwad Kristensen
> Fix For: 2.4
>
>
> I try to run the JMockit framework in my tests to do some mocking of static
> classes.
> I supply the argLine arguments as follows (some spaces added to avoid
> smileys):
>
> -javaagent:D : \
> .m2\repository\jmockit\jmockit\0.83\jmockit-0.83.jar
> once
>
> This does not work. The problem is that the Mockit class is not able to find
> neither the class it is suppose to mock nor the class to use as a mock. I
> have made two small classes, Math and MockMath each with one similar method
> and one static String constant. My setup-method in the testclass is as
> follows:
> protected void setUp() throws Exception {
> super.setUp();
> System.out.println(Math.TEST);
> System.out.println(MockMath.TEST);
> Mockit.redefineMethods(Math.class, MockMath.class);
> }
> When I run this, the two System.out.printlns runs Ok, and prints what it
> should, but the Mockit class returns the following error:
> java.lang.RuntimeException: Failed to read class file for
> no.ergo.ec.vaktplan.MockMath
> at mockit.Mockit.readClassFile(Mockit.java:228)
> at mockit.Mockit.collectMockMethods(Mockit.java:191)
> at mockit.Mockit.redefineMethods(Mockit.java:176)
> at mockit.Mockit.redefineMethods(Mockit.java:162)
> at no.ergo.ec.vaktplan.TestMain.setUp(TestMain.java:12)
> at junit.framework.TestCase.runBare(TestCase.java:125)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
> at
> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
> at
> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
> Caused by: java.io.IOException: Class not found
> at org.objectweb.asm2.ClassReader.readClass(ClassReader.java:259)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:236)
> at org.objectweb.asm2.ClassReader.(ClassReader.java:246)
> at mockit.Mockit.readClassFile(Mockit.java:225)
> It is not able to find the class, which was ok in the System.out run just
> before.
> If I do a mvn eclipse:eclipse and create an eclipse project, I can run the
> test class without any problems in Eclipse (with exactly tha same VM
> arguments as I use in the pom.xml)
> So I guess it is some issue with which classloader that loads the Mockit
> class when it is supplied as the instrumentation class via the -javaagent
> switch.
> Anybody experience any problems like this using the -javaagent switch?
> Any feedback would be greatly appreciated.
> regards,
> bdk
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact o
[jira] Closed: (MNG-3126) mvn.bat always exits 0 on WinXP
[ http://jira.codehaus.org/browse/MNG-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gilday closed MNG-3126. -- Resolution: Duplicate Thanks Dan, Marking this as a duplicate. > mvn.bat always exits 0 on WinXP > --- > > Key: MNG-3126 > URL: http://jira.codehaus.org/browse/MNG-3126 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.7 >Reporter: Martin Gilday > > http://jira.codehaus.org/browse/MNG-2127 seems to have started again with > 2.0.7. Regardless of a build passing or failing an %ERRORLVEL%/exit code of > 0 is set. When you change back to 2.0.6 an exir code of 1 is correctly > output for a failure. -- 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-3126) mvn.bat always exits 0 on WinXP
mvn.bat always exits 0 on WinXP --- Key: MNG-3126 URL: http://jira.codehaus.org/browse/MNG-3126 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.7 Reporter: Martin Gilday http://jira.codehaus.org/browse/MNG-2127 seems to have started again with 2.0.7. Regardless of a build passing or failing an %ERRORLVEL%/exit code of 0 is set. When you change back to 2.0.6 an exir code of 1 is correctly output for a failure. -- 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-2127) mvn.bat always exits 0 on Windows 2000 and higher
[ http://jira.codehaus.org/browse/MNG-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103645 ] Martin Gilday commented on MNG-2127: What is the situation with this on WinXP SP2, with Maven 2.0.7? I have set MAVEN_TERMINATE_CMD=on and regardless of which command I run I am always getting %ERRORLEVEL% as 0. > mvn.bat always exits 0 on Windows 2000 and higher > - > > Key: MNG-2127 > URL: http://jira.codehaus.org/browse/MNG-2127 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0, 2.0.1, 2.0.2 > Environment: I'm on Windows 2003 Server, but this will affect any OS > for which the %OS% environment variable is Windows_NT, including Windows XP > and Windows 2000. >Reporter: Dan Fabulich >Assignee: Brett Porter >Priority: Blocker > Attachments: maven-task.xml, mvnfixed.bat, mvnfixed.bat > > > Write the following ant script and run it on Windows 2000 or higher: > failonerror="true" /> > This will run "mvn" with no arguments, which will always fail. But the ant > script will claim "build successful", because the exit value of mvn.bat was > 0. It is absolutely critical that this work correctly, or else I can't > integrate Maven into any other automated system. > This is happening because mvn.bat is improperly abusing local scoping. On > line 130 of mvn.bat, we execute maven, but we don't do anything with its exit > value... we just always goto end. The fix for this is to add a line 131 that > says "if errorlevel 1 goto error", which will behave correctly. > (I marked this as having a test case because I've included a test ant script, > but technically this isn't a JUnit test case, so it may be an inappropriate > use of the "testcase included" marker.) -- 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-56) targetJdk support for jdk 1.6
[ http://jira.codehaus.org/browse/MPMD-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100339 ] Martin Gilday commented on MPMD-56: --- I have attached two patches. The first simply adds in 1.6 into the selection statement. The second I think is a slight improvement as it uses SourceType.getSourceTypeForId from PMD to select based upon an id. This should protect from having to change the plugin to eventually support 1.7 (Of course a new release would still be needed to use the new version of PMD). > targetJdk support for jdk 1.6 > - > > Key: MPMD-56 > URL: http://jira.codehaus.org/browse/MPMD-56 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Any >Reporter: Jeff Campbell > Attachments: martingilday-pmd-patch.txt, martingilday-pmd-patch2.txt > > > Currently you can only set a targetJdk to 1.3, 1.4, and 1.5 what about > 1.6? -- 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: (MPMD-56) targetJdk support for jdk 1.6
[ http://jira.codehaus.org/browse/MPMD-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gilday updated MPMD-56: -- Attachment: martingilday-pmd-patch2.txt > targetJdk support for jdk 1.6 > - > > Key: MPMD-56 > URL: http://jira.codehaus.org/browse/MPMD-56 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Any >Reporter: Jeff Campbell > Attachments: martingilday-pmd-patch.txt, martingilday-pmd-patch2.txt > > > Currently you can only set a targetJdk to 1.3, 1.4, and 1.5 what about > 1.6? -- 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: (MPMD-56) targetJdk support for jdk 1.6
[ http://jira.codehaus.org/browse/MPMD-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Gilday updated MPMD-56: -- Attachment: martingilday-pmd-patch.txt > targetJdk support for jdk 1.6 > - > > Key: MPMD-56 > URL: http://jira.codehaus.org/browse/MPMD-56 > Project: Maven 2.x PMD Plugin > Issue Type: Bug > Components: PMD >Affects Versions: 2.2 > Environment: Any >Reporter: Jeff Campbell > Attachments: martingilday-pmd-patch.txt > > > Currently you can only set a targetJdk to 1.3, 1.4, and 1.5 what about > 1.6? -- 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-1664) Write mojos w/Groovy
[ http://jira.codehaus.org/browse/MNG-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88502 ] Martin Gilday commented on MNG-1664: I have documented how to use the current groovy-maven-tools to write groovy mojos. Hopefully this will highlight the differences in the two approaches http://www.martingilday.org/articles/Groovy+Maven+Mojos > Write mojos w/Groovy > > > Key: MNG-1664 > URL: http://jira.codehaus.org/browse/MNG-1664 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Affects Versions: 2.0 >Reporter: Jason Dillon > Fix For: 2.2.x > > Attachments: maven2-groovy-mojo-support.tar.gz > > > Attached is an archive containing 3 modules: > * plexus-groovy-factory > * maven-plugin-tools-groovy > * groovytest-maven-plugin > plexus-groovy-factory is a plexus component factory, which allows Groovy > objects to be used as components inside of Plexus. I started with the > existing module of the same name in the plexus project, but most of it > changed, so I just included the entire module instead of providing a patch. > Tests included. > maven-plugin-tools-groovy provides the ability to extract MojoDescriptors > from one or more .groovy sources. This is based off of the beanshell > extractor.sh... its kinda hacky, but functions _well enough_ for now. > groovytest-maven-plugin is used to test. > groovytest-maven-plugin is just a simple maven plugin that uses the new > groovy script support. It shows that a .groovy can use other .groovy sources > inside of the plugin, and shows that the descriptor extractor functions. Its > basically useful for integration testing. > * * * > Someone should check & update the version details for the parent pom of these > modules. I just used whatever I had on my local system to get it working. > This plugin depends on Groovy 1.0 JSR 05, but 04 will sorta work, but will > not function with included classes in the same jar. Since 04 was just > releases yesterday, these modules depend on 05 SNAPSHOT, which should be > available on the codehaus ci repo. When 1.0 is released this dep should be > updated to that version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=comments#action_81706 ] Martin Gilday commented on SUREFIRE-31: --- Is anything "official" being worked on for this at the moment? It seems to be blocking many people from migrating to JUnit 4. I too am considering using TestNG now instead. > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, > SUREFIRE31_karl_maven-surefire-plugin.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit_2ndMethod.patch > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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-128) SCM properties being replaced during release:perform
[ http://jira.codehaus.org/browse/MRELEASE-128?page=comments#action_67977 ]
Martin Gilday commented on MRELEASE-128:
I posted a question regarding this on the maven users mailing list. At least
now I know it appears to be a bug and not my POM.
But I get the problem when using release:perform as well. Do I need to create
another issue for this (quite new to JIRA/reporting)?
Another slight difference is that my property is for the SCM username and
password - $\{cvs-user\} and $\{cvs-pass\}. After a release:perform both of
these properties are replaced with the ones from the settings.xml. I have
tried removing the properties from the POM and specifiying them with \
-Dusername and \-Dpassword. Doing this also reasults in the SCM path being
altered and the login details added. Both the exported POM and the original
POM are incorrectly altered.
{code:xml}
scm:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
scm:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
{code}
turns to
{code:xml}
scm:cvs:pserver:joebloggs:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
scm:cvs:pserver:joebloggs:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:MyProjectName
{code}
after the release:perform is called.
> SCM properties being replaced during release:perform
>
>
> Key: MRELEASE-128
> URL: http://jira.codehaus.org/browse/MRELEASE-128
> Project: Maven 2.x Release Plugin
> Type: Bug
> Environment: Windows XP client, Linux repo, CVS, Maven 2.0.4
> Reporter: Craig Dickson
> Attachments: after-release-perform-pom.xml, after-release-prepre-pom.xml,
> original-pom.xml
>
>
> The section of a pom in CVS for a pom archetype project looks like this
> prior to executing release:prepare :
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
>
> Then after executing release:prepare, the pom in CVS looks like this (new
> tag is only difference):
>
> ${base.cvs.url}:commons-maven/uber-pom
>
> ${base.cvs.url}:commons-maven/uber-pom
> ${base.viewcvs.url}/commons-maven/uber-pom
> R-1_7
>
> Then after executing release:perform, the pom looks like this in CVS:
>
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> scm:cvs:pserver:behrcvs.masco-coatings.com:/usr/cvsroot:commons-maven/uber-pom
>
> http://behrcvs.masco-coatings.com/cgi-bin/viewcvs.cgi/commons-maven/uber-pom
>
> Notice that the properties that were there for the base URLs for CVS and
> ViewCVS have been replaced with literal values.
> No other properties in the POM are being replaced
--
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: (CONTINUUM-730) Properties not resolved in SCM
[ http://jira.codehaus.org/browse/CONTINUUM-730?page=comments#action_67565
]
Martin Gilday commented on CONTINUUM-730:
-
Thank you for such a prompt reply. Sorry if this was unsuitable for the JIRA.
> Properties not resolved in SCM
> --
>
> Key: CONTINUUM-730
> URL: http://jira.codehaus.org/browse/CONTINUUM-730
> Project: Continuum
> Type: Bug
> Environment: Redhat 4, Continuum 1.03, JDK 1.5.06
> Reporter: Martin Gilday
> Assignee: Emmanuel Venisse
>
>
> Properties do not seem to be interpreted when I place them inside a SCM
> connection.
> My $MAVEN_HOME/conf/settings.xml contains
> {noformat}
>
> property-overrides
>
> {noformat}
> Then in my user settings file (/home/continuum/.m2/settings.xml) contains:
> {noformat}
>
> property-overrides
>
> name
> password
>
>
> {noformat}
> Finally my pom contains
> {noformat}
>
> scm:cvs:pserver:${cvs-user}:[EMAIL
> PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
> scm:cvs:pserver:${cvs-user}:[EMAIL
> PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
>
> {noformat}
> When I run the build from Continuum I recieve the error
> {noformat}
> Provider message: The cvs command failed.
> Command output:
> ---
> Fatal error, aborting.
> ${cvs-user}: no such user
> ---
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-730) Properties not resolved in SCM
[ http://jira.codehaus.org/browse/CONTINUUM-730?page=comments#action_67526
]
Martin Gilday commented on CONTINUUM-730:
-
It seems that if I remove the project and then readd it then it will find the
settings. Are properties only read once when a project is first loaded?
> Properties not resolved in SCM
> --
>
> Key: CONTINUUM-730
> URL: http://jira.codehaus.org/browse/CONTINUUM-730
> Project: Continuum
> Type: Bug
> Environment: Redhat 4, Continuum 1.03, JDK 1.5.06
> Reporter: Martin Gilday
>
>
> Properties do not seem to be interpreted when I place them inside a SCM
> connection.
> My $MAVEN_HOME/conf/settings.xml contains
> {noformat}
>
> property-overrides
>
> {noformat}
> Then in my user settings file (/home/continuum/.m2/settings.xml) contains:
> {noformat}
>
> property-overrides
>
> name
> password
>
>
> {noformat}
> Finally my pom contains
> {noformat}
>
> scm:cvs:pserver:${cvs-user}:[EMAIL
> PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
> scm:cvs:pserver:${cvs-user}:[EMAIL
> PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
>
> {noformat}
> When I run the build from Continuum I recieve the error
> {noformat}
> Provider message: The cvs command failed.
> Command output:
> ---
> Fatal error, aborting.
> ${cvs-user}: no such user
> ---
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-730) Properties not resolved in SCM
[ http://jira.codehaus.org/browse/CONTINUUM-730?page=comments#action_67523
]
Martin Gilday commented on CONTINUUM-730:
-
Forgot to mention. I am loading the settings using the following in my
application.xml
{noformat}
org.apache.maven.settings.MavenSettingsBuilder
org.apache.maven.settings.DefaultMavenSettingsBuilder
/usr/maven/maven-2.0.4/conf/settings.xml
/home/continuum/.m2/settings.xml
{noformat}
I can see them being loaded in the logs.
> Properties not resolved in SCM
> --
>
> Key: CONTINUUM-730
> URL: http://jira.codehaus.org/browse/CONTINUUM-730
> Project: Continuum
> Type: Bug
> Environment: Redhat 4, Continuum 1.03, JDK 1.5.06
> Reporter: Martin Gilday
>
>
> Properties do not seem to be interpreted when I place them inside a SCM
> connection.
> My $MAVEN_HOME/conf/settings.xml contains
> {noformat}
>
> property-overrides
>
> {noformat}
> Then in my user settings file (/home/continuum/.m2/settings.xml) contains:
> {noformat}
>
> property-overrides
>
> name
> password
>
>
> {noformat}
> Finally my pom contains
> {noformat}
>
> scm:cvs:pserver:${cvs-user}:[EMAIL
> PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
> scm:cvs:pserver:${cvs-user}:[EMAIL
> PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
>
> {noformat}
> When I run the build from Continuum I recieve the error
> {noformat}
> Provider message: The cvs command failed.
> Command output:
> ---
> Fatal error, aborting.
> ${cvs-user}: no such user
> ---
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-730) Properties not resolved in SCM
Properties not resolved in SCM
--
Key: CONTINUUM-730
URL: http://jira.codehaus.org/browse/CONTINUUM-730
Project: Continuum
Type: Bug
Environment: Redhat 4, Continuum 1.03, JDK 1.5.06
Reporter: Martin Gilday
Properties do not seem to be interpreted when I place them inside a SCM
connection.
My $MAVEN_HOME/conf/settings.xml contains
{noformat}
property-overrides
{noformat}
Then in my user settings file (/home/continuum/.m2/settings.xml) contains:
{noformat}
property-overrides
name
password
{noformat}
Finally my pom contains
{noformat}
scm:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
scm:cvs:pserver:${cvs-user}:[EMAIL
PROTECTED]:/usr/share/cvs/cvsroot:UTL-GeneralUtilities
{noformat}
When I run the build from Continuum I recieve the error
{noformat}
Provider message: The cvs command failed.
Command output:
---
Fatal error, aborting.
${cvs-user}: no such user
---
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
