[jira] Commented: (MNG-4555) mvn archetype:generate -o (offline) still results in a "checking updates from central"
[ http://jira.codehaus.org/browse/MNG-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208764#action_208764 ] Matthew McCullough commented on MNG-4555: - I'm almost freaked out that we submitted (yours is more detailed, of course) almost the identical issue just minutes apart. ;-) I'm willing to accept closure of mine as a dupe. > mvn archetype:generate -o (offline) still results in a "checking updates from > central" > -- > > Key: MNG-4555 > URL: http://jira.codehaus.org/browse/MNG-4555 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-6 > Environment: Mac OSX 10.6.2, Mvn 3.0-alpha-6 >Reporter: Matthew McCullough > Fix For: 3.0-alpha-7 > > > When I invoke an archetype in offline mode (-o) I still get a info message > stating central is being checked. > > mvn archetype:generate -o > ... > Choose a number: 17 > ... > [INFO] artifact org.apache.maven.archetypes:maven-archetype-webapp: checking > for updates from central > I don't believe this is a forceful call coming from the archetype, but rather > something requested from core. Nonetheless, shouldn't Maven's core always > block calls that would reach to central when in offline mode? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4555) mvn archetype:generate -o (offline) still results in a "checking updates from central"
[ http://jira.codehaus.org/browse/MNG-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4555: -- Fix Version/s: 3.0-alpha-7 > mvn archetype:generate -o (offline) still results in a "checking updates from > central" > -- > > Key: MNG-4555 > URL: http://jira.codehaus.org/browse/MNG-4555 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0-alpha-6 > Environment: Mac OSX 10.6.2, Mvn 3.0-alpha-6 >Reporter: Matthew McCullough > Fix For: 3.0-alpha-7 > > > When I invoke an archetype in offline mode (-o) I still get a info message > stating central is being checked. > > mvn archetype:generate -o > ... > Choose a number: 17 > ... > [INFO] artifact org.apache.maven.archetypes:maven-archetype-webapp: checking > for updates from central > I don't believe this is a forceful call coming from the archetype, but rather > something requested from core. Nonetheless, shouldn't Maven's core always > block calls that would reach to central when in offline mode? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208759#action_208759 ] Brett Porter commented on WAGON-297: I'm a bit confused by it. - the multiple levels of try/catch is a bit scary - the checkOut call that fails with a TransferFailedException seems to be called identically after calculating the missing directories. Am I misreading it? - it might be nice to have a block comment that explains what happens (are the directories added in the local checkout, created, remotely, etc? Is it checking out a new base directory higher up to create the directories?) - also, you want to make sure you don't start creating directories within the original supplied URL - wagon doesn't do that, only create those that it tries to put within that. Separately - is the test case one that is valid across all the providers? Maybe it can be pushed up to the abstract class? > Wagon SCM does not automatically create missing directories during deployment > - > > Key: WAGON-297 > URL: http://jira.codehaus.org/browse/WAGON-297 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-scm >Affects Versions: 1.0-beta-6 >Reporter: Maria Odea Ching > Attachments: WAGON-297.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4555) mvn archetype:generate -o (offline) still results in a "checking updates from central"
mvn archetype:generate -o (offline) still results in a "checking updates from central" -- Key: MNG-4555 URL: http://jira.codehaus.org/browse/MNG-4555 Project: Maven 2 & 3 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 3.0-alpha-6 Environment: Mac OSX 10.6.2, Mvn 3.0-alpha-6 Reporter: Matthew McCullough When I invoke an archetype in offline mode (-o) I still get a info message stating central is being checked. > mvn archetype:generate -o ... Choose a number: 17 ... [INFO] artifact org.apache.maven.archetypes:maven-archetype-webapp: checking for updates from central I don't believe this is a forceful call coming from the archetype, but rather something requested from core. Nonetheless, shouldn't Maven's core always block calls that would reach to central when in offline mode? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4554) [regression] plugin updates are requested on every build regardless of policies
[
http://jira.codehaus.org/browse/MNG-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-4554:
--
Fix Version/s: 3.0-alpha-7
> [regression] plugin updates are requested on every build regardless of
> policies
> ---
>
> Key: MNG-4554
> URL: http://jira.codehaus.org/browse/MNG-4554
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Plugins and Lifecycle
>Affects Versions: 3.0-alpha-6
>Reporter: Brett Porter
> Fix For: 3.0-alpha-7
>
>
> I'm not sure if this is an intentional change that I've missed or not, but
> running something like:
> {code}
> mvn archetype:generate
> {code}
> will retrieve the metadata from the repository on every build:
> {code}
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
> 9 KB downloaded at 17.1 KB/sec
> {code}
> This is in contrast to Maven 2.2.1 which always continues to use the first
> version encountered until you use -U:
> {code:xml}
>
>
>
> never
>
> {code}
> While that remains in the super POM of Maven 3, it seems that the metadata is
> retrieved regardless.
--
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-4554) [regression] plugin updates are requested on every build regardless of policies
[regression] plugin updates are requested on every build regardless of policies
---
Key: MNG-4554
URL: http://jira.codehaus.org/browse/MNG-4554
Project: Maven 2 & 3
Issue Type: Bug
Components: Artifacts and Repositories, Plugins and Lifecycle
Affects Versions: 3.0-alpha-6
Reporter: Brett Porter
I'm not sure if this is an intentional change that I've missed or not, but
running something like:
{code}
mvn archetype:generate
{code}
will retrieve the metadata from the repository on every build:
{code}
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
9 KB downloaded at 17.1 KB/sec
{code}
This is in contrast to Maven 2.2.1 which always continues to use the first
version encountered until you use -U:
{code:xml}
never
{code}
While that remains in the super POM of Maven 3, it seems that the metadata is
retrieved regardless.
--
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-514) release:branch hit remoteTagging problem
[
http://jira.codehaus.org/browse/MRELEASE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208752#action_208752
]
Benson Margulies commented on MRELEASE-514:
---
I don't think so. I started with a clean, up'ed, working copy, ran mvn, and got
what I reported.
> release:branch hit remoteTagging problem
>
>
> Key: MRELEASE-514
> URL: http://jira.codehaus.org/browse/MRELEASE-514
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.0-beta-9
>Reporter: Benson Margulies
>
> I ran:
> mvn release:branch -DbranchName=rlp_7.1
> and got ...
> {noformat}
> [INFO] Working directory: /Users/benson/x/rex2009-trunk/java
> org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
> branch SCM
> Provider message:
> The svn branch command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
> already exists
> at
> org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
> at
> org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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:597)
> 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)
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to branch SCM
> Provider message:
> The svn branch command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
> already exists
> {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: (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&focusedCommentId=208747#action_208747
]
Stephen Connolly commented on MRELEASE-140:
---
Have you tried changing forkMode on surefire... by default forkMode will be
none, which means that if the release plugin is pulling in extra classes, they
will still be in the JVM (even if classworlds keeps them on a separate
classloader)
> 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
> Components: prepare
>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.DefaultPlug
[jira] Commented: (MRELEASE-514) release:branch hit remoteTagging problem
[
http://jira.codehaus.org/browse/MRELEASE-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208746#action_208746
]
Stephen Connolly commented on MRELEASE-514:
---
Did you have a mixed revision working copy?
I have seen this type of issue just creating tags using svn directly.
If you modify files locally, commit just those files and then do an svn cp
without doing an svn update first, then you can end up with the above issue.
If this is a case of a mixed revision working copy, then there may not be an
easy way to fix this, we could force an svn update, but that might be counter
to what the user is trying to do, e.g. they may want to branch from their
working copy... which has some files updated to HEAD while others have not been
updated (because the update would break the code)
> release:branch hit remoteTagging problem
>
>
> Key: MRELEASE-514
> URL: http://jira.codehaus.org/browse/MRELEASE-514
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: branch
>Affects Versions: 2.0-beta-9
>Reporter: Benson Margulies
>
> I ran:
> mvn release:branch -DbranchName=rlp_7.1
> and got ...
> {noformat}
> [INFO] Working directory: /Users/benson/x/rex2009-trunk/java
> org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to
> branch SCM
> Provider message:
> The svn branch command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
> already exists
> at
> org.apache.maven.shared.release.phase.ScmBranchPhase.execute(ScmBranchPhase.java:98)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379)
> at
> org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350)
> at
> org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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:597)
> 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)
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to branch SCM
> Provider message:
> The svn branch command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: File '/engineering/rex2009/branches/rlp_7.1/annotatortools/pom.xml'
> already exists
> {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: (MRELEASE-492) The svn tag command failed
[
http://jira.codehaus.org/browse/MRELEASE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208745#action_208745
]
Stephen Connolly commented on MRELEASE-492:
---
What version of SVN are you using on the client and the server side.
Did the release continue correctly after executing
svn update
mvn release:prepare
as (for those of us in Europe making releases on the apache svn server, the
sync process can cause a fail similar to what you are seeing which can be
resolved by svn update followed by continuing the release:prepare)?
> The svn tag command failed
> --
>
> Key: MRELEASE-492
> URL: http://jira.codehaus.org/browse/MRELEASE-492
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.0-beta-9
> Environment: ubuntu 9.04 ,
> Apache Maven 2.1.0 (r755702; 2009-03-19 00:40:27+0530)
> Java version: 1.6.0_13
> Java home: /usr/lib/jvm/java-6-sun-1.6.0.13/jre
> Default locale: en_IN, platform encoding: UTF-8
> OS name: "linux" version: "2.6.28-15-server" arch: "i386" Family: "unix"
>Reporter: Sridher Jakku
>
> when i run the mvn release:prepare this error comming
> [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.584
> sec
> [INFO] Running com.ipleanty.accure.module.orm.AppTest
> [INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018
> sec
> [INFO]
> [INFO] Results :
> [INFO]
> [INFO] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> [INFO] [INFO] [antrun:run {execution: default}]
> [INFO] [INFO] Executing tasks
> [INFO] [echo]
>
> [INFO] [echo] r2093 | js | 2009-10-13 20:02:29 +0530 (Tue, 13 Oct 2009)
> [INFO] [echo]
>
> [INFO] [echo] Your orm Revision number : 2073
> [INFO] [INFO] Executed tasks
> [INFO] [INFO] [jar:jar]
> [INFO] [INFO] Building jar: /home/sridher/maven/svn/orm/target/orm-0.7.jar
> [INFO] [INFO]
>
> [INFO] [INFO] BUILD SUCCESSFUL
> [INFO] [INFO]
>
> [INFO] [INFO] Total time: 26 seconds
> [INFO] [INFO] Finished at: Tue Oct 13 20:03:30 IST 2009
> [INFO] [INFO] Final Memory: 25M/114M
> [INFO] [INFO]
>
> [INFO] Checking in modified POMs...
> [INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm && svn --username
> js --password '*' --non-interactive commit --file
> /tmp/maven-scm-327676631.commit --targets
> /tmp/maven-scm-7485856893453511468-targets
> [INFO] Working directory: /home/sridher/maven/svn/orm
> [INFO] Tagging release with the label orm-0.7...
> [INFO] Executing: /bin/sh -c cd /home/sridher/maven/svn/orm && svn --username
> js --password '*' --non-interactive copy --file
> /tmp/maven-scm-895863680.commit .
> scm:svn:svn://192.168.1.10/Accure/orm/tags/orm-0.7
> [INFO] Working directory: /home/sridher/maven/svn/orm
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> [INFO] Unable to tag SCM
> Provider message:
> The svn tag command failed.
> Command output:
> svn: Local, non-commit operations do not take a log message or revision
> properties
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 41 seconds
> [INFO] Finished at: Tue Oct 13 20:03:32 IST 2009
> [INFO] Final Memory: 12M/119M
> [INFO]
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-293) Unable to deploy SNAPSHOT vesion using sftp in remote location
[
http://jira.codehaus.org/browse/WAGON-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208739#action_208739
]
Olaf Fricke commented on WAGON-293:
---
We encountered a very similar error lately after a patch was installed on our
solaris server.
I tracked down the problem to the class
{{org.apache.maven.wagon.providers.ssh.jsch.ScpWagon}}: when trying to lookup
the file {{.../maven-metadata.xml}} for any *new* snapshot version the method
{{fillInputData}} detects the error code {{1}} and then validates the error
message to contain the text {{No such file or directory}}. Only then a
{{ResourceDoesNotExistException}} will be thrown, indicating that the requested
file does not exist.
Unfortunately, the error messages are returned in german since the solaris
patch has been installed ({{Datei oder Verzeichnis existiert nicht}}).
Therefore an {{IOException}} will be thrown instead of the
{{ResourceDoesNotExistException}}. This will stop the deployment of the new
snapshot version immediately.
We are still working on a solution. In the meantime we have to create target
directories, {{maven-metadata.xml}} files, and {{maven-metadata.xml.sha1}}
files manually as workaround. Very, very anoying.
> Unable to deploy SNAPSHOT vesion using sftp in remote location
> --
>
> Key: WAGON-293
> URL: http://jira.codehaus.org/browse/WAGON-293
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
> Environment: C:\MavenTest\dhe>mvn -version
> Apache Maven 2.2.1 (r801777; 2009-08-07 00:46:01+0530)
> Java version: 1.5.0
> Java home: C:\Program Files\IBM\Java50\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86"
> Famil
> y: "dos"
>Reporter: Dherendra Singh
> Attachments: pom.xml, sftp_deploy_error.txt
>
>
> I am unable to deploy vesion with SNAPSHOT in my remote location using sftp.
> here error is attached in .txt format.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-631) [Maven 3] Integration test project-44 fails with Unable to resolve resource location: /checkstyle-config.xml
[ http://jira.codehaus.org/browse/MECLIPSE-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MECLIPSE-631. -- Resolution: Fixed Fix Version/s: 2.8 Assignee: Benjamin Bentmann Fixed in [r905109|http://svn.apache.org/viewvc?view=revision&revision=905109] by updating to plexus-resources:1.0-alpha-6 which contains the actual fix and retains full compat with existing POMs. > [Maven 3] Integration test project-44 fails with Unable to resolve resource > location: /checkstyle-config.xml > > > Key: MECLIPSE-631 > URL: http://jira.codehaus.org/browse/MECLIPSE-631 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Environment: Using Java version: 1.6 > Apache Maven 3.0-alpha-5 (r883378; 2009-11-23 10:53:41-0500) > Java version: 1.6.0_17 > Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home > Default locale: en_US, platform encoding: MacRoman > OS name: "mac os x" version: "10.5.8" arch: "x86_64" Family: "mac" >Reporter: Peter Lynch >Assignee: Benjamin Bentmann > Fix For: 2.8 > > Attachments: MECLIPSE-631.patch > > > project-44 integration test fails due to MNG-4514 when using Maven 3.0-alpha-5 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 1.309s > [INFO] Finished at: Sun Jan 03 19:19:58 EST 2010 > [INFO] Final Memory: 4M/264M > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) on > project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-eclipse-plugin:test:eclipse (default-cli) > on project maven-eclipse-plugin-test-project-44: Unable to resolve resource > location: /checkstyle-config.xml > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:570) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:317) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:245) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:102) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:423) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:158) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:123) > 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:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) > Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to resolve > resource location: /checkstyle-config.xml > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeAdditionalConfig(EclipsePlugin.java:1200) > at > org.apache.maven.plugin.eclipse.EclipsePlugin.writeConfiguration(EclipsePlugin.java:1141) > at > org.apache.maven.plugin.ide.AbstractIdeSupportMojo.execute(AbstractIdeSupportMojo.java:511) > at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:105) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:562) > ... 14 more > [ERROR] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-379) Regression: title block isn't parsed in APT file if comment is present before it
[ http://jira.codehaus.org/browse/DOXIA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIA-379. --- Resolution: Fixed Assignee: Herve Boutemy fixed in r905092 > Regression: title block isn't parsed in APT file if comment is present before > it > > > Key: DOXIA-379 > URL: http://jira.codehaus.org/browse/DOXIA-379 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Apt >Affects Versions: 1.1.2 >Reporter: Marat Radchenko >Assignee: Herve Boutemy > Fix For: 1.1.3 > > > I recently updated to maven-site-plugin-2.1 (which pulled doxia-1.1.2) and > suddenly page > title block stopped working. > My apt file [1] (didn't change it) now renders as [2]. > Notice no page title and ugly "-- About -- Marat Radchenko -- > 2009-04-09" line at top of page. > Page starts to render correctly if title block is but before commented > license banner, so it becomes a first element. > [1] > http://autodao.git.sourceforge.net/git/gitweb.cgi?p=autodao/autodao;a=blob;f=src/site/apt/index.apt;h=cda99c5a0500b657162c2ac7f6419df334c41771;hb=HEAD#l17 > [2] http://autodao.sourceforge.net/index.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-467) Sharing assembly descriptor across sub modules does not work if invoked from parent project - bad resolve of the classpath
Sharing assembly descriptor across sub modules does not work if invoked from
parent project - bad resolve of the classpath
--
Key: MASSEMBLY-467
URL: http://jira.codehaus.org/browse/MASSEMBLY-467
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-5
Environment: Winfows7, Maven 2.2.1, Sun JDK1.6.0_u18
Reporter: Kek
Attachments: build-log.txt
My problem is similar to http://jira.codehaus.org/browse/MASSEMBLY-391, but in
my opinion it is BUG, not request for new feature.
I have project structure like:
module
submodule-1
submodule-2
my-assembly-descriptor-submodule
The submodule-1 and submodule-2 use the shared my-assembly-descriptor-submodule
to produce attached zip-artifact with configuration files.
The creation of the zip-artifact is defined on parent module by use of assembly
plugin.
maven-assembly-plugin
2.2-beta-5
org.mymodule
my-assembly-descriptor-submodule
${project.version}
zip-config
package
single
config-assembly.xml
Everything works fine, when I install the shared assembly-descriptor to local
repository and run the "mvn clean package" separately in submodule-1 and
submodule-2.
But when I try to run the same command in parent module, than the build fails -
the config-assembly.xml is not found on classpath.
[INFO] Error reading assemblies: Error locating assembly descriptor:
config-assembly.xml
[1] [INFO] Searching for file location:
D:\mymodule\submodule-1\config-assembly.xml
[2] [INFO] File: D:\mymodule\submodule-1\config-assembly.xml does not exist.
[3] [INFO] Invalid artifact specification: 'config-assembly.xml'. Must contain
at least three fields, separated by ':'.
[4] [INFO] Failed to resolve classpath resource: assemblies/config-assembly.xml
from classloader: org.codehaus.classworlds.realmclassloa...@11a75a2
[5] [INFO] Failed to resolve classpath resource: config-assembly.xml from
classloader: org.codehaus.classworlds.realmclassloa...@11a75a2
[6] [INFO] File: D:\mymodule\config-assembly.xml does not exist.
[7] [INFO] Building URL from location: config-assembly.xml
Error:
java.net.MalformedURLException: no protocol: config-assembly.xml
at java.net.URL.(URL.java:567)
at java.net.URL.(URL.java:464)
at java.net.URL.(URL.java:413)
at
org.apache.maven.shared.io.location.URLLocatorStrategy.resolve(URLLocatorStrategy.java:54)
at org.apache.maven.shared.io.location.Locator.resolve(Locator.java:81)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.addAssemblyFromDescriptor(DefaultAssemblyReader.java:309)
at
org.apache.maven.plugin.assembly.io.DefaultAssemblyReader.readAssemblies(DefaultAssemblyReader.java:140)
at
org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:352)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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:597)
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.j
[jira] Created: (MNG-4553) Plugins artifact filtering should use full Artifact identification instead only ArtifactId
Plugins artifact filtering should use full Artifact identification instead only ArtifactId -- Key: MNG-4553 URL: http://jira.codehaus.org/browse/MNG-4553 Project: Maven 2 & 3 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.2.1 Environment: Windows7, Sun JDK 1.6.0_u18 Reporter: Kek I created common module with some abstract parents and Helpers for our Mojos. I named the module as "maven-plugin-api", but the groupId was "org.mycompany.maven". Than I create "my-maven-plugin" that depends on this common library "org.mycompany.maven:maven-plugin-api". When I try to use the MyMavenPlugin, I get the following message: [DEBUG] The following artifacts were filtered out for plugin: org.mycompany.maven:my-maven-plugin:1.0.0-SNAPSHOT because they're already in the core of Maven: active project artifact: artifact = org.mycompany.maven:maven-plugin-api:jar:1.0.0-SNAPSHOT:runtime; project: MavenProject: org.mycompany.maven:maven-plugin-api:1.0.0-SNAPSHOT These will use the artifact files already in the core ClassRealm instead, to allow them to be included in PluginDescriptor.getArtifacts(). And than build fails with Caused by: java.lang.ClassNotFoundException: org.mycompany.maven.mojo.AbstractProjectMojo at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 52 more After some investigation I found the workaround for this problem - I must rename the shared module "org.mycompany.maven:maven-plugin-api" to ""org.mycompany.maven:MY-maven-plugin-api" so I can not use the artifactId like "maven-plugin-api" because it is already used for core maven modules and therefore my library was filtered out. But this is not correct behaviour, because the artifactId was the same, but the groupId was different. In my opinion the maven should use the full-id during the Artifact comparation and filtering. -- 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: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-85. --- Resolution: Fixed Patch applied, thanks. A new snapshot of the upcoming 2.4.1 is also available. > ejb-client dependencies should be placed in defaultLibBundleDir > --- > > Key: MEAR-85 > URL: http://jira.codehaus.org/browse/MEAR-85 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3.1 >Reporter: James Olsen >Assignee: Stephane Nicoll > Fix For: 2.4.1 > > Attachments: MEAR-85-ashipilev-TESTS.patch, MEAR-85-ashipilev-v1.patch > > > ejb-client jars should be placed in the defaultLibBundleDir when specified. > They're just standard jar dependencies not J2EE artifacts so should be > treated the same as other jars. They're currently being placed in the root > directory. > A workaround is to add an ejbClientModule entry to override the bundleDir: > > > ... > ... > lib > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=208723#action_208723 ] Stephane Nicoll edited comment on MEAR-85 at 1/31/10 8:56 AM: -- okay, due to the number of votes and since we seems to have a working solution that fit, I'll review and apply the patches in the upcoming version. was (Author: sni): okay, due to the number of votes and a working solution that seems to fit to anyone, I'll review and apply the patches in the upcoming version. > ejb-client dependencies should be placed in defaultLibBundleDir > --- > > Key: MEAR-85 > URL: http://jira.codehaus.org/browse/MEAR-85 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3.1 >Reporter: James Olsen >Assignee: Stephane Nicoll > Fix For: 2.4.1 > > Attachments: MEAR-85-ashipilev-TESTS.patch, MEAR-85-ashipilev-v1.patch > > > ejb-client jars should be placed in the defaultLibBundleDir when specified. > They're just standard jar dependencies not J2EE artifacts so should be > treated the same as other jars. They're currently being placed in the root > directory. > A workaround is to add an ejbClientModule entry to override the bundleDir: > > > ... > ... > lib > > -- 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] Work started: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MEAR-85 started by Stephane Nicoll. > ejb-client dependencies should be placed in defaultLibBundleDir > --- > > Key: MEAR-85 > URL: http://jira.codehaus.org/browse/MEAR-85 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3.1 >Reporter: James Olsen >Assignee: Stephane Nicoll > Fix For: 2.4.1 > > Attachments: MEAR-85-ashipilev-TESTS.patch, MEAR-85-ashipilev-v1.patch > > > ejb-client jars should be placed in the defaultLibBundleDir when specified. > They're just standard jar dependencies not J2EE artifacts so should be > treated the same as other jars. They're currently being placed in the root > directory. > A workaround is to add an ejbClientModule entry to override the bundleDir: > > > ... > ... > lib > > -- 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: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
[ http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-85: Priority: Major (was: Minor) Fix Version/s: (was: 2.5) 2.4.1 Issue Type: Bug (was: Improvement) okay, due to the number of votes and a working solution that seems to fit to anyone, I'll review and apply the patches in the upcoming version. > ejb-client dependencies should be placed in defaultLibBundleDir > --- > > Key: MEAR-85 > URL: http://jira.codehaus.org/browse/MEAR-85 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.3.1 >Reporter: James Olsen >Assignee: Stephane Nicoll > Fix For: 2.4.1 > > Attachments: MEAR-85-ashipilev-TESTS.patch, MEAR-85-ashipilev-v1.patch > > > ejb-client jars should be placed in the defaultLibBundleDir when specified. > They're just standard jar dependencies not J2EE artifacts so should be > treated the same as other jars. They're currently being placed in the root > directory. > A workaround is to add an ejbClientModule entry to override the bundleDir: > > > ... > ... > lib > > -- 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: (MPDF-38) Allow selective report inclusion
Allow selective report inclusion Key: MPDF-38 URL: http://jira.codehaus.org/browse/MPDF-38 Project: Maven 2.x PDF Plugin Issue Type: Improvement Reporter: Dominik Bartholdi It would be a big enhancement to allow selective report inclusion to the final PDF. I know there is the flag 'includeReports', but this is a "all or nothing" flag. There are many reports quite interessting for a web report, but some of theme just don't make sence within the PDF because it is just to omutch data for some endusers (e.g. dependency). But on the other hand there are reports needed by some managers (e.g. project-team). -- 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
