[jira] Closed: (SCM-339) Need documentation on how to configure path to ss.exe for VSS provider
[ http://jira.codehaus.org/browse/SCM-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-339. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1.1 patch applied in [r691442|http://svn.apache.org/viewvc?rev=691442&view=rev]. Thanks! > Need documentation on how to configure path to ss.exe for VSS provider > -- > > Key: SCM-339 > URL: http://jira.codehaus.org/browse/SCM-339 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-site >Affects Versions: 1.0 > Environment: N/A >Reporter: Allan Lang >Assignee: Vincent Siveton > Fix For: 1.1.1 > > Attachments: SCM-339-maven-scm-site.patch > > > The Maven SCM website currently has no information on how to set the path of > the ss.exe executable for use by the VSS provider. This should be added. -- 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: (SCM-404) tgit scm:update does not have TCK Test yet
[ http://jira.codehaus.org/browse/SCM-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-404. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: (was: 1.x) 1.1.1 Patch applied in [r691439|http://svn.apache.org/viewvc?rev=691439&view=rev] Since I am not using git, could you test it? > tgit scm:update does not have TCK Test yet > -- > > Key: SCM-404 > URL: http://jira.codehaus.org/browse/SCM-404 > Project: Maven SCM > Issue Type: Test > Components: maven-scm-provider-git >Affects Versions: 1.1 >Reporter: Mark Struberg >Assignee: Vincent Siveton > Fix For: 1.1.1 > > Attachments: GitExeUpdateTck.patch > > > The maven-scm-provider-gitexe currently does not have the TCK test for the > update command. > The attachment contains the necessary patch to enable the TCK. > Please do not activate this TCK unless we improved the 'update' command to > pass TCK! -- 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: (SCM-408) Support the CVSNT "sserver" protocol
[
http://jira.codehaus.org/browse/SCM-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-408.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1.1
Fixed in [r691433|http://svn.apache.org/viewvc?rev=691433&view=rev]
Please try it since I am not using this protocol.
> Support the CVSNT "sserver" protocol
>
>
> Key: SCM-408
> URL: http://jira.codehaus.org/browse/SCM-408
> Project: Maven SCM
> Issue Type: Improvement
> Components: maven-scm-provider-cvs
>Affects Versions: 1.0
> Environment: windows server 2003, cvsnt 2.5.03, maven 2.0.9, tomcat,
> hudson
>Reporter: cory bestgen
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
>
> When setting the scm developerConnection like the following i get an error
> that the "sserver" protocol is invalid.
> {code}
>
>
>
> scm:cvs:sserver:cvsserver:/bigrepo:myproject
> HEAD
> http://cvsserver/ViewVC/viewvc.cgi/myproject/
>
> {code}
> The "sserver" protocol is a valid when using cvsnt(pserver over ssl).
> I have set the "-Dmaven.scm.provider.cvs.implementation=cvs_native" in the
> mvn.bat and still get the following error.
> {code}
> java.lang.IllegalArgumentException: This SCM url
> 'scm:cvs:sserver:cvsserver:/bigrepo:commons/myproject' is invalid due to the
> following errors:
> * Unknown transport: sserver
> For more information about SCM URL Format, please refer to:
> http://maven.apache.org/scm/scm-url-format.html
> at
> org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.getScmRepository(ScmReport.java:720)
> at
> org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderBody(ScmReport.java:223)
> at
> org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
> at
> org.apache.maven.report.projectinfo.ScmReport.executeReport(ScmReport.java:124)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> 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)
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-395) Plugin tests are failing due to a wrong local repository path.
[
http://jira.codehaus.org/browse/MECLIPSE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=126609#action_126609
]
aheritier edited comment on MECLIPSE-395 at 9/2/08 6:25 PM:
--
My fix breaks the build if those properties aren't set. Maven complains about
'$/{org.apache.maven.user-settings/}' references itself.
{code}
testMyEclipseProject01(org.apache.maven.plugin.eclipse.MyEclipsePluginTest)
Time elapsed: 11.46 sec <<< ERROR!
org.apache.maven.shared.test.plugin.TestToolsException: Error building
MavenProject instance from test pom:
/Users/arnaud/Development/Maven/Code/m2-trunks/plugins/maven-eclipse-plugin/pom-test.xml
at
org.apache.maven.shared.test.plugin.ProjectTool.packageProjectArtifact(ProjectTool.java:238)
at
org.apache.maven.shared.test.plugin.PluginTestTool.prepareForTesting(PluginTestTool.java:181)
at
org.apache.maven.shared.test.plugin.PluginTestTool.preparePluginForUnitTestingWithMavenBuilds(PluginTestTool.java:121)
at
org.apache.maven.plugin.eclipse.AbstractEclipsePluginTestCase.setUp(AbstractEclipsePluginTestCase.java:137)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)
Caused by: org.apache.maven.project.InvalidProjectModelException: The POM
expression: ${org.apache.maven.user-settings} could not be evaluated. Reason:
Expression value '${org.apache.maven.user-settings}' references itself in
'org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:test'. for project
org.apache.maven.plugins:maven-eclipse-plugin at
/Users/arnaud/Development/Maven/Code/m2-trunks/plugins/maven-eclipse-plugin/pom-test.xml
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:803)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:476)
at
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197)
at
org.apache.maven.shared.test.plugin.ProjectTool.packageProjectArtifact(ProjectTool.java:223)
... 24 more
Caused by: org.apache.maven.project.interpolation.ModelInterpolationException:
The POM expression: ${org.apache.maven.user-settings} could not be evaluated.
Reason: Expression value '${org.apache.maven.user-settings}' references itself
in 'org.apache.maven.plugins:maven-eclipse-plugin:maven-plugin:test'.
at
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolateInternal(RegexBasedModelInterpolator.java:172)
at
org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(RegexBasedModelInterpolator.java:98)
at
org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:937)
at
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:799)
... 27 more
{code}
was (Author: aheritier):
My fix breaks the build if those properties aren't set. Maven complains
about '${org.apache.maven.user-settings}' references itself.
{code}
testMyEclipseProject01(org.apache.maven.plugin.eclipse.MyEclipsePluginTest)
Time elapsed: 11.46 sec <<< ERROR!
org.apache.maven.shared.test.plugin.TestToolsExceptio
[jira] Closed: (MECLIPSE-200) Please add support for the AJDT plugin
[ http://jira.codehaus.org/browse/MECLIPSE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-200. Resolution: Fixed Fixed and snapshot 2.6-20080902.232029-1 deployed. If you can test it > Please add support for the AJDT plugin > -- > > Key: MECLIPSE-200 > URL: http://jira.codehaus.org/browse/MECLIPSE-200 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.2 >Reporter: Eric Berry >Assignee: Arnaud Heritier > Fix For: 2.6 > > Attachments: ajdt.patch, maven-eclipse-plugin.zip, > maven-eclipse-plugin.zip > > > Please add support for the AJDT plugin. > I have modified the eclipse plugin for our site with the needed changes. I > have attached the modifications that I made for someone to look at and > incorporate into the 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] Closed: (MECLIPSE-313) AJDT feature
[ http://jira.codehaus.org/browse/MECLIPSE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-313. Assignee: Arnaud Heritier Resolution: Fixed Fix Version/s: 2.5.2 Fixed with MECLIPSE-200 > AJDT feature > > > Key: MECLIPSE-313 > URL: http://jira.codehaus.org/browse/MECLIPSE-313 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support > Environment: Windows / Linux >Reporter: Cyril JOUI >Assignee: Arnaud Heritier >Priority: Minor > Fix For: 2.5.2 > > Attachments: EclipsePlugin.java > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > This feature adds configuration parameters for project which use AspectJ > Compiler. > It is a current preview version. I will go on my work this week ... > To use it, add -Dajdtversion=1.5 (currently tested version of this plugin). > Changes made on EclipsePlugin.java -- 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-270) Add support for classpathentry attributes
[ http://jira.codehaus.org/browse/MECLIPSE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-270. Assignee: Arnaud Heritier Resolution: Fixed Fix Version/s: 2.5.2 Fixed with MECLIPSE-200 > Add support for classpathentry attributes > - > > Key: MECLIPSE-270 > URL: http://jira.codehaus.org/browse/MECLIPSE-270 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.3 >Reporter: Mike Youngstrom >Assignee: Arnaud Heritier > Fix For: 2.5.2 > > > With eclipse 3.3 and AJDT 1.5 aspect jars are now configured as an attribute > nested inside of the .classpath file's element Like so: > path="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5.jar" > > sourcepath="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5-sources.jar"> > > > > > It would be nice if it were possible to add attributes to classpathentry's > with some kind of configuration syntax where maybe the dependency artifact > and group are specified and then the attributes for that dependency. > Mike -- 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-102) Preparation goals 'clean integration-test' not sufficient for plugin-projects
[ http://jira.codehaus.org/browse/MRELEASE-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-102. - Resolution: Duplicate > Preparation goals 'clean integration-test' not sufficient for plugin-projects > - > > Key: MRELEASE-102 > URL: http://jira.codehaus.org/browse/MRELEASE-102 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-3, 2.0-beta-4 >Reporter: Jens Zastrow > > A multi-project build: > root >L Project-A (plugin) >L Project-B (jar) (B uses A as plugin) > To successfully build such a project-structure phase 'install' has to be > called - at least for the project A - to ensure there exists a plugin in the > local repository with the correct name/group and VERSION wich is used during > the same build from project B. -- 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-292) during release:prepare, if one of the goals specified in preparationGoals fails, the release:prepare should abort/fail, but it continues along as if nothing bad happened
[ http://jira.codehaus.org/browse/MRELEASE-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-292. - Resolution: Fixed I think if you have upgraded your maven, you shouldn't have the issue. If not please reopen the issue. > during release:prepare, if one of the goals specified in preparationGoals > fails, the release:prepare should abort/fail, but it continues along as if > nothing bad happened > - > > Key: MRELEASE-292 > URL: http://jira.codehaus.org/browse/MRELEASE-292 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Ian Springer > > In my case, I specified "clean install" as the value of preparationGoals. One > of my unit tests failed, which caused the "mvn clean install" to fail, but > release:prepare continued on and tagged the release as if nothing had gone > wrong during the prep goals... -- 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-300) Regression: release:prepare fails for svn
[ http://jira.codehaus.org/browse/MRELEASE-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-300. - Resolution: Won't Fix > Regression: release:prepare fails for svn > - > > Key: MRELEASE-300 > URL: http://jira.codehaus.org/browse/MRELEASE-300 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: scm >Affects Versions: 2.0-beta-7 > Environment: Windows, M205, JDK 1.4.2, svn 1.4.2 >Reporter: Joerg Schaible >Priority: Blocker > > After the upgrade to 2.0-beta-7 from 2.0-beta-6 the release:prepare fails at > the last step: > == %< === > $ mvn release:prepare > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'release'. > [INFO] > > [INFO] Building Elsag Master Project > [INFO]task-segment: [release:prepare] (aggregator-style) > [INFO] > > [INFO] [release:prepare] > [INFO] Resuming release from phase 'scm-commit-release' > [INFO] Checking in modified POMs... > [INFO] Executing: svn --non-interactive commit --file > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-84899240.commit --targets > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-13397-targets > [INFO] Working directory: D:\work\standard\master-pom > [INFO] Tagging release with the label v_117... > [INFO] Executing: svn --non-interactive copy --file > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-1381395764.commit . > http://websvn/svn/essvn/development/buildsystem/maven-2/master-pom/tags/v_117 > [INFO] Working directory: D:\work\standard\master-pom > [INFO] Transforming 'Elsag Master Project'... > [INFO] Not removing release POMs > [INFO] Checking in modified POMs... > [INFO] Executing: svn --non-interactive commit --file > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-1672780400.commit --targets > c:\DOKUME~1\jos\LOKALE~1\Temp\maven-scm-13398-targets > [INFO] Working directory: D:\work\standard\master-pom > [INFO] > > [ERROR] BUILD FAILURE > [INFO] > > [INFO] Unable to commit files > Provider message: > The svn command failed. > Command output: > svn: Commit succeeded, but other errors follow: > svn: Error bumping revisions post-commit (details follow): > svn: In directory 'D:\work\standard\master-pom' > svn: Error processing command 'committed' in 'D:\work\standard\master-pom' > svn: Error replacing text-base of 'pom.xml' > svn: Can't move 'D:\work\standard\master-pom\.svn\tmp\pom.xml.tmp' to > 'D:\work\standard\master-pom\pom.xml': Zugriff verweigert > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 21 seconds > [INFO] Finished at: Tue Nov 27 11:59:30 CET 2007 > [INFO] Final Memory: 5M/10M > [INFO] > > == %< === > After switching back to 2.0.-beta-6, the step works flawlessly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-238) release:prepare hangs at cvs update
[ http://jira.codehaus.org/browse/MRELEASE-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146752#action_146752 ] Olivier Lamy commented on MRELEASE-238: --- do you have same issue with 2.0-beta-7 ? > release:prepare hangs at cvs update > --- > > Key: MRELEASE-238 > URL: http://jira.codehaus.org/browse/MRELEASE-238 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Lothar Hegebart >Priority: Blocker > > release:prepare just hangs indefinitely, no more information given by -X and > -e > when i define version 2.0-beta-5 as plugin version it works just fine -- 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-330) target release:prepare fails for multiproject if cross project dependencies exist
[ http://jira.codehaus.org/browse/MRELEASE-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-330. - Assignee: Olivier Lamy Resolution: Duplicate > target release:prepare fails for multiproject if cross project dependencies > exist > - > > Key: MRELEASE-330 > URL: http://jira.codehaus.org/browse/MRELEASE-330 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-7 > Environment: Maven version: 2.0.8 > Java version: 1.5.0_13 > OS name: "mac os x" version: "10.4.11" arch: "i386" Family: "unix" >Reporter: Lars Sonchocky-Helldorf >Assignee: Olivier Lamy >Priority: Blocker > Attachments: AvE24All.zip, release.out.txt > > > We got a multiproject with cross dependencies to release. The structure is > like this: > AvE24All > | > +- Applications > | | > | +- AvE24 > | | > | \- AvE24Backoffice > | > +- Frameworks > | | > | \- AvE24Data > | > +- Static > | | > | \- www.ave24.de > | > \- WebServices >| >\- AvE24WS > Each subproject contains a correlative pom.xml which declare the cross > dependencies: > The AvE24 and AvE24Backoffice subprojects both depend on AvE24Data and > AvE24WS subprojects > (see also AvE24All.zip attachment, which contains the bare bone (just pom.xml > files) multiproject ) > While all the "easy" targets (clean, install, deploy) work for me > release:prepare fails because the freshly build cross dependencies are only > inside the target folder and not yet in some repository: > mac-mini-lars:~/Documents/workspace/AvE24All lars$ mvn --batch-mode > release:prepare > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Unnamed - assense.ave24:ave24-all-parent:pom:1.2.8-SNAPSHOT > [INFO] Unnamed - assense.ave24:WebServices:pom:1.2.8-SNAPSHOT > [INFO] AvE24WS > [INFO] Unnamed - assense.ave24:Frameworks:pom:1.2.8-SNAPSHOT > [INFO] Unnamed - assense.ave24:AvE24Data:woframework:1.2.8-SNAPSHOT > [INFO] Unnamed - assense.ave24:Applications:pom:1.2.8-SNAPSHOT > [INFO] Unnamed - assense.ave24:AvE24:woapplication:1.2.8-SNAPSHOT > [INFO] Unnamed - assense.ave24:AvE24Backoffice:woapplication:1.2.8-SNAPSHOT > [INFO] Unnamed - assense.ave24:Static:pom:1.2.8-SNAPSHOT > [INFO] Unnamed - assense.ave24:www.ave24.de:jar:1.2.8-SNAPSHOT > . > . > . > [INFO] Working directory: /Users/lars/Documents/workspace/AvE24All > [INFO] Checking dependencies and plugins for snapshots ... > [INFO] Transforming 'Unnamed - > assense.ave24:ave24-all-parent:pom:1.2.8-SNAPSHOT'... > [INFO] Transforming 'Unnamed - > assense.ave24:WebServices:pom:1.2.8-SNAPSHOT'... > [INFO] Transforming 'AvE24WS'... > [INFO] Transforming 'Unnamed - assense.ave24:Frameworks:pom:1.2.8-SNAPSHOT'... > [INFO] Transforming 'Unnamed - > assense.ave24:AvE24Data:woframework:1.2.8-SNAPSHOT'... > [INFO] Transforming 'Unnamed - > assense.ave24:Applications:pom:1.2.8-SNAPSHOT'... > [INFO] Transforming 'Unnamed - > assense.ave24:AvE24:woapplication:1.2.8-SNAPSHOT'... > [INFO] Updating AvE24Data to 1.2.8 > [INFO] Updating AvE24WS to 1.2.8 > [INFO] Transforming 'Unnamed - > assense.ave24:AvE24Backoffice:woapplication:1.2.8-SNAPSHOT'... > [INFO] Updating AvE24Data to 1.2.8 > [INFO] Updating AvE24WS to 1.2.8 > [INFO] Transforming 'Unnamed - assense.ave24:Static:pom:1.2.8-SNAPSHOT'... > [INFO] Transforming 'Unnamed - > assense.ave24:www.ave24.de:jar:1.2.8-SNAPSHOT'... > [INFO] Not generating release POMs > [INFO] Executing goals 'clean verify'... > [INFO] Executing: mvn clean verify --no-plugin-updates --batch-mode -P > assense.default,assense.default > [INFO] Scanning for projects... > [INFO] Reactor build order: > [INFO] Unnamed - assense.ave24:ave24-all-parent:pom:1.2.8 > [INFO] Unnamed - assense.ave24:WebServices:pom:1.2.8 > [INFO] AvE24WS > [INFO] Unnamed - assense.ave24:Frameworks:pom:1.2.8 > [INFO] Unnamed - assense.ave24:AvE24Data:woframework:1.2.8 > [INFO] Unnamed - assense.ave24:Applications:pom:1.2.8 > [INFO] Unnamed - assense.ave24:AvE24:woapplication:1.2.8 > [INFO] Unnamed - assense.ave24:AvE24Backoffice:woapplication:1.2.8 > [INFO] Unnamed - assense.ave24:Static:pom:1.2.8 > [INFO] Unnamed - assense.ave24:www.ave24.de:jar:1.2.8 > [INFO] > > [INFO] Building Unnamed - assense.ave24:ave24-all-parent:pom:1.2.8 > [INFO]task-segment: [clean, verify] > . > . > . > [INFO] > > [INFO] Building AvE24WS > [INFO]task-segment: [clean, verify] > [INFO] >
[jira] Closed: (MRELEASE-268) Release is broken with Subversion 1.3.x and earlier
[ http://jira.codehaus.org/browse/MRELEASE-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MRELEASE-268. - Assignee: Olivier Lamy Resolution: Fixed Fix Version/s: 2.0-beta-8 fix upgrade to scm 1.1 > Release is broken with Subversion 1.3.x and earlier > --- > > Key: MRELEASE-268 > URL: http://jira.codehaus.org/browse/MRELEASE-268 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Max Bowsher >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 2.0-beta-8 > > > Due to breakage in maven-scm, the release plugin is broken when used with > Subversion 1.3.x and earlier - see SCM-320. Since the version of maven-scm in > use is explicitly determined by the maven-release-plugin dependencies, I'm > filing this issue to link the progress of SCM-320 to the release-plugin > release planning. > I'm filing at Priority=Blocker, since this is a regression over 2.0-beta-5. -- 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: (MCLEAN-36) filesets with an absolute path directory are ignored when !project.isExecutionRoot()
filesets with an absolute path directory are ignored when
!project.isExecutionRoot()
Key: MCLEAN-36
URL: http://jira.codehaus.org/browse/MCLEAN-36
Project: Maven 2.x Clean Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: Will Horn
Attachments: mvn-test.zip
Due to the fix for http://jira.codehaus.org/browse/MCLEAN-27, mvn clean will
not delete a fileset with a directory represented by an absolute path when run
from a parent directory. Instead it will automatically prepend the project
directory path to the absolute path and silently do nothing after not find the
directory. The logic responsible is in
http://svn.apache.org/viewvc/maven/plugins/tags/maven-clean-plugin-2.2/src/main/java/org/apache/maven/plugin/clean/CleanMojo.java?revision=594869&view=markup
getLog().info( "Deleting " + fileset );
if ( !project.isExecutionRoot() )
{
String projectBasedir = StringUtils.replace(
project.getBasedir().getAbsolutePath(), "\\", "/" );
String filesetDir = StringUtils.replace(
fileset.getDirectory(), "\\", "/" );
if ( filesetDir.indexOf( projectBasedir ) == -1 )
{
fileset.setDirectory( projectBasedir + "/" +
filesetDir );
}
}
fileSetManager.delete( fileset );
The issue can be seen in the attached test project. If a directory c:\mvntemp
exists, then "mvn clean" from the base directory will not delete it. "mvn
clean" from inside subproject will work since project.isExecutionRoot() is true
and the above logic is not executed.
--
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: (MCLEAN-27) fileset directory does not work as expected when cleaning "modules" in sub-directories
[
http://jira.codehaus.org/browse/MCLEAN-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146734#action_146734
]
Will Horn commented on MCLEAN-27:
-
Note that this fix breaks absolute directory paths. I had to look through the
source code to find that if you are not in the project directory, the plugin
silently prepends the project directory to the specified directory.
> fileset directory does not work as expected when cleaning "modules" in
> sub-directories
> --
>
> Key: MCLEAN-27
> URL: http://jira.codehaus.org/browse/MCLEAN-27
> Project: Maven 2.x Clean Plugin
> Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Jacob Robertson
>Assignee: Vincent Siveton
> Fix For: 2.2
>
>
> Following the example given on the plugin site, I used a fileset with a
> directory like so.
> {code}
>
> maven-clean-plugin
>
>
>
>
> src/main/application
>
>
> *.jar
>
>
>
>
>
> {code}
> I did this, or a variation on it, to several projects. I then created a
> parent pom in the directory above those projects, added them as modules in
> that pom, and ran "mvn clean" expecting to have those specified directories
> cleaned for me (of all jar files). However, it did not work. To get it to
> work, I had to prefix my directories with ${basedir}, for example
> "${basedir}/src/main/application".
> If this is the desired behavior, I recommend adding one sentence to the
> documentation to explain this.
--
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: (MCLEAN-31) Always resolve relative path against the project's base directory
[
http://jira.codehaus.org/browse/MCLEAN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146733#action_146733
]
Will Horn commented on MCLEAN-31:
-
Is there a reason why absolute paths are not addressed? In my case, I need to
delete a directory with absolute path stored in a custom ${} parameter. The
build creates the directory and clean should remove it.
I've found that "mvn clean" works when I am in the project dir, but due to the
MCLEAN-27 fix, it fails when run from a parent dir.
> Always resolve relative path against the project's base directory
> -
>
> Key: MCLEAN-31
> URL: http://jira.codehaus.org/browse/MCLEAN-31
> Project: Maven 2.x Clean Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Benjamin Bentmann
> Attachments: clean.zip, relative-paths.patch, relative-paths.patch
>
>
> Relative paths - which are often used by users for plugin configuration in
> the POM - must always be resolved against the base directory of the current
> project. By always I mean not just when run in a reactor build.
> Attached is a patch to fix the mojo as well as a mini project to reveal the
> bug. Just unpack the project, change your working directory to the parent
> folder of its base directory or any other directory that does not contain the
> POM and run Maven on the test POM from this working directory using its -f
> switch. The plugin will not delete the "test-target" directory in the project
> base directory but instead delete an equally named directory in the current
> working directory.
--
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: (MASSEMBLY-73) Sharing a default assembly descriptor across sub modules
[ http://jira.codehaus.org/browse/MASSEMBLY-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146728#action_146728 ] Grégory Joseph commented on MASSEMBLY-73: - ha, excellent, works indeed and is simpler. The documentation for descriptorRefs doesn't make this obvious, tho. Thanks ! > Sharing a default assembly descriptor across sub modules > > > Key: MASSEMBLY-73 > URL: http://jira.codehaus.org/browse/MASSEMBLY-73 > Project: Maven 2.x Assembly Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: vinoth rajasekaran >Assignee: John Casey > Fix For: 2.2-beta-2 > > > I have a multi-project folders setup like one shown below, > > root > |_ sub-folder1 > |_ sub-folder2 > |_ sub-folder3 > |_ etc > > Have a root pom.xml at the root folder level and in that I have defined > > maven-assembly-plugin > > > src/main/assembly/descriptor.xml > > > > > > Above descriptor works fine only if I have defined a descriptor file on the > src/main/assembly folder for each sub-folder1, sub-folder2, etc. > It would be great if maven supports me in defining a common assembly > descriptor and can be shared by all the sub modules from a common location. -- 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-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146724#action_146724 ] Paul Benedict commented on MNG-3738: I don't have access to change states. Sorry, I wish I did. > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MECLIPSE-200) Please add support for the AJDT plugin
[ http://jira.codehaus.org/browse/MECLIPSE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MECLIPSE-200 started by Arnaud Heritier. > Please add support for the AJDT plugin > -- > > Key: MECLIPSE-200 > URL: http://jira.codehaus.org/browse/MECLIPSE-200 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.2 >Reporter: Eric Berry >Assignee: Arnaud Heritier > Fix For: 2.5.2 > > Attachments: ajdt.patch, maven-eclipse-plugin.zip, > maven-eclipse-plugin.zip > > > Please add support for the AJDT plugin. > I have modified the eclipse plugin for our site with the needed changes. I > have attached the modifications that I made for someone to look at and > incorporate into the 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] Updated: (MECLIPSE-200) Please add support for the AJDT plugin
[ http://jira.codehaus.org/browse/MECLIPSE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-200: - Fix Version/s: 2.5.2 > Please add support for the AJDT plugin > -- > > Key: MECLIPSE-200 > URL: http://jira.codehaus.org/browse/MECLIPSE-200 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.2 >Reporter: Eric Berry >Assignee: Arnaud Heritier > Fix For: 2.5.2 > > Attachments: ajdt.patch, maven-eclipse-plugin.zip, > maven-eclipse-plugin.zip > > > Please add support for the AJDT plugin. > I have modified the eclipse plugin for our site with the needed changes. I > have attached the modifications that I made for someone to look at and > incorporate into the 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: (MASSEMBLY-73) Sharing a default assembly descriptor across sub modules
[
http://jira.codehaus.org/browse/MASSEMBLY-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146717#action_146717
]
John Casey commented on MASSEMBLY-73:
-
There's a much simpler way to accomplish all this. In fact, I've even moved
away from using the descriptor and component packaging types in favor of it.
Simply put all your standardized descriptors, components, etc. into a normal
jar project, and install that project. The project directory might look
something like this:
{noformat}
/ my-custom-assemblies
| +- pom.xml
| +- src
| | +- main
| | | +- resources
| | | | +- assemblies
| | | | | +- custom-one.xml
| | | | | +- custom-two.xml
{noformat}
Then, in the plugin-level dependencies of the POM from which you want to create
an assembly (or, it could be in the top-level POM for a bunch of projects you
want to use the same assembly...you can get pretty creative using
pluginManagement here), you simply reference that standardized
assembly-descriptor project:
{code:xml}
maven-assembly-plugin
2.2-beta-2
org.myproject
my-custom-assemblies
1.0
make-assembly
package
single
custom-one.xml
custom-two.xml
{code}
Then, wherever you want a sub-module to create these two assemblies, you add
this to the sub-module pom:
{code:xml}
maven-assembly-plugin
{code}
> Sharing a default assembly descriptor across sub modules
>
>
> Key: MASSEMBLY-73
> URL: http://jira.codehaus.org/browse/MASSEMBLY-73
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.0.1
>Reporter: vinoth rajasekaran
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> I have a multi-project folders setup like one shown below,
>
> root
> |_ sub-folder1
> |_ sub-folder2
> |_ sub-folder3
> |_ etc
>
> Have a root pom.xml at the root folder level and in that I have defined
>
> maven-assembly-plugin
>
>
> src/main/assembly/descriptor.xml
>
>
>
>
>
> Above descriptor works fine only if I have defined a descriptor file on the
> src/main/assembly folder for each sub-folder1, sub-folder2, etc.
> It would be great if maven supports me in defining a common assembly
> descriptor and can be shared by all the sub modules from a common location.
--
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-2195) JasperReports 3.0.1 upload
JasperReports 3.0.1 upload -- Key: MAVENUPLOAD-2195 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2195 Project: Maven Upload Requests Issue Type: Task Reporter: Teodor Danciu http://jasperreports.sf.net/maven/jasperreports-3.0.1-bundle.jar http://sourceforge.net/projects/jasperreports http://sourceforge.net/project/memberlist.php?group_id=36382 Open Source Reporting Engine -- 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: (MASSEMBLY-73) Sharing a default assembly descriptor across sub modules
[
http://jira.codehaus.org/browse/MASSEMBLY-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146703#action_146703
]
gjoseph edited comment on MASSEMBLY-73 at 9/2/08 9:28 AM:
-
I surprisingly had to add {code}
true
{code} to the assembly plugin configuration when trying this
again today. How come this could have changed ? (i updated my maven deps to
2.0.9 but I'm don't really see how that would have modified this behaviour)
Also, a little bump on the question above.
was (Author: gjoseph):
I surprisingly had to add {code}
true
{code} to the assembly plugin configuration when trying this
again today. How come this could have changed ?
Also, a little bump on the question above.
> Sharing a default assembly descriptor across sub modules
>
>
> Key: MASSEMBLY-73
> URL: http://jira.codehaus.org/browse/MASSEMBLY-73
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.0.1
>Reporter: vinoth rajasekaran
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> I have a multi-project folders setup like one shown below,
>
> root
> |_ sub-folder1
> |_ sub-folder2
> |_ sub-folder3
> |_ etc
>
> Have a root pom.xml at the root folder level and in that I have defined
>
> maven-assembly-plugin
>
>
> src/main/assembly/descriptor.xml
>
>
>
>
>
> Above descriptor works fine only if I have defined a descriptor file on the
> src/main/assembly folder for each sub-folder1, sub-folder2, etc.
> It would be great if maven supports me in defining a common assembly
> descriptor and can be shared by all the sub modules from a common location.
--
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: (MASSEMBLY-73) Sharing a default assembly descriptor across sub modules
[
http://jira.codehaus.org/browse/MASSEMBLY-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146703#action_146703
]
Grégory Joseph commented on MASSEMBLY-73:
-
I surprisingly had to add {code}
true
{code} to the assembly plugin configuration when trying this
again today. How come this could have changed ?
Also, a little bump on the question above.
> Sharing a default assembly descriptor across sub modules
>
>
> Key: MASSEMBLY-73
> URL: http://jira.codehaus.org/browse/MASSEMBLY-73
> Project: Maven 2.x Assembly Plugin
> Issue Type: New Feature
>Affects Versions: 2.0.1
>Reporter: vinoth rajasekaran
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
>
> I have a multi-project folders setup like one shown below,
>
> root
> |_ sub-folder1
> |_ sub-folder2
> |_ sub-folder3
> |_ etc
>
> Have a root pom.xml at the root folder level and in that I have defined
>
> maven-assembly-plugin
>
>
> src/main/assembly/descriptor.xml
>
>
>
>
>
> Above descriptor works fine only if I have defined a descriptor file on the
> src/main/assembly folder for each sub-folder1, sub-folder2, etc.
> It would be great if maven supports me in defining a common assembly
> descriptor and can be shared by all the sub modules from a common location.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MNG-3738. Resolution: Not A Bug > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak reopened MNG-3738: -- If you're going to comment on it, you might as well fix it-- I noticed the incorrect resolution, and decided to leave it alone to avoid extra email. There is no fix-for version, so it would not have appeared in any release notes. > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3738) Maven Update Depenedency!
[ http://jira.codehaus.org/browse/MNG-3738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146690#action_146690 ] Paul Benedict commented on MNG-3738: If possible, switch the resolution to INVALID so it doesn't show up in the JIRA release notes. > Maven Update Depenedency! > - > > Key: MNG-3738 > URL: http://jira.codehaus.org/browse/MNG-3738 > Project: Maven 2 > Issue Type: Task > Components: Artifacts and Repositories >Affects Versions: 2.0.9 >Reporter: prashant p >Assignee: Wendy Smoak >Priority: Blocker > > Hi , > We are facing issue with maven update dependency.When multiple depevlopers > run maven ,it takes hours of time in updating dependency from artifactory > located in remote.Is it because of network issue causing this slow.I tried > to change localhost in setting.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-357) UCM config_spec are not managed correctly
[ http://jira.codehaus.org/browse/SCM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-357. --- Assignee: Vincent Siveton Resolution: Fixed Patch applied in [r691200|http://svn.apache.org/viewvc?rev=691200&view=rev] Thanks. I also updated the documentation in [r691202|http://svn.apache.org/viewvc?rev=691202&view=rev] Since I have no clearcase tool, could you review it? > UCM config_spec are not managed correctly > - > > Key: SCM-357 > URL: http://jira.codehaus.org/browse/SCM-357 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-clearcase >Affects Versions: 1.0 >Reporter: Jean-Philippe Hautin >Assignee: Vincent Siveton > Fix For: 1.1.1 > > Attachments: > maven-scm-provider-clearcase-ClearCaseCheckOutCommand.patch, > maven-scm-provider-clearcase-ClearCaseScmProviderRepository.patch, > maven-scm-provider-clearcase-ClearCaseScmProviderRepositoryTest.patch, > maven-scm-provider-clearcase-SCM-XXX.patch > > > I am using the UCM clearcase configuration. > Currently, the config_spec of the view does not contain the ucm section even > if we ask for UCM Clearcase. > This is due to the fact that the current behavior erase the existing > config_spec file with one with load rules. > I have added a tiny method in the ClearCaseCheckOutCommand to read the > existing config spec and merge it with load rules. -- 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: (SCM-343) Changelog can be generated with only an end-tag
[ http://jira.codehaus.org/browse/SCM-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-343. --- Assignee: Vincent Siveton Resolution: Fixed Patch applied in [r691197|http://svn.apache.org/viewvc?rev=691197&view=rev] Thanks! > Changelog can be generated with only an end-tag > --- > > Key: SCM-343 > URL: http://jira.codehaus.org/browse/SCM-343 > Project: Maven SCM > Issue Type: Improvement > Components: maven-scm-api, maven-scm-provider-cvs >Affects Versions: 1.0 >Reporter: Roland Asmann >Assignee: Vincent Siveton >Priority: Minor > Fix For: 1.1.1 > > Attachments: scm.diff > > > When given only an end-tag, the changelog was not built correctly --> no tags > were included in the command. > Changes include: > - Check if a tag is given, not if its name is empty > - Building a command-line with tags even if one of the tags' names is empty -- 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: (SCM-252) ClearCaseUpdateConsumer for I18N
[
http://jira.codehaus.org/browse/SCM-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-252.
---
Assignee: Vincent Siveton
Resolution: Fixed
Patch applied in [r691185|http://svn.apache.org/viewvc?rev=691185&view=rev].
Thanks!
> ClearCaseUpdateConsumer for I18N
> -
>
> Key: SCM-252
> URL: http://jira.codehaus.org/browse/SCM-252
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-clearcase
>Affects Versions: 1.0-beta-3
> Environment: does not dependency
>Reporter: komusubi
>Assignee: Vincent Siveton
> Fix For: 1.1.1
>
> Attachments: java.patch, maven-scm-provider-clearcase.patch,
> update_ja.txt
>
>
> It can't get updateFiles list way of indexOf("Loading") method because I
> use Japanese version.
> It might use ResourceBundle ??
> I have to need fix it because use with continuum, so I can give you a patch,
> but how should I do?
--
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: (MPLUGIN-138) Suppress bogus warning in case goalPrefix has been set to default goal prefix
[
http://jira.codehaus.org/browse/MPLUGIN-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MPLUGIN-138.
-
Assignee: Benjamin Bentmann
Resolution: Fixed
Fix Version/s: 2.4.4
Fixed in [r691149|http://svn.apache.org/viewvc?view=rev&revision=691149].
> Suppress bogus warning in case goalPrefix has been set to default goal prefix
> -
>
> Key: MPLUGIN-138
> URL: http://jira.codehaus.org/browse/MPLUGIN-138
> Project: Maven 2.x Plugin Tools
> Issue Type: Improvement
> Components: Plugin Plugin
>Affects Versions: 2.4.3
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Trivial
> Fix For: 2.4.4
>
>
> This is superfluous:
> {noformat}
> [WARNING]
> Goal prefix is specified as: 'versions'. Maven currently expects it to be
> 'versions'.
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-138) Suppress bogus warning in case goalPrefix has been set to default goal prefix
Suppress bogus warning in case goalPrefix has been set to default goal prefix
-
Key: MPLUGIN-138
URL: http://jira.codehaus.org/browse/MPLUGIN-138
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Components: Plugin Plugin
Affects Versions: 2.4.3
Reporter: Benjamin Bentmann
Priority: Trivial
This is superfluous:
{noformat}
[WARNING]
Goal prefix is specified as: 'versions'. Maven currently expects it to be
'versions'.
{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: (SCM-409) Windows path length limitations can be overcome by feeding an absolute path to SVN (checkout command)
[ http://jira.codehaus.org/browse/SCM-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146668#action_146668 ] Dominique Jean-Prost commented on SCM-409: -- Just tested it. It works fine for me. Please note that I only tested the checkout command. > Windows path length limitations can be overcome by feeding an absolute path > to SVN (checkout command) > - > > Key: SCM-409 > URL: http://jira.codehaus.org/browse/SCM-409 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.1 > Environment: Windows OS >Reporter: Dominique Jean-Prost >Assignee: Olivier Lamy > Fix For: 1.1.1 > > > When calling Subversion with relative paths there is a limit of 255 > characters to the path length. If you call Subversion with an absolute path > that no longer applies and you now have access to 32K chars. I have tried > this myself and it does work. Try feeding SVN a path that is relative and is > over 255 chars. It will not be able to complete the transaction. Now, try to > the same path again only as an absolute path and it will successfully > complete the transaction. > This bug was originally fixed for the update command, but still remains for > the checkout command. There may be other command that are affected by this > bug. > 1. cd c:\a\very\long\paht\under\windows\xp\or\windows\2000 > 2. mvn scm:checkout -DconnectionUrl=scm:svn:http://myUrlHere > --> It says > [INFO] Executing: cmd.exe /X /C "svn --non-interactive checkout > http://myUrlHere checkout" > [INFO] Working directory: c:\a\very\long\paht\under\windows\xp\or\windows\2000 > [ERROR] Provider message: > [ERROR] The svn command failed. > [ERROR] Command output: > [ERROR] svn: Your .svn/tmp directory may be missing or corrupt; run 'svn > cleanup' and try again > svn: Can't open file 'checkout\blablasvn-base': Le chemin d'accès > spécifié est introuvable. > 3. If I execute svn --non-interactive checkout http://myUrlHere > c:\a\very\long\paht\under\windows\xp\or\windows\2000\checkout : it works. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-599) mac-libs for gwt 1.5.2 has an incorrect filename
mac-libs for gwt 1.5.2 has an incorrect filename Key: MEV-599 URL: http://jira.codehaus.org/browse/MEV-599 Project: Maven Evangelism Issue Type: Bug Reporter: Martin Algesten The mac version of the native libraries have an incorrect naming which makes it not possible to find via a dependency (missing -dev). gwt-1.5.2-mac-libs.zip 01-Sep-2008 05:56 207K gwt-1.5.2-mac-libs.zip.md5 01-Sep-2008 05:56 34 gwt-1.5.2-mac-libs.zip.sha1 01-Sep-2008 05:56 42 gwt-dev-1.5.2-linux-libs.zip01-Sep-2008 05:55 10M gwt-dev-1.5.2-linux-libs.zip.md501-Sep-2008 05:56 34 gwt-dev-1.5.2-linux-libs.zip.sha1 01-Sep-2008 05:56 42 gwt-dev-1.5.2-windows-libs.zip 01-Sep-2008 02:58 101K gwt-dev-1.5.2-windows-libs.zip.md5 01-Sep-2008 05:56 34 gwt-dev-1.5.2-windows-libs.zip.sha1 01-Sep-2008 05:56 42 -- 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
