[jira] Commented: (MNG-2797) Instance variables are null when extending a mojo
[
http://jira.codehaus.org/browse/MNG-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96252
]
Alessio Pace commented on MNG-2797:
---
Well,
I'm having the same issue. I extend the exec-maven-plugin, which defines a
boolean parameter with default-value=true and in its execute() method does
something upon it's true evaluation.
My MOJO extends the ExecJavaMojo basically doing nothing (as the example
provided above) and the boolean variable is found to be false this time.
So, basically it's not injected the default value but is left initialized, and
so it has the default value for a Java boolean variable declaration: false.
I posted the issue on the maven-user ML.
Instance variables are null when extending a mojo
-
Key: MNG-2797
URL: http://jira.codehaus.org/browse/MNG-2797
Project: Maven 2
Issue Type: Bug
Components: Plugin API
Affects Versions: 2.0.4
Environment: Tested on Fedora Core 6.
Reporter: Petar Tahchiev
Assignee: Carlos Sanchez
Hi gyus,
first of all I want to be execused if this is not the right place to post
this. Now on the problem: I am trying to make my own mojo and for the purpose
I extend an exisitng mojo (for example SurefirePlugin). So my mojo is
something like this:
public class MyTestMojo extends AbstractMojo
{
/**
* This is the mojo's main method.
*
* @throws MojoExecutionException in case of error
* @throws MojoFailureException in case of error
*/
public void execute() throws MojoExecutionException, MojoFailureException
{
super.execute();
}
}
After building my mojo as maven plugin and trying to run it, I get the
following stack-trace.
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:355)
at
org.apache.cactus.integration.m2.CactusTestMojo.execute(CactusTestMojo.java:53)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
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)
And I see on the line 355 of the maven-surefire-plugin (ver.2.2) it stays:
else if ( !testClassesDirectory.exists() )
and after debugging it, I see that testClassesDirectory is always null !!!
It is really surpising to me, as testClassesDirectory is initialized with the
following lines:
/**
* The directory containing generated test classes of the project being
tested.
*
* @parameter expression=${project.build.testOutputDirectory}
* @required
*/
private File testClassesDirectory;
OK, I want to hear what do you think?
--
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-2800) Default layout .pathOf(Artifact) resolution of SNAPSHOT incorrect.
[
http://jira.codehaus.org/browse/MNG-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96254
]
Matthias Wurm commented on MNG-2800:
Could you post your tentative patch for DefaultArtifact? I'm using Archiva
together with the Maven Antlib, and due to this bug all dependencies with
SNAPSHOT-Versions in my classpaths are screwed.
Default layout .pathOf(Artifact) resolution of SNAPSHOT incorrect.
--
Key: MNG-2800
URL: http://jira.codehaus.org/browse/MNG-2800
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.4
Reporter: Joakim Erdfelt
Priority: Minor
When working with SNAPSHOT deps from within Archiva, the resolution of the
Artifact to a file system path is incorrect.
Example:
* groupId: {{com.foo}}
* artifactId: {{foo-lib}}
* version: {{1.0-20070130.172557-1}}
* type: {{jar}}
Resolves to the incorrect path
{{/com/foo/foo-lib/1.0-20070130.172557-1/foo-lib-1.0-20070130.172557-1.jar}}
It should be
{{/com/foo/foo-lib/1.0-SNAPSHOT/foo-lib-1.0-20070130.172557-1.jar}}
This is the apparent fault of
org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(Artifact)
method not having a check for .isSnapshot()
--
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-106) Remember the Dry Run Status
[ http://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96260 ] Mark Hobson commented on MRELEASE-106: -- Perhaps dryRun should become part of the ReleaseDescriptor? Remember the Dry Run Status --- Key: MRELEASE-106 URL: http://jira.codehaus.org/browse/MRELEASE-106 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Priority: Minor When doing a dry run of a release, make note of that in the release.properties file so that a reasonable failure can occur if the user tries to perform the release. Also, this flag might be used to allow a non-dry-run prepare to occur without needing to do a clean in between (maybe also not need to prompt but reuse the same answers as in the dry run). -- 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: (MRELEASE-233) ScmCheckModificationsPhase ignores pom.xml
ScmCheckModificationsPhase ignores pom.xml -- Key: MRELEASE-233 URL: http://jira.codehaus.org/browse/MRELEASE-233 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: patch.txt Any local changes to pom.xmls are committed when using release:prepare. Such changes should be committed manually by the user before releasing to keep commits atomic. Thus pom.xml needs to be removed from the ScmCheckModificationsPhase exclusion list to fail the build under these circumstances. The attached patch removes pom.xml from the excluded files and realigns the tests accordingly. -- 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: (SCM-316) Fix change logs parsing when the scm url ends with a trailing slash
[ http://jira.codehaus.org/browse/SCM-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-316: - Assignee: Emmanuel Venisse Fix Version/s: 1.0 Fix change logs parsing when the scm url ends with a trailing slash --- Key: SCM-316 URL: http://jira.codehaus.org/browse/SCM-316 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Affects Versions: 1.0-rc1 Reporter: Emmanuel Venisse Assignee: Emmanuel Venisse Fix For: 1.0 The pb is the date/user/comment isn't populated -- 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-316) Fix change logs parsing when the scm url ends with a trailing slash
Fix change logs parsing when the scm url ends with a trailing slash --- Key: SCM-316 URL: http://jira.codehaus.org/browse/SCM-316 Project: Maven SCM Issue Type: Bug Components: maven-scm-api Affects Versions: 1.0-rc1 Reporter: Emmanuel Venisse Fix For: 1.0 The pb is the date/user/comment isn't populated -- 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-1276) Error in editing the Project name using spaces only
[ http://jira.codehaus.org/browse/CONTINUUM-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Teodoro Cue Jr. updated CONTINUUM-1276: --- Attachment: CONTINUUM-1276-continuum-webapp.patch Patch attached. The patch is dependent on the localization fix of CONTINUUM-1275. Error in editing the Project name using spaces only --- Key: CONTINUUM-1276 URL: http://jira.codehaus.org/browse/CONTINUUM-1276 Project: Continuum Issue Type: Bug Components: Web - UI Reporter: Teodoro Cue Jr. Priority: Minor Attachments: CONTINUUM-1276-continuum-webapp.patch Edit a Project in Continuum. Use only spaces in the Project Group Name instead of string. Then Save. This will generate an error: org.apache.maven.continuum.ContinuumException: unable to rename the project group Show/hide Stack Trace org.apache.maven.continuum.ContinuumException: unable to rename the project group at org.apache.maven.continuum.web.action.ProjectGroupAction.save(ProjectGroupAction.java:276) 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 com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:364) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:216) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:73) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:103) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:175) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:168) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188) at
[jira] Commented: (MRELEASE-106) Remember the Dry Run Status
[ http://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96263 ] Emmanuel Venisse commented on MRELEASE-106: --- I'm not sure it's a good idea, but don't know yet why. Remember the Dry Run Status --- Key: MRELEASE-106 URL: http://jira.codehaus.org/browse/MRELEASE-106 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Priority: Minor When doing a dry run of a release, make note of that in the release.properties file so that a reasonable failure can occur if the user tries to perform the release. Also, this flag might be used to allow a non-dry-run prepare to occur without needing to do a clean in between (maybe also not need to prompt but reuse the same answers as in the dry run). -- 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: (MANTLR-14) Allowing patterns in filename
[ http://jira.codehaus.org/browse/MANTLR-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MANTLR-14. - Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.0-beta-2 Applied. Thanks! Allowing patterns in filename - Key: MANTLR-14 URL: http://jira.codehaus.org/browse/MANTLR-14 Project: Maven 2.x Antlr Plugin Issue Type: Improvement Reporter: Emmanuel Lécharny Assignee: Vincent Siveton Priority: Minor Fix For: 2.0-beta-2 Attachments: pattern.diff It would be very cool to allow a user to add some patterns in the grammars list, instead of having to give every single name. Apache Directory Server project has more than 10 parsers to deal with, and the list becomes very long. Here is a patch which deal with this issue. You can mix filenames and pattern, the order won't be lost : For instance, here is what I'm using : grammarsfilter-value-lexer.g filter-lexer.g filter-lexer.g filter-value-parser.g filter-parser.g *.g/grammars The first files are kept as is, to avoid antlr failures, but the last one will eat all the remaining grammars. '*' and '?' are transformed to their regexp counterparts. A grammar which match more than one pattern won't be compile dtwice. Patch attached. -- 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-140) Tests fail during release:perform but work elsewhere
[
http://jira.codehaus.org/browse/MRELEASE-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96267
]
Emmanuel Venisse commented on MRELEASE-140:
---
ping
Tests fail during release:perform but work elsewhere
Key: MRELEASE-140
URL: http://jira.codehaus.org/browse/MRELEASE-140
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Environment: Maven 2.0.4. Linux
Reporter: Adrian
Priority: Blocker
Attachments: com.dolby.pics.core.ejb.bean.CountryBeanTestCase.txt,
perform-output, TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml,
WORKING-TEST-com.dolby.pics.core.ejb.bean.CountryBeanTestCase.xml
h2. Summary
I have a project that builds successfully when {{mvn clean install}} is
executed.
When {{mvn clean release:prepare}} is executed the integration tests run
successfully too.
When {{mvn release:perform}} is executed the junit tests using surefire fail.
h2. Details
h3. The project layout
The project is an EJB 3 project. The unit tests bootstrap/startup an embedded
EJB container to test the EJBs. The container is configured via a set of xml
and property files that are specified in the testResources section of the
pom. The embedded container is a dependency of the project with _test_ scope.
h3. release:perform output
The output of the release:perform goal is attached to this issue.
h3. surefire junit test report
The output of the release:perform goal is attached to this issue. A snippet
is shown here:
{code}
---
Battery: com.dolby.pics.core.ejb.bean.CountryBeanTestCase
---
Tests run: 11, Failures: 0, Errors: 11, Time elapsed: 7.234 sec
testGetAll(com.dolby.pics.core.ejb.bean.CountryBeanTestCase) Time elapsed:
2.255 sec ERROR!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
java.lang.RuntimeException: org.jboss.xb.binding.JBossXBRuntimeException:
Failed to create a new SAX parser
at
org.jboss.ejb3.embedded.EJB3StandaloneBootstrap.boot(EJB3StandaloneBootstrap.java:391)
at
com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:63)
at
com.dolby.pics.test.AbstractEJBTestCase.setUp(AbstractEJBTestCase.java:145)
at
com.dolby.pics.core.ejb.bean.CountryBeanTestCase.setUp(CountryBeanTestCase.java:43)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:228)
at junit.framework.TestSuite.run(TestSuite.java:223)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:242)
at
org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:216)
at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:215)
at org.apache.maven.surefire.Surefire.run(Surefire.java:163)
at org.apache.maven.surefire.Surefire.run(Surefire.java:87)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at
org.apache.maven.surefire.SurefireBooter.runTestsInProcess(SurefireBooter.java:313)
at org.apache.maven.surefire.SurefireBooter.run(SurefireBooter.java:221)
at org.apache.maven.test.SurefirePlugin.execute(SurefirePlugin.java:371)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
[jira] Commented: (MRELEASE-103) No SCM URL was provided to perform the release from
[ http://jira.codehaus.org/browse/MRELEASE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96268 ] Emmanuel Venisse commented on MRELEASE-103: --- Olivier, Can you reproduce it with 2.0-beta-5? No SCM URL was provided to perform the release from --- Key: MRELEASE-103 URL: http://jira.codehaus.org/browse/MRELEASE-103 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Environment: solaris Reporter: Olivier Lamy Priority: Blocker Attachments: olamy.tar.gz The stack trace says : DEBUG] Trace org.apache.maven.BuildFailureException: No SCM URL was provided to perform the release from at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor .java:555) I included a test case with multi modules project (you need to change scm url in all poms to complete the test). Strange because all scm parts are filled in all modules. To test it, I launch ./buildis.sh $svnuser $svnpwd Olivier -- 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-106) Remember the Dry Run Status
[ http://jira.codehaus.org/browse/MRELEASE-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96269 ] Mark Hobson commented on MRELEASE-106: -- It would be handy in the case of release:rollback: 1) mvn release:prepare -DdryRun=true 2) mvn release:rollback (2) would perform live SCM operations once MRELEASE-229 is fixed, if dryRun=true wasn't explicitly set. Storing dryRun in the release.properties would allow these second-phase goals to inherit the same environment. Remember the Dry Run Status --- Key: MRELEASE-106 URL: http://jira.codehaus.org/browse/MRELEASE-106 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Environment: Release plugin snapshot 20060509.101136-3, Subversion Reporter: Bob Allison Priority: Minor When doing a dry run of a release, make note of that in the release.properties file so that a reasonable failure can occur if the user tries to perform the release. Also, this flag might be used to allow a non-dry-run prepare to occur without needing to do a clean in between (maybe also not need to prompt but reuse the same answers as in the dry run). -- 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: (MRELEASE-215) mvn release:perform deploys an incomplete pom into repository.
[ http://jira.codehaus.org/browse/MRELEASE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-215. - Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 2.0-beta-5 I can't reproduce it and don't know how to reproduce it. If it always occurs, reopen the issue mvn release:perform deploys an incomplete pom into repository. -- Key: MRELEASE-215 URL: http://jira.codehaus.org/browse/MRELEASE-215 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: Windows XP, Java 1.05 Reporter: Marco Antonio Villalobos, Jr. Assignee: Emmanuel Venisse Priority: Blocker Fix For: 2.0-beta-5 Attachments: kineteque-jsf-1.0.5.pom, pom.xml I have had this problem in Maven 2.04, and Maven 2.0.6. My manager also had this problem independently. When using the mvn release:perform plugin, the pom that it posts into the repository is cut off somewhere in the middle, creating invalid xml, and furthermore, an invalid pom. Then, when another project that uses this dependency attempts to use this dependency, it cannot be resolved because the xml in the repository is wrong. I want to maven through a complete cycle test compile release. Attached is the project pom, and and the generated pom version 1.0.5 I would actually private project source if there is a guarantee that it would be kept private and my property. I consider this a stopper because I want to release my code, but now I cannot because of this bug unless I choose NOT to use Maven. But I love Maven, and I want to continue using it. -- 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: (MRELEASE-233) ScmCheckModificationsPhase ignores pom.xml
[ http://jira.codehaus.org/browse/MRELEASE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated MRELEASE-233: -- Assignee: Emmanuel Venisse Fix Version/s: 2.0-beta-6 ScmCheckModificationsPhase ignores pom.xml -- Key: MRELEASE-233 URL: http://jira.codehaus.org/browse/MRELEASE-233 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Emmanuel Venisse Fix For: 2.0-beta-6 Attachments: patch.txt Any local changes to pom.xmls are committed when using release:prepare. Such changes should be committed manually by the user before releasing to keep commits atomic. Thus pom.xml needs to be removed from the ScmCheckModificationsPhase exclusion list to fail the build under these circumstances. The attached patch removes pom.xml from the excluded files and realigns the tests accordingly. -- 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: (MRELEASE-178) Release prepare fails to update version information for ejb-client dependencies
[ http://jira.codehaus.org/browse/MRELEASE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated MRELEASE-178: -- Assignee: Emmanuel Venisse Fix Version/s: 2.0-beta-6 Release prepare fails to update version information for ejb-client dependencies --- Key: MRELEASE-178 URL: http://jira.codehaus.org/browse/MRELEASE-178 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Eric Bernstein Assignee: Emmanuel Venisse Fix For: 2.0-beta-6 Attachments: MRELEASE-178-similar-deps.patch, MRELEASE-178-similar-deps_rev_535938.patch If you use the dependency management section of a parent pom to include sub-poms of the same project, the release plugin will update the version number for those projects as part of the prepare phase. Unfortunately, if you have two dependencies with the same groupId and artifactId (as is the case with generated ejb-clients) prepare will just update one of them. I believe the problem in the code is in AbstractRewritePomsPhase.updateDomVersion. The code currently uses an xpath expression matching on groupId and artifactId and then calls xpath.getSingleNode to find the object to update. This will leave out one of the dependencies (either ejb or ejb-client). I'm having a little trouble writing a unit test for this (hence no patch upload), but if I could do that, I believe the fix would either be looping over the elements returned from the xpath expression, or altering the xpath expression (and the rest of the artifact handling - read: bigger change) to be more explicit about what artifacts it's looking at (including type, classifier, etc...). -- 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: (MSITE-221) Korean translation resource file
[ http://jira.codehaus.org/browse/MSITE-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MSITE-221. - Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.0 Applied Thanks Korean translation resource file Key: MSITE-221 URL: http://jira.codehaus.org/browse/MSITE-221 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-5 Environment: Korean language environment. Reporter: Woonsan Ko Assignee: Vincent Siveton Priority: Minor Fix For: 2.0 Attachments: site-plugin_ko.properties I added Korean language translation for maven-site-plugin according to the instruction. (http://maven.apache.org/plugins/maven-site-plugin/i18n.html) Of course, I'm happy with this after testing. :) Great project website! Thanks! -- 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: (MRELEASE-217) BUILD FAILURE: The version could not be updated: ${version}
[
http://jira.codehaus.org/browse/MRELEASE-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse closed MRELEASE-217.
-
Assignee: Emmanuel Venisse
Resolution: Fixed
Fix Version/s: 2.0-beta-6
Fixed in r.535828
BUILD FAILURE: The version could not be updated: ${version}
---
Key: MRELEASE-217
URL: http://jira.codehaus.org/browse/MRELEASE-217
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-5
Environment: XP Pro SP2
Reporter: David Hoffer
Assignee: Emmanuel Venisse
Priority: Critical
Fix For: 2.0-beta-6
Attachments: buildlog.txt, poms-for-release-plugin.zip
I manually built 2.0-beta-5 from maven-release-1 tag because of bug in
2.0-beta-4. I have found a problem using 2.0-beta-5 with a large
multi-module project which makes heavy use of ${version} macros. This macro
is used for the version for any dependency on modules within each module.
For example in one module where I have a dependency on 3 other modules I have
this:
dependencies
dependency
groupIdcom.xrite/groupId
artifactIdxdsiii-driver-api/artifactId
version${version}/version
/dependency
dependency
groupIdcom.xrite/groupId
artifactIdxdsiii-driver/artifactId
version${version}/version
/dependency
dependency
groupIdcom.xrite/groupId
artifactIdxdsiii-instrument-dtp22/artifactId
version${version}/version
/dependency
When I run the prepare phase I get the following error:
[INFO] Transforming 'X-Rite XDSIII Instrument Drivers'...
[INFO] Transforming 'X-Rite XDSIII Base Instrument'...
[INFO] Transforming 'X-Rite XDSIII DTP22 Instrument'...
[INFO] Updating xdsiii-instrument-base to 1.84
[ERROR] BUILD FAILURE
[INFO]
[INFO] The version could not be updated: ${version}
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: The version could not be updated:
${version}
It starts updating the poms with the new release version and then fails part
way through the process.
I will attach some files:
--
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-177) generateReleasePoms does not work
[ http://jira.codehaus.org/browse/MRELEASE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96276 ] Mark Hobson commented on MRELEASE-177: -- Sure, feel free to give me a shout. I'm still working on related issues within the release manager that using ranges have highlighted, but I'll raise these separately. generateReleasePoms does not work - Key: MRELEASE-177 URL: http://jira.codehaus.org/browse/MRELEASE-177 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Gabriele Contini Priority: Critical Attachments: MRELEASE-177-2.patch, MRELEASE-177.patch the goal release:prepare does not create the release poms. All the code is commented. This make impossible to reproduce build if you use version ranges. -- 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-177) generateReleasePoms does not work
[ http://jira.codehaus.org/browse/MRELEASE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96274 ] Emmanuel Venisse commented on MRELEASE-177: --- ok, I'll try to look at it before the 2.0-beta-6 release. Maybe I'll need to chat with you. generateReleasePoms does not work - Key: MRELEASE-177 URL: http://jira.codehaus.org/browse/MRELEASE-177 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Gabriele Contini Priority: Critical Attachments: MRELEASE-177-2.patch, MRELEASE-177.patch the goal release:prepare does not create the release poms. All the code is commented. This make impossible to reproduce build if you use version ranges. -- 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: (MPIR-64) Korean translation resource file
[ http://jira.codehaus.org/browse/MPIR-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-64. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Applied. Thanks! Korean translation resource file Key: MPIR-64 URL: http://jira.codehaus.org/browse/MPIR-64 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Affects Versions: 2.0.1 Environment: Korean language environment Reporter: Woonsan Ko Assignee: Vincent Siveton Priority: Minor Fix For: 2.1 Attachments: project-info-report_ko.properties I added Korean language translation for maven-project-info-reports-plugin according to the instruction. (http://maven.apache.org/plugins/maven-site-plugin/i18n.html) Of course, I'm happy with this after testing. :) Great project website! Thanks! -- 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-177) generateReleasePoms does not work
[ http://jira.codehaus.org/browse/MRELEASE-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96270 ] Mark Hobson commented on MRELEASE-177: -- It is a bit of a big patch, but it does solely address this issue. The main bulk comes from the resources used to test the release pom generation. The generate- and remove-release-poms phases have been implemented and the other phases only adjusted where necessary to cope with release-poms being present. I could try to break it up but the patch wouldn't be atomic. I'm happy to chat over the changes on IRC if that's easier? generateReleasePoms does not work - Key: MRELEASE-177 URL: http://jira.codehaus.org/browse/MRELEASE-177 Project: Maven 2.x Release Plugin Issue Type: Bug Reporter: Gabriele Contini Priority: Critical Attachments: MRELEASE-177-2.patch, MRELEASE-177.patch the goal release:prepare does not create the release poms. All the code is commented. This make impossible to reproduce build if you use version ranges. -- 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: (MRELEASE-233) ScmCheckModificationsPhase ignores pom.xml
[ http://jira.codehaus.org/browse/MRELEASE-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-233. - Resolution: Fixed Applied. Thanks. ScmCheckModificationsPhase ignores pom.xml -- Key: MRELEASE-233 URL: http://jira.codehaus.org/browse/MRELEASE-233 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Environment: Windows XP, Cygwin Reporter: Mark Hobson Assignee: Emmanuel Venisse Fix For: 2.0-beta-6 Attachments: patch.txt Any local changes to pom.xmls are committed when using release:prepare. Such changes should be committed manually by the user before releasing to keep commits atomic. Thus pom.xml needs to be removed from the ScmCheckModificationsPhase exclusion list to fail the build under these circumstances. The attached patch removes pom.xml from the excluded files and realigns the tests accordingly. -- 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: (MSITE-219) Slovak translation of site-plugin.properties
[ http://jira.codehaus.org/browse/MSITE-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96278 ] Vincent Siveton commented on MSITE-219: --- We need also the PIR properties to apply it. See http://maven.apache.org/plugins/maven-site-plugin/i18n.html Thanks Slovak translation of site-plugin.properties Key: MSITE-219 URL: http://jira.codehaus.org/browse/MSITE-219 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6, 2.0-beta-7 Reporter: Martin Vysny Priority: Minor Attachments: site-plugin_sk.properties Attached slovak translation of site-plugin.properties. I started to translate project-info-reports.properties aswell but I couldn't find out how to use it with the site plugin. -- 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: (MSITE-212) Catalan Language
[ http://jira.codehaus.org/browse/MSITE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96279 ] Vincent Siveton commented on MSITE-212: --- We need also the PIR properties to apply it. See http://maven.apache.org/plugins/maven-site-plugin/i18n.html Thanks Catalan Language Key: MSITE-212 URL: http://jira.codehaus.org/browse/MSITE-212 Project: Maven 2.x Site Plugin Issue Type: New Feature Reporter: Javier de Ros Attachments: site-plugin_ca.properties That's the Catalan language properties for the maven site plugin. -- 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-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96281 ] Sebastian Annies commented on CONTINUUM-1274: - I added some log to the AbstractRewritePomsPhase.java source: 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - We are about to write the pom 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - releaseDescriptor.isScmUseEditMode(): false 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - provider.requiresEditMode(): true 2007-05-18 14:52:46,186 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Okay let's make C:\svn\continuum\working-directory\1\pom.xml writable. -- Here we executeEditScmResult result = provider.edit(repository, new ScmFileSet(new File(releaseDescriptor.getWorkingDirectory()), pomFile)); 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Edit Files: [] 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Success: true 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Command Line: p4 -d C:\svn\continuum\working-directory\1 -u ** -P * edit pom.xml 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Command Output: null 2007-05-18 14:52:46,514 [pool-3-thread-1] ERROR ReleasePhase:rewrite-poms-for-release - Provider message: null Hmm - no command output. What happens in the perforceProvider. I'll check it out. Wait for more info Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at
[jira] Closed: (MPIR-62) [PATCH] Dependency File Details : set right justification for numeric columns
[ http://jira.codehaus.org/browse/MPIR-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-62. --- Assignee: Vincent Siveton Resolution: Fixed Applied. Thanks [PATCH] Dependency File Details : set right justification for numeric columns - Key: MPIR-62 URL: http://jira.codehaus.org/browse/MPIR-62 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Herve Boutemy Assignee: Vincent Siveton Priority: Minor Fix For: 2.1 Attachments: PIR-rigth_justification.patch rigth justification eases number reading -- 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: (MPIR-66) When run standalone, project metadata is missing
[ http://jira.codehaus.org/browse/MPIR-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MPIR-66. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Applied. Thanks! When run standalone, project metadata is missing Key: MPIR-66 URL: http://jira.codehaus.org/browse/MPIR-66 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Thomas Leonard Assignee: Vincent Siveton Fix For: 2.1 Attachments: project-info.patch When run directly with mvn project-info-reports:dependencies, the copyright field is blank. When run as part of 'mvn site', the field is filled in correctly from the pom.xml. The attached patch seems to fix the 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] Closed: (MRELEASE-178) Release prepare fails to update version information for ejb-client dependencies
[ http://jira.codehaus.org/browse/MRELEASE-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-178. - Resolution: Fixed Fixed. I didn't apply patches 1 or 2 but a mix of them because both was wrong. Release prepare fails to update version information for ejb-client dependencies --- Key: MRELEASE-178 URL: http://jira.codehaus.org/browse/MRELEASE-178 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Eric Bernstein Assignee: Emmanuel Venisse Fix For: 2.0-beta-6 Attachments: MRELEASE-178-similar-deps.patch, MRELEASE-178-similar-deps_rev_535938.patch If you use the dependency management section of a parent pom to include sub-poms of the same project, the release plugin will update the version number for those projects as part of the prepare phase. Unfortunately, if you have two dependencies with the same groupId and artifactId (as is the case with generated ejb-clients) prepare will just update one of them. I believe the problem in the code is in AbstractRewritePomsPhase.updateDomVersion. The code currently uses an xpath expression matching on groupId and artifactId and then calls xpath.getSingleNode to find the object to update. This will leave out one of the dependencies (either ejb or ejb-client). I'm having a little trouble writing a unit test for this (hence no patch upload), but if I could do that, I believe the fix would either be looping over the elements returned from the xpath expression, or altering the xpath expression (and the rest of the artifact handling - read: bigger change) to be more explicit about what artifacts it's looking at (including type, classifier, etc...). -- 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: (MRM-347) Undefined ${appserver.home} and ${appserver.base}
[
http://jira.codehaus.org/browse/MRM-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak updated MRM-347:
Description:
When I run:
mvn jetty:run
from trunk at r538691, the appserver.base property is undefined, resulting in
the creation of this directory:
Directory of C:\dev\apache-maven\archiva\archiva-web\archiva-webapp
05/17/2007 02:24 PMDIR ${appserver.base}
05/16/2007 11:40 AM14,681 pom.xml
05/16/2007 11:40 AMDIR src
05/17/2007 11:06 AMDIR target
was:
When I run:
mvn jetty:run
from trunk at r538691, the appserver.home property is undefined, resulting in
the creation of this directory:
Directory of C:\dev\apache-maven\archiva\archiva-web\archiva-webapp
05/17/2007 02:24 PMDIR ${appserver.base}
05/16/2007 11:40 AM14,681 pom.xml
05/16/2007 11:40 AMDIR src
05/17/2007 11:06 AMDIR target
Summary: Undefined ${appserver.home} and ${appserver.base} (was:
Undefined ${appserver.home} with mvn jetty:run)
I also have a c:/${appserver.home} directory created after starting Archiva.
I'm not yet sure if it's coming from 'mvn jetty:run' or the plexus runtime.
Undefined ${appserver.home} and ${appserver.base}
-
Key: MRM-347
URL: http://jira.codehaus.org/browse/MRM-347
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-alpha-1
Environment: Windows, Maven 2.0.6, JDK 5 or JDK 6
Reporter: Jan Nielsen
When I run:
mvn jetty:run
from trunk at r538691, the appserver.base property is undefined, resulting
in the creation of this directory:
Directory of C:\dev\apache-maven\archiva\archiva-web\archiva-webapp
05/17/2007 02:24 PMDIR ${appserver.base}
05/16/2007 11:40 AM14,681 pom.xml
05/16/2007 11:40 AMDIR src
05/17/2007 11:06 AMDIR target
--
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: (MRM-347) Undefined ${appserver.home} with mvn jetty:run
Undefined ${appserver.home} with mvn jetty:run
--
Key: MRM-347
URL: http://jira.codehaus.org/browse/MRM-347
Project: Archiva
Issue Type: Bug
Affects Versions: 1.0-alpha-1
Environment: Windows, Maven 2.0.6, JDK 5 or JDK 6
Reporter: Jan Nielsen
When I run:
mvn jetty:run
from trunk at r538691, the appserver.home property is undefined, resulting in
the creation of this directory:
Directory of C:\dev\apache-maven\archiva\archiva-web\archiva-webapp
05/17/2007 02:24 PMDIR ${appserver.base}
05/16/2007 11:40 AM14,681 pom.xml
05/16/2007 11:40 AMDIR src
05/17/2007 11:06 AMDIR target
--
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-2994) Snapshot repositories are not checked when using ranges
Snapshot repositories are not checked when using ranges --- Key: MNG-2994 URL: http://jira.codehaus.org/browse/MNG-2994 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.6 Environment: Windows XP, Cygwin Reporter: Mark Hobson Attachments: patch.txt The attached patch demonstrates the problem by adding it0121. If the test repository has releases enabled, the test passes, when they are disabled, the test fails. This appears to be due to DefaultArtifact.isSnapshot returning false for unresolved ranges, thus causing snapshot repositories to be disabled when resolving artifacts. -- 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-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96294 ] Sebastian Annies commented on CONTINUUM-1274: - Logging should be improved. I have to debug everything, cause logging doesn't log enough Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- 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: (MANT-22) Make it possible to run the package target without tests
[ http://jira.codehaus.org/browse/MANT-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MANT-22: --- Fix Version/s: (was: 2.0) 2.1 Make it possible to run the package target without tests Key: MANT-22 URL: http://jira.codehaus.org/browse/MANT-22 Project: Maven 2.x Ant Plugin Issue Type: Improvement Affects Versions: 2.0-beta-1 Environment: Gentoo Linux Reporter: Petteri Räty Fix For: 2.1 Attachments: maven-ant-plugin-dist-target.patch When packaging stuff for Gentoo linux it is our packaging policy to give the user the choice whether he/she wants to run the unit tests or not. Nowadays as quite a few projects only use maven as their build system we use ant:ant to generate build.xml files and do your packaging using that (at least until we can get maven to properly build from source and integrate repositories to our system etc. which has proved not so easy). The problem with the generated build.xml files is that it always forces the tests for the package target. For this reason I wrote a patch that changes the default target to dist that just depends on the package and test targets. -- 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-1551) Upload org.hibernate:hibernate:jar:3.2.4.sp1 to ibiblio
Upload org.hibernate:hibernate:jar:3.2.4.sp1 to ibiblio --- Key: MAVENUPLOAD-1551 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1551 Project: maven-upload-requests Issue Type: Task Reporter: Craig Condit http://dsmhub01.prod.phx1.secureserver.net/maven/hibernate-3.2.4.sp1-bundle.jar http://www.hibernate.org/ Relational Persistence for Java 3.2.4.SP1 has been released to fix a serious bug with IDENTITY column handling which was introduced in 3.2.4.GA. -- 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: (MRELEASE-227) release:perform fails when using Perforce
[ http://jira.codehaus.org/browse/MRELEASE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse closed MRELEASE-227. - Assignee: Emmanuel Venisse Resolution: Fixed Fix Version/s: 2.0-beta-6 Patrick, I fixed it. Can you verify it works for Perforce now? release:perform fails when using Perforce - Key: MRELEASE-227 URL: http://jira.codehaus.org/browse/MRELEASE-227 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Maven 2.0.6 Reporter: Patrick Schneider Assignee: Emmanuel Venisse Priority: Minor Fix For: 2.0-beta-6 The Perforce provider requires edit mode when changing files that are under source control. After a successful release:prepare, the release:perform goal fails. It looks like RestoreBackupPomsPhase tries a FileUtils.copyFile, disregarding whether the SCM requires this or not -- it then fails b/c the POM is readonly at this point. -- 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: (SCM-317) Add edit and unedit commands
[ http://jira.codehaus.org/browse/SCM-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Venisse updated SCM-317: - Fix Version/s: 1.x Add edit and unedit commands Key: SCM-317 URL: http://jira.codehaus.org/browse/SCM-317 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-cvs Reporter: Emmanuel Venisse Fix For: 1.x -- 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-189) Release with CVS SCM failed when Checkout is read-only
[ http://jira.codehaus.org/browse/MRELEASE-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96300 ] Emmanuel Venisse commented on MRELEASE-189: --- The edit command must be implemented in Maven-SCM Release with CVS SCM failed when Checkout is read-only -- Key: MRELEASE-189 URL: http://jira.codehaus.org/browse/MRELEASE-189 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-3 Environment: CVS 2.5.03 jdk * Reporter: Christophe Lallement Priority: Critical When we use the goal release:perform, the plugins try to update the pom.xml Bug we use CVS with checkout in read-only mode (by setting the variable CVSREAD to 1) It seems that the plugins do not try to do a cvs edit before updating the file. So the update file because the file is read only. Christophe -- 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-317) Add edit and unedit commands
Add edit and unedit commands Key: SCM-317 URL: http://jira.codehaus.org/browse/SCM-317 Project: Maven SCM Issue Type: New Feature Components: maven-scm-provider-cvs Reporter: Emmanuel Venisse Fix For: 1.x -- 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: (MRM-348) Create a buildable source distribution
Create a buildable source distribution -- Key: MRM-348 URL: http://jira.codehaus.org/browse/MRM-348 Project: Archiva Issue Type: Task Components: build Affects Versions: 0.9, 1.0 Reporter: Wendy Smoak Archiva should have a source distribution. Use the assembly plugin to construct the equivalent of zipping up a svn export. Also, LICENSE and NOTICE need to be in svn at the top. -- 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: (MRELEASE-103) No SCM URL was provided to perform the release from
[ http://jira.codehaus.org/browse/MRELEASE-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-103. - Resolution: Fixed Fix Version/s: 2.0-beta-5 I can't reproduce it with 2.0-beta-5. No SCM URL was provided to perform the release from --- Key: MRELEASE-103 URL: http://jira.codehaus.org/browse/MRELEASE-103 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Environment: solaris Reporter: Olivier Lamy Priority: Blocker Fix For: 2.0-beta-5 Attachments: olamy.tar.gz The stack trace says : DEBUG] Trace org.apache.maven.BuildFailureException: No SCM URL was provided to perform the release from at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor .java:555) I included a test case with multi modules project (you need to change scm url in all poms to complete the test). Strange because all scm parts are filled in all modules. To test it, I launch ./buildis.sh $svnuser $svnpwd Olivier -- 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-1552) Upload mysql:mysql-connector-java:jar:5.0.6 to ibiblio
Upload mysql:mysql-connector-java:jar:5.0.6 to ibiblio -- Key: MAVENUPLOAD-1552 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1552 Project: maven-upload-requests Issue Type: Task Reporter: Matt Whitlock http://www.mattwhitlock.com/mysql-connector-java-5.0.6-bundle.jar http://dev.mysql.com/downloads/connector/j/5.0.html MySQL Connector/J is the official 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-1545) JexcelAPI 2.6.3 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96307 ] Carlos Sanchez commented on MAVENUPLOAD-1545: - I suggest you to create your own repo and we'll sync, then you guys can take care as you want http://maven.apache.org/guides/mini/guide-central-repository-upload.html JexcelAPI 2.6.3 Upload -- Key: MAVENUPLOAD-1545 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1545 Project: maven-upload-requests Issue Type: Task Reporter: Kevin Conaway Assignee: Carlos Sanchez Attachments: jxl-2.6.3-bundle.jar, jxl-2.6.3-bundle.jar I am not a developer of this project. The repository bundle is attached. The administrators of this project do not care to move to Maven but we depend on this project. The project URL is: http://jexcelapi.sourceforge.net Alternatively, please install the latest version from here: http://sourceforge.net/project/showfiles.php?group_id=79926 Thanks, Kevin -- 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: (MCLOVER-78) Excludes should not take higher presedence than includes
Excludes should not take higher presedence than includes Key: MCLOVER-78 URL: http://jira.codehaus.org/browse/MCLOVER-78 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Mike Youngstrom Fix For: 2.5 If I do: includes include**/somefile.java/include /includes excludes exclude**/*.java/exclude /excludes Then it appears no files get instrumented. I think the include and exclude rules should work the same way they do with the surefire plugin where includes have a higher precedence than excludes -- 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-78) Excludes should not take higher presedence than includes
[ http://jira.codehaus.org/browse/MCLOVER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96308 ] Mike Youngstrom commented on MCLOVER-78: The example should read: includes include**/somefile.java/include /includes excludes exclude**/*.java/exclude /excludes Excludes should not take higher presedence than includes Key: MCLOVER-78 URL: http://jira.codehaus.org/browse/MCLOVER-78 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Mike Youngstrom Fix For: 2.5 If I do: includes include**/somefile.java/include /includes excludes exclude**/*.java/exclude /excludes Then it appears no files get instrumented. I think the include and exclude rules should work the same way they do with the surefire plugin where includes have a higher precedence than excludes -- 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-78) Excludes should not take higher presedence than includes
[ http://jira.codehaus.org/browse/MCLOVER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96309 ] Mike Youngstrom commented on MCLOVER-78: Well, nevermind my '*'s are getting escaped. :) Trust me it is correct. Excludes should not take higher presedence than includes Key: MCLOVER-78 URL: http://jira.codehaus.org/browse/MCLOVER-78 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.4 Reporter: Mike Youngstrom Fix For: 2.5 If I do: includes include**/somefile.java/include /includes excludes exclude**/*.java/exclude /excludes Then it appears no files get instrumented. I think the include and exclude rules should work the same way they do with the surefire plugin where includes have a higher precedence than excludes -- 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: (MRELEASE-227) release:rollback fails when using Perforce
[ http://jira.codehaus.org/browse/MRELEASE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Schneider updated MRELEASE-227: --- Description: The Perforce provider requires edit mode when changing files that are under source control. After a successful release:prepare, the release:rollback goal fails. It looks like RestoreBackupPomsPhase tries a FileUtils.copyFile, disregarding whether the SCM requires this or not -- it then fails b/c the POM is readonly at this point. (was: The Perforce provider requires edit mode when changing files that are under source control. After a successful release:prepare, the release:perform goal fails. It looks like RestoreBackupPomsPhase tries a FileUtils.copyFile, disregarding whether the SCM requires this or not -- it then fails b/c the POM is readonly at this point.) Summary: release:rollback fails when using Perforce (was: release:perform fails when using Perforce) Corrected the title and description. release:rollback fails when using Perforce -- Key: MRELEASE-227 URL: http://jira.codehaus.org/browse/MRELEASE-227 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Maven 2.0.6 Reporter: Patrick Schneider Assignee: Emmanuel Venisse Priority: Minor Fix For: 2.0-beta-6 The Perforce provider requires edit mode when changing files that are under source control. After a successful release:prepare, the release:rollback goal fails. It looks like RestoreBackupPomsPhase tries a FileUtils.copyFile, disregarding whether the SCM requires this or not -- it then fails b/c the POM is readonly at this point. -- 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-227) release:rollback fails when using Perforce
[ http://jira.codehaus.org/browse/MRELEASE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96327 ] Patrick Schneider commented on MRELEASE-227: Works great Emmanuel -- thanks! release:rollback fails when using Perforce -- Key: MRELEASE-227 URL: http://jira.codehaus.org/browse/MRELEASE-227 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: Maven 2.0.6 Reporter: Patrick Schneider Assignee: Emmanuel Venisse Priority: Minor Fix For: 2.0-beta-6 The Perforce provider requires edit mode when changing files that are under source control. After a successful release:prepare, the release:rollback goal fails. It looks like RestoreBackupPomsPhase tries a FileUtils.copyFile, disregarding whether the SCM requires this or not -- it then fails b/c the POM is readonly at this point. -- 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-116) [regression] Test-resources not on classpath in forkMode always
[ http://jira.codehaus.org/browse/SUREFIRE-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96330 ] Jonathon Golden commented on SUREFIRE-116: -- Hi, I tried applying Will's patch to the 2.3.1 code base and it did not solve this problem for me, however if I run my tests with Junit4 this class loader bug goes away. Perhaps the solution to the bug in the Junit3 provider can be found in the code for the Junit4 provider? [regression] Test-resources not on classpath in forkMode always --- Key: SUREFIRE-116 URL: http://jira.codehaus.org/browse/SUREFIRE-116 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.0 (2.2 plugin) Reporter: Geoffrey De Smet Fix For: 2.4 Attachments: JUnitTestSet.patch Before surefire plugin 2.2 at spring-richclient: - our build succeeded - ValidationResultsTests worked - testFailureIgnoretrue/testFailureIgnore due to an unrelated testcase: HandlerTest - forkModepertest/forkMode Since 2.2: - our build failes - ValidtorResultTests failed too - while it's still testFailureIgnoretrue/testFailureIgnore (how can it fail in that case?) - forkModepertest/forkMode or forkModealways/forkMode (same result) The entire discussion (with stacktraces etc) on the user list is here: http://article.gmane.org/gmane.comp.jakarta.turbine.maven.user/45131 -- 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-113) docletPath not working in 2.2 - Cannot find doclet class ydoc.doclets.YStandard
[ http://jira.codehaus.org/browse/MJAVADOC-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96331 ] Greg Luck commented on MJAVADOC-113: Hi I am trying to test this. What repository and version number do I need to use? I tried 2.3-SNAPSHOT and SNAPSHOT but neither resolved. What repo do I need? Greg docletPath not working in 2.2 - Cannot find doclet class ydoc.doclets.YStandard --- Key: MJAVADOC-113 URL: http://jira.codehaus.org/browse/MJAVADOC-113 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Greg Luck I have two projects which use the javadoc plugin. Ehcache and JPam. Both started giving this error in the last few days: [INFO] Velocity successfully started. [INFO] [javadoc:javadoc] [WARNING] No docletpath option was found. Please review docletpath/ or docletArtifact/ or doclets/. 1 error [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) 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: An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages at org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:230) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1200) at org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:128) at org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:216) ... 18 more [INFO] [INFO] Total time: 18 seconds [INFO] Finished at: Sun Feb 25 09:48:18 EST 2007 [INFO] Final Memory: 9M/17M
[jira] Commented: (MJAVADOC-113) docletPath not working in 2.2 - Cannot find doclet class ydoc.doclets.YStandard
[ http://jira.codehaus.org/browse/MJAVADOC-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96332 ] Carlos Sanchez commented on MJAVADOC-113: - pluginRepositories pluginRepository idapache.snapshots/id nameApache Snapshot Repository/name urlhttp://people.apache.org/repo/m2-snapshot-repository/url releases enabledfalse/enabled /releases /pluginRepository /pluginRepositories docletPath not working in 2.2 - Cannot find doclet class ydoc.doclets.YStandard --- Key: MJAVADOC-113 URL: http://jira.codehaus.org/browse/MJAVADOC-113 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Greg Luck I have two projects which use the javadoc plugin. Ehcache and JPam. Both started giving this error in the last few days: [INFO] Velocity successfully started. [INFO] [javadoc:javadoc] [WARNING] No docletpath option was found. Please review docletpath/ or docletArtifact/ or doclets/. 1 error [INFO] [ERROR] BUILD ERROR [INFO] [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) 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: An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages at org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:230) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.apache.maven.reporting.MavenReportException: Exit code: 1 - javadoc: error - Cannot find doclet class ydoc.doclets.YStandard Command line was:/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/javadoc -J-Xmx512m -J-Xms128m @options @packages at org.apache.maven.plugin.javadoc.AbstractJavadocMojo.executeReport(AbstractJavadocMojo.java:1200) at org.apache.maven.plugin.javadoc.JavadocReport.generate(JavadocReport.java:128) at org.apache.maven.plugin.javadoc.JavadocReport.execute(JavadocReport.java:216) ... 18 more [INFO]
[jira] Issue Comment Edited: (CONTINUUM-1274) Release Project fails due to pom.xml not writable with perforce as SCM
[ http://jira.codehaus.org/browse/CONTINUUM-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96294 ] Sebastian Annies edited comment on CONTINUUM-1274 at 5/18/07 7:01 PM: -- Logging should be improved. I have to debug everything, cause logging doesn't log enough (or at least debug log level is disabled and I got no idea how to enable) was: Logging should be improved. I have to debug everything, cause logging doesn't log enough Release Project fails due to pom.xml not writable with perforce as SCM -- Key: CONTINUUM-1274 URL: http://jira.codehaus.org/browse/CONTINUUM-1274 Project: Continuum Issue Type: Bug Components: Integration - Maven 2, SCM Affects Versions: 1.1-alpha-1 Environment: ubunto 7.04 java 6 Reporter: Sebastian Annies Priority: Critical All release steps from update-working-copy to map-development-versions work fine. The next phase ' rewrite-poms-for-release' fails because of read-only pom.xml. this could be an issue with the scmUseEdit flag since perforce file are read-only by default. see log output: (I tried to fix alpha-2 by myself therfor log output is alpha2-SNAPSHOT, error reproduces with alpha-1, too) [INFO] Updating local copy against the scm... [INFO] Verifying that there are no local modifications... [INFO] Checking dependencies and plugins for snapshots ... [ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Error writing POM: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:659) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:604) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:190) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:115) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:98) at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) at org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107) at org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43) at org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:619) Caused by: java.io.FileNotFoundException: /home/drmtest/continuum-1.1-alpha-2-SNAPSHOT/continuum-webapp/src/main/webapp/WEB-INF/working-directory/1/pom.xml (Permission denied) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at java.io.FileWriter.init(FileWriter.java:73) at org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.writePom(AbstractRewritePomsPhase.java:640) ... 14 more -- 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: (MANTLR-17) Support for Antlr 3
[ http://jira.codehaus.org/browse/MANTLR-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96333 ] David Holroyd commented on MANTLR-17: - Phew! I only created the last release of the plugin a couple of days ago : ) I've committed some changes to address, * the license * code style * ANTLR 3.0-final dependency I also created some simple unit tests, but they don't test very much at the moment. Any ideas when ANTLR 3.0 will get pushed to the repositories? Note that the 3.0 release [already listed|http://repo1.maven.org/maven2/org/antlr/antlr/] appears to be bugus (dates from January this year). Also, the project is now shipping separate 'runtime' and 'tool' jars -- I have some [proposed POMs|http://svn.badgers-in-foil.co.uk/maven-antlr3-plugin/maven-antlr3-plugin/trunk/src/site/apt/install.apt] to reflect this split. Support for Antlr 3 --- Key: MANTLR-17 URL: http://jira.codehaus.org/browse/MANTLR-17 Project: Maven 2.x Antlr Plugin Issue Type: Wish Reporter: Brian Hanafee Antlr 3.0 is a major rewrite of ANTLR. It's not clear whether the right approach would be to upgrade this plug-in or to write a new plug-in. There is a (partial) [workaround using the antrun plugin|http://www.antlr.org/wiki/display/ANTLR3/Using+ANTLR+3+with+Maven+2]. -- 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
