[jira] Commented: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126270 ] gotama commented on MIDEA-102: -- I am running XP, Maven 2.0.8, Maven IDEA plugin 2.1 and Cygwin. When I issue 'mvn idea:idea' on the XP command line my IDEA project file is fine. When I issue the same command in Cygwin, the paths are incorrect. Using the 2.2-SNAPSHOT it works fine, except for the above noted conditions where the parent and module dirs are at the same level. This is a different bug. This issue is working on over 8 months without a release, yet there is a fix for one of the show stopping bugs which prevents you from using the plugin. 2.2 should be released as is now and a new fresh jira issue should be created to address the bug about the paths being incorrect for when the parents and modules are at the same level. This plugin is broken without releasing 2.2. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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-1914) Wrong url in error message when using a mirror
[ http://jira.codehaus.org/browse/MNG-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1914. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: (was: 2.1) 2.0.9 > Wrong url in error message when using a mirror > -- > > Key: MNG-1914 > URL: http://jira.codehaus.org/browse/MNG-1914 > Project: Maven 2 > Issue Type: Bug > Components: Errors >Affects Versions: 2.0.1 >Reporter: Vincent Massol >Assignee: Brett Porter > Fix For: 2.0.9 > > > I had the following in my settings.xml: > > [...] > > > cargo m2 release repository > http://cargo.codehaus.org/dist2 > central > > > > > staging-repo > > > central > staging repo > http://test.maven.codehaus.org/maven2 > > true > > > true > > > > > > central > staging repo > http://test.maven.codehaus.org/maven2 > > true > > > true > > > > > > > staging-repo > > [...] > > When building any project I was getting the following console trace: > [...] > Downloading: > http://cargo.codehaus.org/dist2/org/apache/maven/plugins/maven-plugin-parent/2.0/maven-plugin-parent-2.0.pom > [WARNING] Unable to get resource from repository central > (http://test.maven.codehaus.org/maven2) > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > > GroupId: org.apache.maven.plugins > ArtifactId: maven-plugin-parent > Version: 2.0 > > Reason: Unable to download the artifact from any repository > > org.apache.maven.plugins:maven-plugin-parent:pom:2.0 > > from the specified remote repositories: > central (http://test.maven.codehaus.org/maven2) > As you can see it says that it cannot get the pom from the > test.maven.codehaus.org repository whereas it's actually looking in > cargo.codehaus.org... The message needs to be fixed. -- 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-3070) ${x} properties no longer expanded in tag after 2.0.3
[
http://jira.codehaus.org/browse/MNG-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3070:
---
Affects Version/s: (was: 2.0.7)
2.0.9
will need to verify, even maven uses properties in versions.
> ${x} properties no longer expanded in tag after 2.0.3
>
>
> Key: MNG-3070
> URL: http://jira.codehaus.org/browse/MNG-3070
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.7
>Reporter: Gabriele Garuglieri
> Fix For: 2.0.10
>
>
> I was experimenting with maven using killer-app sample
> (http://www.sonatype.com/book/examples/book-killerapp.zip) from Sonatipe book
> (http://www.sonatype.com/book/index.html) and immediately hit a show stopper.
> Maven 2.0.3 is able to build the sample out of the box, but any later version
> up to 2.0.7 chokes telling that it's not able to find the parent project:
> C:\home\prjHome\mavenTest\killerapp>mvn help:effective-pom
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: com.training.killerapp
> ArtifactId: killerapp
> Version: 1.0-SNAPSHOT
> Reason: Unable to download the artifact from any repository
> com.training.killerapp:killerapp:pom:1.0-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> com.training.killerapp:killerapp for project: null:killerapp-model:jar:null
> for project null:killerapp-model:jar:null
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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)
> All the problems looks to be caused by the fact that the root POM has the
> following construct (that should be perfectly legal) in it:
> ${killerappVersion}
>
> 1.0-SNAPSHOT
>
> If i substitute the version tag in the root POM with the following everything
> works with all versions.
> 1.0-SNAPSHOT
> I was not able to find anywhere in the doc that ${x} substitution is no
> longer legal in tag, so i think this is a regression from 2.0.3.
> Btw, all the test were done with clean local repository.
--
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-3070) ${x} properties no longer expanded in tag after 2.0.3
[
http://jira.codehaus.org/browse/MNG-3070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3070:
---
Affects Version/s: (was: 2.0.9)
2.0.7
Fix Version/s: (was: 2.0.x)
2.0.10
> ${x} properties no longer expanded in tag after 2.0.3
>
>
> Key: MNG-3070
> URL: http://jira.codehaus.org/browse/MNG-3070
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.7
>Reporter: Gabriele Garuglieri
> Fix For: 2.0.10
>
>
> I was experimenting with maven using killer-app sample
> (http://www.sonatype.com/book/examples/book-killerapp.zip) from Sonatipe book
> (http://www.sonatype.com/book/index.html) and immediately hit a show stopper.
> Maven 2.0.3 is able to build the sample out of the box, but any later version
> up to 2.0.7 chokes telling that it's not able to find the parent project:
> C:\home\prjHome\mavenTest\killerapp>mvn help:effective-pom
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: com.training.killerapp
> ArtifactId: killerapp
> Version: 1.0-SNAPSHOT
> Reason: Unable to download the artifact from any repository
> com.training.killerapp:killerapp:pom:1.0-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> com.training.killerapp:killerapp for project: null:killerapp-model:jar:null
> for project null:killerapp-model:jar:null
> at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:290)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> 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)
> All the problems looks to be caused by the fact that the root POM has the
> following construct (that should be perfectly legal) in it:
> ${killerappVersion}
>
> 1.0-SNAPSHOT
>
> If i substitute the version tag in the root POM with the following everything
> works with all versions.
> 1.0-SNAPSHOT
> I was not able to find anywhere in the doc that ${x} substitution is no
> longer legal in tag, so i think this is a regression from 2.0.3.
> Btw, all the test were done with clean local repository.
--
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-2553) Maven Local Settings Model should allow configuration of distributions (distributionManagement)
[ http://jira.codehaus.org/browse/MNG-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2553: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 This can currently be handled using the new deploy plugin's altDeploymentRepository > Maven Local Settings Model should allow configuration of distributions > (distributionManagement) > --- > > Key: MNG-2553 > URL: http://jira.codehaus.org/browse/MNG-2553 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Affects Versions: 2.0.4 >Reporter: Jimisola Laursen > Fix For: 2.1 > > > There is a good use case where this would be very useful. > E.g. I develop a plugin in mojo-sandbox and want to test it in an environment > other than the one that I developed it on (e.g. a computer at work). I check > out the plugin to this, build and then want to deploy to another repository > (e..g a company's internal repository). I don't want to fiddle with the > pom.xml of the plugin, just refer to a profile in settings.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] Updated: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-1323: --- Fix Version/s: (was: 2.0.x) 2.0.10 > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.10 > > Attachments: MNG-1323-components-2.0.x.diff, > MNG-1323-core-integration-testing-2.diff, > MNG-1323-core-integration-testing.diff, > MNG-1323-core-integration-tests-3.diff, MNG-1323-core-integration-tests.diff, > MNG1323-maven-core-2.1.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- 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-3092) Version ranges with non-snapshot bounds can contain snapshot versions
[ http://jira.codehaus.org/browse/MNG-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3092: --- Fix Version/s: (was: 2.0.x) 2.0.10 > Version ranges with non-snapshot bounds can contain snapshot versions > - > > Key: MNG-3092 > URL: http://jira.codehaus.org/browse/MNG-3092 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Reporter: Mark Hobson >Assignee: Mark Hobson > Fix For: 2.0.10 > > Attachments: MNG-3092.patch > > > Contrary to the 2.0 design docs: > "Resolution of dependency ranges should not resolve to a snapshot > (development version) unless it is included as an explicit boundary." > -- from > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-Incorporating%7B%7BSNAPSHOT%7D%7Dversionsintothespecification > The following is equates to true: > VersionRange.createFromVersionSpec( "[1.0,1.1]" ).containsVersion( new > DefaultArtifactVersion( "1.1-SNAPSHOT" ) ) > The attached patch only allows snapshot versions to be contained in a range > if they are equal to one of the boundaries. Note that this is a strict > equality, so [1.0,1.2-SNAPSHOT] will not contain 1.1-SNAPSHOT. -- 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-2318) When a project has modules and its parent is not preinstalled the build fails
[ http://jira.codehaus.org/browse/MNG-2318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2318: --- Fix Version/s: (was: 2.0.x) 2.0.10 > When a project has modules and its parent is not preinstalled the build fails > - > > Key: MNG-2318 > URL: http://jira.codehaus.org/browse/MNG-2318 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.4 >Reporter: Carlos Sanchez >Priority: Critical > Fix For: 2.0.10 > > > . > |-- A > | `-- pom.xml (A) > |-- C > | `-- pom.xml (C) - module of B > `-- pom.xml (B) > C parent is B and B parent is A, trying to build B it fails -- 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-2426) Artifact copied to local repository with wrong file extension when using jboss-packaging plugin
[ http://jira.codehaus.org/browse/MNG-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2426: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x > Artifact copied to local repository with wrong file extension when using > jboss-packaging plugin > --- > > Key: MNG-2426 > URL: http://jira.codehaus.org/browse/MNG-2426 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: jdk 1.5.0_06, maven 2.0.4, jboss-package-maven-plugin > 2.0-SNAPSHOT (from mojo-sandbox SVN r2088) >Reporter: Fredrik Vraalsen > Fix For: 2.0.x > > > When using the jboss-packaging plugin and setting to jboss-sar in > my pom, the artifact is copied into the local repository with the wrong file > extension (.jboss-sar instead of .sar). The jboss-packaging components.xml > has set to sar. The file in the build target directory has the > correct .sar extension. > Here's the relevant excerpt from my pom.xml: > jboss-sar > ... > > > > org.codehaus.mojo > jboss-packaging-maven-plugin > 2.0-SNAPSHOT > true > ... -- 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-1203) snapshot directories create in local repository on some occasions
[ http://jira.codehaus.org/browse/MNG-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-1203: --- Description: do you still see this? Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x > snapshot directories create in local repository on some occasions > - > > Key: MNG-1203 > URL: http://jira.codehaus.org/browse/MNG-1203 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Brett Porter >Priority: Trivial > Fix For: 2.0.x > > > do you still see 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] Closed: (MNG-2436) Alternative to proxying or mirroring maven repos
[ http://jira.codehaus.org/browse/MNG-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2436. -- Resolution: Won't Fix This is the job of one of the available repo managers > Alternative to proxying or mirroring maven repos > > > Key: MNG-2436 > URL: http://jira.codehaus.org/browse/MNG-2436 > Project: Maven 2 > Issue Type: Wish > Components: Artifacts and Repositories >Reporter: Adrian > Fix For: Reviewed Pending Version Assignment > > > To minimise reliance on outside repos and to lower bandwidth externally from > our network I wonder if maven could provide the following option: > Whenever it downloads an artifact/plugin from an external server if could > upload and install the artifact on another server's repository of the > developers choice if it does not exist there. > i.e. whenever I build code on my machine and a dependency changes and is > downloaded to my local repository it is also installed to a central > repository for our dev team. > I know that another solution is to proxy the server, but this means we need > to maintain a proxy that understands maven on the central machine. -- 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-2513) ArtifactResolver.resolveTransitively() is not working
[ http://jira.codehaus.org/browse/MNG-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2513: --- Affects Version/s: (was: 2.0.10) 2.0.5 Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > ArtifactResolver.resolveTransitively() is not working > - > > Key: MNG-2513 > URL: http://jira.codehaus.org/browse/MNG-2513 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4, 2.0.5 >Reporter: Jason Dillon >Assignee: Brian Fox > Fix For: 2.0.10 > > > I've got a plugin which is basically doing the same thing that the dependency > plugin is, defining artifactItem elements in a configuration, which provide > he details for a maven artifact. The version details are filled in just like > the dependency plugin. > Problem is that I need to take each of those artifactItems and get the > transitive dependencies for them... but so far all of my attempts to do so > with ArtifactResolver.resolveTransitively() is not working. > Should be easy enough to test, just create a new artifact that you know has > deps with a ArtifactFactory, then try to get the transitive dependencies. > Everytime I try I get an empty set from result.getArtifacts(). -- 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-2477) Implement repository security improvements for verification of downloaded artifacts
[ http://jira.codehaus.org/browse/MNG-2477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2477: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 > Implement repository security improvements for verification of downloaded > artifacts > --- > > Key: MNG-2477 > URL: http://jira.codehaus.org/browse/MNG-2477 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Brett Porter > Fix For: 2.1 > > > http://docs.codehaus.org/display/MAVEN/Repository+Security+Improvements -- 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-2513) ArtifactResolver.resolveTransitively() is not working
[ http://jira.codehaus.org/browse/MNG-2513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2513: --- Affects Version/s: 2.0.10 i saw this recently and will need to fix also > ArtifactResolver.resolveTransitively() is not working > - > > Key: MNG-2513 > URL: http://jira.codehaus.org/browse/MNG-2513 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4, 2.0.5 >Reporter: Jason Dillon >Assignee: Brian Fox > Fix For: 2.0.10 > > > I've got a plugin which is basically doing the same thing that the dependency > plugin is, defining artifactItem elements in a configuration, which provide > he details for a maven artifact. The version details are filled in just like > the dependency plugin. > Problem is that I need to take each of those artifactItems and get the > transitive dependencies for them... but so far all of my attempts to do so > with ArtifactResolver.resolveTransitively() is not working. > Should be easy enough to test, just create a new artifact that you know has > deps with a ArtifactFactory, then try to get the transitive dependencies. > Everytime I try I get an empty set from result.getArtifacts(). -- 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-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2551: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.9 will try to check for 2.0.9 if the attached pom is valid. If not, will bump to .10 > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden > Fix For: 2.0.9 > > Attachments: pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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-2524) DefaultArtifactFactory.createDependencyArtifact sets scope to null
[
http://jira.codehaus.org/browse/MNG-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2524:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.0.9
> DefaultArtifactFactory.createDependencyArtifact sets scope to null
> --
>
> Key: MNG-2524
> URL: http://jira.codehaus.org/browse/MNG-2524
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Adrian Sox
>Priority: Trivial
> Fix For: 2.0.9
>
>
> There are four createDependencyArtifact methods in DefaultArtifactFactory,
> all of which take scope as an argument. One of the four fails to pass the
> scope into the createArtifact method.
> Specifically,
> public Artifact createDependencyArtifact( String groupId, String
> artifactId, VersionRange versionRange, String type,
>String classifier, String
> scope )
> {
> return createArtifact( groupId, artifactId, versionRange, type,
> classifier, null, null );
> }
> should be
> public Artifact createDependencyArtifact( String groupId, String
> artifactId, VersionRange versionRange, String type,
>String classifier, String
> scope )
> {
> return createArtifact( groupId, artifactId, versionRange, type,
> classifier, scope, null );
> }
--
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-2583) DefaultArtifact: Method getVersionRange returns null also if field version is already set! [SMALL PATCH ATTACHED]
[ http://jira.codehaus.org/browse/MNG-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2583: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 I suspect this is already fixed. Can you reproduce? > DefaultArtifact: Method getVersionRange returns null also if field version is > already set! [SMALL PATCH ATTACHED] > - > > Key: MNG-2583 > URL: http://jira.codehaus.org/browse/MNG-2583 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0-alpha-1 > Environment: Java5, WinXp >Reporter: Martin Zeltner >Assignee: Jason van Zyl > Fix For: 2.0.10 > > Attachments: patch_maven-artifact_made-getVersionRange-saver.patch > > > In class *org.apache.maven.artifact.DefaultArtifact* method *getVersionRange* > returns *null* altough the version field is already set. In attached patch I > check in method getVersionRange if versionRange is null if field version or > baseVersion is already set and then create the versionRange by using > version/baseVersion. By the way I've replaced HashMap with a LinkedHashMap to > remember the insertion order of meta data. > For those who don't see why this patch is needed can try binding the eclipse > plugin to a phase before the jar plugin is bound. The eclipse plugin uses the > org.apache.maven.artifact.resolver.DefaultArtifactCollector which is invoking > method setVersion of org.apache.maven.artifact.DefaultArtifact which will > erase field version range and cause a NullPointerException in plugin jar that > doesn't check if returned version range is null. > Cheers, > Martin -- 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-2585) Overriding default naming
[
http://jira.codehaus.org/browse/MNG-2585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2585:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1
> Overriding default naming
> -
>
> Key: MNG-2585
> URL: http://jira.codehaus.org/browse/MNG-2585
> Project: Maven 2
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Jonathan Gilbert
> Fix For: 2.1
>
>
> Currently all artifacts in a maven2 repository must be named
> ${artifactId}-${version}[-${classifier}].${packaging}. Sometimes this is
> simply not possible. Jars can be renamed easily enough, but other binaries
> cannot.
> My case involves .NET. .NET assemblies are completely analogous to java jars
> - simply a packaging of classes. The crucial difference though is that .NET
> assemblies cannot be renamed (as classes are located based upon their
> containing assembly name). There are plenty of existing third party .NET
> libraries which currently cannot be placed in a maven repository. (Note that
> if the assembly is renamed such that, for instance, it has no version in the
> name, this is no problem as .NET embeds this information into the assembly
> itself.)
--
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-2596) Allow support for multiple classifier for a given artifact
[
http://jira.codehaus.org/browse/MNG-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2596:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1
> Allow support for multiple classifier for a given artifact
> --
>
> Key: MNG-2596
> URL: http://jira.codehaus.org/browse/MNG-2596
> Project: Maven 2
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Vincent Massol
> Fix For: 2.1
>
>
> Right now Maven 2.0.x only support a single classifier per artifact. There
> are cases where more than 1 classifer would be required. For example the
> Clover plugin modifies the current artifact to add a "clover" classifier.
> However when the source plugin runs it tries to add another classifier
> ("sources") to the artifact. As only one classifier is currently supported
> it's not working (see MSOURCES-10). In the clover plugin code we also have
> things like:
> {code:java}
> // Do not try to find Clovered versions for artifacts with
> classifiers. This is because Maven2 only
> // supports a single classifier per artifact and thus if we replace
> the original classifier with
> // a Clover classifier the artifact will fail to perform properly as
> intended originally. This is a
> // limitation.
> if ( artifact.getClassifier() == null )
> {
> {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] Closed: (MNG-2630) This is a question on how to extract the groupid,artifactid and other values of the artifact from its pom using a java code
[ http://jira.codehaus.org/browse/MNG-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2630. -- Resolution: Incomplete > This is a question on how to extract the groupid,artifactid and other values > of the artifact from its pom using a java code > --- > > Key: MNG-2630 > URL: http://jira.codehaus.org/browse/MNG-2630 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: We use Maven in sun solaris environment >Reporter: sharda sheshabhattar > Fix For: Reviewed Pending Version Assignment > > > Using a java program I want to extract the details of an artifact from a > pom.How can I do that? > Please help.Also point me to some docs and examples on doing this > Thanks, > Sharda -- 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-2635) DefaultArtifactCollector.recurse can lose versionRange
[
http://jira.codehaus.org/browse/MNG-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2635:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.0.10
> DefaultArtifactCollector.recurse can lose versionRange
> --
>
> Key: MNG-2635
> URL: http://jira.codehaus.org/browse/MNG-2635
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Environment: Linux
>Reporter: Bud Osterberg
>Assignee: Brian Fox
> Fix For: 2.0.10
>
> Attachments: artifact_patch
>
>
> This affects maven 2.0.4 and 2.0.5 (at least).
> I'm not quite sure how to reproduce the bug in a simple test case, but we
> have a setup where running the command:
> mvn install site source:jar
> crashes in ArtifactUtils.copyArtifact because artifact.getVersionRange()
> returns null.
> The code that seems to be causing the problem is in
> DefaultArtifactCollector.recurse(). Because the Artifact sets the version in
> setVersionRange, but can't set the VersionRange from setVersion, the
> VersionRange should take precedence if it exists. A simple diff follows:
> Index:
> components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
> ===
> ---
> components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
> (revision 467177)
> +++
> components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
> (working copy)
> @@ -114,8 +114,13 @@
>
> fireEvent( ResolutionListener.MANAGE_ARTIFACT, listeners, node,
> artifact );
>
> -if ( artifact.getVersion() != null )
> +VersionRange range = artifact.getVersionRange();
> +if (range != null)
> {
> + node.getArtifact().setVersionRange(range);
> +}
> +else if ( artifact.getVersion() != null )
> +{
> node.getArtifact().setVersion( artifact.getVersion() );
> }
> if ( artifact.getScope() != null )
--
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-2645) warning message for local scope test should indicate whether the problem is
[ http://jira.codehaus.org/browse/MNG-2645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2645: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 > warning message for local scope test should indicate whether the problem is > --- > > Key: MNG-2645 > URL: http://jira.codehaus.org/browse/MNG-2645 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Barrie Treloar > Fix For: 2.1 > > > This is the warning message you get when a pom doesn't define junit to be > scoped as test (as it should) > [WARNING] > Artifact junit:junit:jar:3.8.1:test retains local scope 'test' > overriding broader scope 'compile' > given by a dependency. If this is not intended, modify or remove the > local scope. > The error message does not indicate where the problem originated, which would > make fixing these issues up much easier. > Something like: > [WARNING] > Artifact junit:junit:jar:3.8.1:test retains local scope 'test' > overriding broader scope 'compile' > given by a dependency in > :::. > If this is not intended, modify or remove the local scope. -- 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-2999) Receiving a 403 response from a mirror server should attempt other mirrors
[ http://jira.codehaus.org/browse/MNG-2999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2999. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 2.0.x) > Receiving a 403 response from a mirror server should attempt other mirrors > -- > > Key: MNG-2999 > URL: http://jira.codehaus.org/browse/MNG-2999 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Matt Ryall >Assignee: Brett Porter >Priority: Minor > > Trying to download asm:asm:3.0:jar from several of the central mirrors fails > with a 403, but it would work if it attempted download from the main site. > I'm not sure whether this is an issue caused by the fact that the mirrors > aren't true mirrors, or that Maven should attempt other mirrors if one of > them fails with a 403 (or perhaps also 404) 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] Updated: (MNG-2649) Allow support for property list based artifact qualifying (enhanced classifiers)
[
http://jira.codehaus.org/browse/MNG-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2649:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1
> Allow support for property list based artifact qualifying (enhanced
> classifiers)
>
>
> Key: MNG-2649
> URL: http://jira.codehaus.org/browse/MNG-2649
> Project: Maven 2
> Issue Type: New Feature
> Components: Artifacts and Repositories
>Affects Versions: 2.0.4
> Environment: Maven 2
>Reporter: Cédric Vidal
> Fix For: 2.1
>
>
> It should be possible to qualify different flavors of an artifact with a list
> of properties instead of just a single classifier.
> The qualified artifacts could be named:
> {noformat}
> myproj-1.0-env=prod-distributed=true.ear
> myproj-1.0-env=dev-distributed=true.ear
> myproj-1.0-env=prod-distributed=false.ear
> myproj-1.0-env=dev-distributed=false.ear
> {noformat}
> They would be referenced that way:
> {code:xml}
>
> com.foo.bar
> myproj
> 1.0
>
> envprod
> distributedtrue
>
>
> {code}
> And the order of the classifiers should not be important. The previous should
> resolve both:
> {noformat}
> myproj-1.0-env=prod-distributed=true.ear
> myproj-1.0-distributed=true-env=prod.ear
> {noformat}
> Qualifiers could also be transitive. A typical use case is EARs (or any other
> types of artifacts which when packaged embed other artifacts) . If you want
> to build the distributed production version of an EAR, then you certainly
> want to include in that EAR the distributed production versions of its WAR
> dependencies.
> To avoid clash in naming with current classifiers, maybe this functionality
> could be named qualifiers. Finally, semantically speaking, the difference
> between classifiers and "qualifiers" could be that the "qualifiers" could be
> used for mutually exclusive artifacts whereas classified versions of a given
> artifact can be used either together or not.
> To illustrate my point, regarding qualifiers, there is no sens in depending
> on both prod and dev versions of a WAR or depending on both the distributed
> and non distributed versions of a same EAR, whereas regarding classifiers, in
> code generation scenarios, daos and entities are generated by a single
> project and attached as seperate jars, they are a whole but it's up to you to
> depend only on entities or on both entities and DAOs. For a more detailed
> explanation of that code generation use case, please see the discussion with
> Stephane Nicoll in MEAR-44.
> Regards,
> Cédric Vidal
--
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-2650) Classifiers are not powerful enough to adress the problem of generating different flavours of an artifact
[ http://jira.codehaus.org/browse/MNG-2650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2650: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 > Classifiers are not powerful enough to adress the problem of generating > different flavours of an artifact > - > > Key: MNG-2650 > URL: http://jira.codehaus.org/browse/MNG-2650 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Cédric Vidal > Fix For: 2.1 > > > Today, Maven only offers a single classifier to adress the problem of > generating different flavours of an artifact such as dev and prod versions of > an EAR, but most of the time, this is not enough, you have a prod version > which is distributed, a prod version which is not, a dev version which is > distributed and a dev version which is not ... > With current classifiers, you can only put one classifier on an artifact, so > if the artifact is already marked with a 'prod' classifier, you cannot add a > 'distributed' one. > Vincent Massol already submitted an idea in MNG-2596 which would address that > limitation by adding support for multiple classifiers on a single artifact. > In MNG-2649, I propose an alternative solution (which is not necessarily > incompatible btw) by adding support for a list of properties to artifacts. > Regards, > Cédric Vidal > PS: I submitted two different issues to separate the problem from the > solution (MNG-2649) ;) -- 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-2834) "from the specified remote repositories" message incorrect
[ http://jira.codehaus.org/browse/MNG-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126254 ] Brett Porter commented on MNG-2834: --- this looks like a POM misconfiguration to me. Or it's being resolved from inside a plugin that uses those repos instead. > "from the specified remote repositories" message incorrect > -- > > Key: MNG-2834 > URL: http://jira.codehaus.org/browse/MNG-2834 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Geoffrey De Smet >Assignee: John Casey >Priority: Trivial > Fix For: 2.1 > > > I am getting this message on a not found dependency: > from the specified remote repositories: > ggg-dev (http://mvn.ggg.be/maven2/dev), > apache.snapshots (http://svn.apache.org/maven-snapshot-repository), > ggg-deploy (http://mvn.ggg.be/maven2/deploy), > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > But that dependency (commons-collections:commons-collections:jar:2.0) is in > ibiblio. > However, we don't use ibiblio, because we configured our repositories like > this: > > > central > ggg deploy repository > http://mvn.ggg.be/maven2/deploy > > true > > > false > > > > ggg-dev > ggg dev repository > http://mvn.ggg.be/maven2/dev > > false > > > true > > > > > > ggg-deploy > ggg deploy repository > http://mvn.schaubroeck.be/maven2/deploy > > true > > > false > > > > ggg-dev > Schaubroeck dev repository > http://mvn.schaubroeck.be/maven2/dev > > false > > > true > > > > So the following lines of "from the specified remote repositories" are > incorrect: > apache.snapshots (http://svn.apache.org/maven-snapshot-repository), > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > PS: especially those snapshots in there scared me... I deleted my entire > repo, verified that we do not include snapshot repo's and still they show up > in that list. -- 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-2716) pluginRepositories seems to be ignored when running a goal without pom.xml
[ http://jira.codehaus.org/browse/MNG-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2716. -- Resolution: Duplicate > pluginRepositories seems to be ignored when running a goal without pom.xml > -- > > Key: MNG-2716 > URL: http://jira.codehaus.org/browse/MNG-2716 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: Linux debian 2.6.16-2-686 >Reporter: Milos Volauf > Fix For: Reviewed Pending Version Assignment > > Attachments: settings.xml > > > I wanted to try the maven-eclipse-plugin, the goal make-artifacts. > mvn eclipse:make-artifacts > However, make-artifacts goal is not in eclipse plugin 2.2, only in > 2.3-SNAPSHOT. > So followed guides and added pluginRepositry section into my > ~/.m2/settings.xml (attached) > so that I can use an apache plugin snapshot repository. > Then I tried: > mvn org.apache.maven.plugins:maven-eclipse-plugin:2.3-SNAPSHOT:make-artifacts > -P apache > But maven did not try to load the snapshot plugin: > ... > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.plugins > ArtifactId: maven-eclipse-plugin > Version: 2.3-SNAPSHOT > Reason: Unable to download the artifact from any repository > org.apache.maven.plugins:eclipse:pom:2.3-SNAPSHOT > from the specified remote repositories: > central (http://repo1.maven.org/maven2) > We can see that maven did not try the pluginRep. specified in settings.xml. > The I found out that if I run the command above in the folder where pom.xml > exists, it works. > (I created an initial project by archetype plugin.) > So it seems to me that this is a (maybe small) bug. Usually, people run maven > in folder where pom.xml exists, most goals require it. > However, certain goals can run without pom.xml (such as > eclipse:make-artifacts) and here it seems to me that maven ignored my > settings (pluginRepositories). -- 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-3337) Downloading plugins for an inhouse repository problem
[ http://jira.codehaus.org/browse/MNG-3337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3337. -- Resolution: Duplicate duplicate of MNG-3099 > Downloading plugins for an inhouse repository problem > - > > Key: MNG-3337 > URL: http://jira.codehaus.org/browse/MNG-3337 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: sedatcorbaci >Priority: Blocker > > For an inhouse maven repository we can't find a way to download the plugins > to local repo. > When we try to execute an initial archetype:create command encountered maven > couldn't find the archetype plugin error. To deal with this we just copies > org.apache folder to local repo and then everything fine. But again if i need > any plugin that is not in copied to local repo manually maven couldn't > download it from internal repository. -- 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-2717) Cache the repo dependencies
[
http://jira.codehaus.org/browse/MNG-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-2717:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.1
> Cache the repo dependencies
> ---
>
> Key: MNG-2717
> URL: http://jira.codehaus.org/browse/MNG-2717
> Project: Maven 2
> Issue Type: Improvement
> Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Nigel Magnay
>Priority: Minor
> Fix For: 2.1
>
>
> Once projects get of a significant size, there can be a large number of
> dependencies, and transitive dependencies thereof.
> In our WAR projects (for example), this can approach a few hundred
> dependencies (though there are a fair number of duplicates).
> Looking at JProfiler (after examinining one of my own non-maven tools that
> also parses POM files), the parsing cycle of reading all these POM files from
> the local repo, and pull-parsing them for dependencies takes a significant
> proportion of the execute time (4 of the top 10 hotspots are in MXParser.
> Since non-snapshot dependencies ought never to change their dependencies [1],
> and dependency download could trigger the fact that the dependencies might
> have changed anyway, some kind of caching mechanism could be used to speed
> this up (something like {artifact, scope} -> List{artifact}).
> [1] I have reserved a particular space in hell for those people who *do*
> change the deps on released POMs... ;-S
--
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-2744) checksum comparison should be case-insensitive
[ http://jira.codehaus.org/browse/MNG-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2744: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > checksum comparison should be case-insensitive > -- > > Key: MNG-2744 > URL: http://jira.codehaus.org/browse/MNG-2744 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Ian Springer > Fix For: 2.0.10 > > > Validation of MD5 and SHA1 checksums should be case-insensitive (since the > individual characters represent hexadecimal digits). For example: > [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = > '9657ed010cea89caa1e35ae326dfccf28ea007f5'; remote > = '9657ED010CEA89CAA1E35AE326DFCCF28EA007F5' - RETRYING -- 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-2739) Repository entries are not validated and NPE will occur
[ http://jira.codehaus.org/browse/MNG-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2739: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > Repository entries are not validated and NPE will occur > --- > > Key: MNG-2739 > URL: http://jira.codehaus.org/browse/MNG-2739 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Reporter: Jason van Zyl > Fix For: 2.0.10 > > > Using something like the following has no id and an incorrect file url: > > cbuilds > > > > /Users/jvanzyl/js/org/codehaus/mojo/trunk/mojo/mojo-sandbox/c-builds/test-cpkg/m2-repo > > > > java.lang.NullPointerException > at > org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:239) > at java.util.HashMap.hash(HashMap.java:264) > at java.util.HashMap.put(HashMap.java:382) > at java.util.HashSet.add(HashSet.java:194) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:665) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-2741) Meaningless error message: "Error transferring file"
[ http://jira.codehaus.org/browse/MNG-2741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2741: --- Assignee: John Casey Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 another error msg thing... > Meaningless error message: "Error transferring file" > > > Key: MNG-2741 > URL: http://jira.codehaus.org/browse/MNG-2741 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Graham Leggett >Assignee: John Casey > Fix For: 2.1 > > > When an attempt is made to resolve dependencies, the following error is > encountered: > [INFO] artifact org.apache.maven.plugins:maven-resources-plugin: checking for > updates from codehaus-mojo-snapshot-plugins > [WARNING] repository metadata for: 'artifact > org.apache.maven.plugins:maven-resources-plugin' could not be retrieved from > repository: codehaus-mojo-snapshot-plugins due to an error: Error > transferring file > [INFO] Repository 'codehaus-mojo-snapshot-plugins' will be blacklisted > Without further information, debugging this problem is impractical. > Information needed in the error message: > - Whether or not a proxy is being used, and if so, which one. (Symptoms in > this case indicate no proxy is being used, yet a proxy is configured - no way > to tell whether its a config problem or a proxy problem) > - Whether the server and/or proxy server gave an error code (4xx, 5xx), or > whether there was no response at all. -- 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-2781) Snapshot plugin repository declarations cause snapshot plugins to slip in where only releases are requested
[ http://jira.codehaus.org/browse/MNG-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2781: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 > Snapshot plugin repository declarations cause snapshot plugins to slip in > where only releases are requested > --- > > Key: MNG-2781 > URL: http://jira.codehaus.org/browse/MNG-2781 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.1-alpha-1 >Reporter: Jason van Zyl > Fix For: 2.1 > > > If you specify a plugin snapshot repository then snapshots will be pulled > down for plugins for which you do not specify a version. I'm bootstrapping on > trunk and trying to debug a problem with the jar plugin and I always get a > snapshot because a snapshot plugin repository is specified. -- 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-3204) Parallel dependency fetching
[ http://jira.codehaus.org/browse/MNG-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3204. -- Assignee: Brian Fox Resolution: Duplicate > Parallel dependency fetching > > > Key: MNG-3204 > URL: http://jira.codehaus.org/browse/MNG-3204 > Project: Maven 2 > Issue Type: Improvement > Components: Performance >Affects Versions: 2.0.7 >Reporter: Marat Radchenko >Assignee: Brian Fox > Fix For: 2.x > > > On projects with many dependencies initial dependency fetch process can be > very slow (20 minutes+). It could be greately speeded up by using parallel > fetching. -- 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-2834) "from the specified remote repositories" message incorrect
[ http://jira.codehaus.org/browse/MNG-2834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2834: --- Assignee: John Casey Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 John, this might be fixed by the error rework? > "from the specified remote repositories" message incorrect > -- > > Key: MNG-2834 > URL: http://jira.codehaus.org/browse/MNG-2834 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Geoffrey De Smet >Assignee: John Casey >Priority: Trivial > Fix For: 2.1 > > > I am getting this message on a not found dependency: > from the specified remote repositories: > ggg-dev (http://mvn.ggg.be/maven2/dev), > apache.snapshots (http://svn.apache.org/maven-snapshot-repository), > ggg-deploy (http://mvn.ggg.be/maven2/deploy), > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > But that dependency (commons-collections:commons-collections:jar:2.0) is in > ibiblio. > However, we don't use ibiblio, because we configured our repositories like > this: > > > central > ggg deploy repository > http://mvn.ggg.be/maven2/deploy > > true > > > false > > > > ggg-dev > ggg dev repository > http://mvn.ggg.be/maven2/dev > > false > > > true > > > > > > ggg-deploy > ggg deploy repository > http://mvn.schaubroeck.be/maven2/deploy > > true > > > false > > > > ggg-dev > Schaubroeck dev repository > http://mvn.schaubroeck.be/maven2/dev > > false > > > true > > > > So the following lines of "from the specified remote repositories" are > incorrect: > apache.snapshots (http://svn.apache.org/maven-snapshot-repository), > snapshots (http://snapshots.maven.codehaus.org/maven2), > central (http://repo1.maven.org/maven2) > PS: especially those snapshots in there scared me... I deleted my entire > repo, verified that we do not include snapshot repo's and still they show up > in that list. -- 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-3053) Define an Repository Manager API for reaching far RMs for various inquiries
[ http://jira.codehaus.org/browse/MNG-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3053: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 > Define an Repository Manager API for reaching far RMs for various inquiries > --- > > Key: MNG-3053 > URL: http://jira.codehaus.org/browse/MNG-3053 > Project: Maven 2 > Issue Type: Wish > Components: Artifacts and Repositories >Reporter: Tamás Cservenák > Fix For: 2.1 > > > Maven Community should define a common API for reaching Repository Managers > in programmatic way. Repository Manager implementations could implement this > API fully or just partially (depending on their capabilities, etc). > This API could be used by various Maven related tools (like M2Eclipse plugin) > in searches, indexing etc. > Possible RM published functionalities: > - direct searching by passing some expressions/lucene queries/whatever > - preparing and offering Lucene/Compass index downloads > - turning reposes online/offine, reachable/unreachable, etc > - Basic RM configurations, repo blackouts, repo controlling > - Advanced RM configurations (probably RM specific?) -- 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: (MJAVADOC-161) performRelease=true breaks install/deploy with multimodule projects
[
http://jira.codehaus.org/browse/MJAVADOC-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wendy Smoak closed MJAVADOC-161.
Resolution: Fixed
> performRelease=true breaks install/deploy with multimodule projects
> ---
>
> Key: MJAVADOC-161
> URL: http://jira.codehaus.org/browse/MJAVADOC-161
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Julien HENRY
> Fix For: 2.4
>
> Attachments: unTest.zip
>
>
> Hi,
> To build my project, I use:
> mvn clean install -DperformRelease=true
> In a multimodule project, it doesn't work if all dependencies are not already
> in the local repository.
> Step to reproduce:
> 1) create a multimodule project with moduleA and moduleB. moduleA depends on
> moduleB.
> 2) Hit mvn clean install: should work
> 3) Clean your local repository (remove moduleA and moduleB)
> 4) Hit mvn clean install -DperformRelease=true:
> {quote}
> [INFO] Scanning for projects...
> [INFO] Reactor build order:
> [INFO] Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO] Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
> [INFO] Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory D:\test\unTest\target
> [INFO] Deleting directory D:\test\unTest\target\classes
> [INFO] Deleting directory D:\test\unTest\target\test-classes
> [INFO] Deleting directory D:\test\unTest\target\site
> [INFO] [site:attach-descriptor]
> [INFO] Preparing source:jar
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO] [source:jar {execution: attach-sources}]
> [INFO] Preparing javadoc:jar
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:unTest:pom:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:moduleB:jar:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO]
>
> [INFO] Building Unnamed - com.capgemini:moduleA:jar:1.0-SNAPSHOT
> [INFO]
>
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [WARNING] Removing: jar from forked lifecycle, to prevent recursive
> invocation.
> [INFO] No goals needed for project - skipping
> [INFO] snapshot com.capgemini:moduleB:1.0-SNAPSHOT: checking for updates from
> illiade-maven-repository-snapshots
> Downloading:
> http://illiade.sud.capgemini.fr/maven2-snapshots/com/capgemini/moduleB/1.0-SNAPSHOT/moduleB-1.0-SNAPSHOT.jar
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) com.capgemini:moduleB:jar:1.0-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=com.capgemini -DartifactId=moduleB \
> -Dversion=1.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file
> Path to dependency:
> 1) com.capgemini:moduleA:jar:1.0-SNAPSHOT
> 2) com.capgemini:moduleB:jar:1.0-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> com.capgemini:moduleA:jar:1.0-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> illiade-maven-repository-snapshots
> (http://illiade.sud.capgemini.fr/maven2-snapshots)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
[jira] Updated: (MNG-2802) Concurrent-safe access to local Maven repository
[ http://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2802: --- Assignee: John Casey Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1 John, you were recently fixing this in 2.1 i believe > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: http://jira.codehaus.org/browse/MNG-2802 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: 2.1 > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- 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-2845) Unwanted creation of repository directories
[ http://jira.codehaus.org/browse/MNG-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2845: --- Affects Version/s: (was: 2.0.10) 2.0.5 Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > Unwanted creation of repository directories > --- > > Key: MNG-2845 > URL: http://jira.codehaus.org/browse/MNG-2845 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 > Environment: Windows XP, JDK 1.4 >Reporter: Holger Hoffstätte > Fix For: 2.0.10 > > > My pom contain a convenience repo: > > local (Maven 1) > Local module repository (lib) > file://lib > ..etc.. > Running mvn eclipse:eclipse with maven 2.0.5 will create that directory in > the filesystem; maven 2.0.4 will not. IMHO creating directories without > explicit instruction is a no-no. > Discussion: > http://www.nabble.com/New-%22feature%22-in-2.0.5%3A-maven-creates-repo-directories-%21-tf3261881s177.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] Updated: (MNG-2994) Snapshot repositories are not checked when using ranges
[ http://jira.codehaus.org/browse/MNG-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2994: --- Affects Version/s: (was: 2.0.10) 2.0.6 Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > Snapshot repositories are not checked when using ranges > --- > > Key: MNG-2994 > URL: http://jira.codehaus.org/browse/MNG-2994 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: 2.0.10 > > Attachments: MNG-2994-2.patch, MNG-2994-3.patch, > MNG-2994-core-it.patch, patch.txt > > > The attached patch demonstrates the problem by adding it0121. If the test > repository has releases enabled, the test passes, when they are disabled, the > test fails. This appears to be due to DefaultArtifact.isSnapshot returning > false for unresolved ranges, thus causing snapshot repositories to be > disabled when resolving artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-119) Aggregate does not work for multiple module project when doing install.
[ http://jira.codehaus.org/browse/MJAVADOC-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126250 ] Wendy Smoak commented on MJAVADOC-119: -- @aggregator has been removed. If this is still a problem, please provide a sample project and steps to reproduce it. I'd like to stage the 2.4 release this weekend, and plan to remove this from the 2.4 bucket if no fix or example is provided. > Aggregate does not work for multiple module project when doing install. > --- > > Key: MJAVADOC-119 > URL: http://jira.codehaus.org/browse/MJAVADOC-119 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Fedora Linux, Maven 2.0.6 >Reporter: Paul Gier > Fix For: 2.4 > > > If have a multi-module project, the javadoc aggregate does not find > inter-module dependencies: > pom.xml > |-->module1 > |-->module2 > module 1 depends on module 2 > The javadoc plugin is added to the build lifecycle attached to the install > phase. When I run "mvn install" I get a "Failed to resolve artifact." error > message looking for module 2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2845) Unwanted creation of repository directories
[ http://jira.codehaus.org/browse/MNG-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2845: --- Affects Version/s: (was: 2.0.5) 2.0.10 > Unwanted creation of repository directories > --- > > Key: MNG-2845 > URL: http://jira.codehaus.org/browse/MNG-2845 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.10 > Environment: Windows XP, JDK 1.4 >Reporter: Holger Hoffstätte > Fix For: Reviewed Pending Version Assignment > > > My pom contain a convenience repo: > > local (Maven 1) > Local module repository (lib) > file://lib > ..etc.. > Running mvn eclipse:eclipse with maven 2.0.5 will create that directory in > the filesystem; maven 2.0.4 will not. IMHO creating directories without > explicit instruction is a no-no. > Discussion: > http://www.nabble.com/New-%22feature%22-in-2.0.5%3A-maven-creates-repo-directories-%21-tf3261881s177.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] Updated: (MNG-2931) DefaultArtifactCollector changes the version of the originatingArtifact if it's in the dependencyManagement with another version
[ http://jira.codehaus.org/browse/MNG-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2931: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > DefaultArtifactCollector changes the version of the originatingArtifact if > it's in the dependencyManagement with another version > > > Key: MNG-2931 > URL: http://jira.codehaus.org/browse/MNG-2931 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5, 2.0.6 >Reporter: Carlos Sanchez > Fix For: 2.0.10 > > Attachments: MNG-2931.patch > > > DefaultDependencyTreeBuilder > https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree/src/main/java/org/apache/maven/shared/dependency/tree/DefaultDependencyTreeBuilder.java > calls collect like this > collector.collect( project.getDependencyArtifacts(), > project.getArtifact(), managedVersions, repository, >project.getRemoteArtifactRepositories(), > metadataSource, null, >Collections.singletonList( listener ) ); > Problem: > This pom > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-component-api/1.0-alpha-22/plexus-component-api-1.0-alpha-22.pom > extends > http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0-alpha-22/plexus-containers-1.0-alpha-22.pom > that in dependencyManagement has > org.codehaus.plexus:plexus-component-api:1.0-alpha-19 > so during collect project.getArtifact().getVersion() is changed to the > managedVersion instead of the original one > Either this is a bug or an exception should be thrown when > originatingArtifact is in managedVersions -- 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-2873) Unable to find transitive dependencies when they have been relocated.
[ http://jira.codehaus.org/browse/MNG-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2873: --- Affects Version/s: (was: 2.0.5) 2.0.10 can you make a sample project or IT? > Unable to find transitive dependencies when they have been relocated. > - > > Key: MNG-2873 > URL: http://jira.codehaus.org/browse/MNG-2873 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre > Fix For: 2.0.10 > > > I have two projects A and B. Project A is dependent on B. Project B has > compile time on project C which is deployed to a repository, repository1. > The newest version, 2.0, of project C has since been relocated from > oldGroupId to newGroupId. The relocation POMs are working correctly and > Project B is able to be built successfully. Project A is not dependent on > anything from repository1 it does not list that repository in its own > section. When building project A, it tries to resolve the > dependencies of B which includes C. However I am currently getting errors > when it tries to resolve the C. Below is an example of this error occurring. > As you can see the list of remote repositories does not display repository1 > as one of the repositories that was checked despite the fact that Project B > listed it in its POM. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > No versions are present in the repository for the artifact with a range [1,) > oldGroupId:projectC:jar:null > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > repo2 (http://repo.some-repo.com/repo) > If I change project B to not use a range but to instead depend on a > non-relocated version of project C everything works fine and I do not get > this issue at all. The other and more correct solution to this issue is to > update project B to use the new groupIds however it forces me to release > project B immediately since all older released versions of B are broken by > using the old groupIds an this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2873) Unable to find transitive dependencies when they have been relocated.
[ http://jira.codehaus.org/browse/MNG-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2873: --- Affects Version/s: (was: 2.0.10) 2.0.5 Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.10 > Unable to find transitive dependencies when they have been relocated. > - > > Key: MNG-2873 > URL: http://jira.codehaus.org/browse/MNG-2873 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Micah Whitacre > Fix For: 2.0.10 > > > I have two projects A and B. Project A is dependent on B. Project B has > compile time on project C which is deployed to a repository, repository1. > The newest version, 2.0, of project C has since been relocated from > oldGroupId to newGroupId. The relocation POMs are working correctly and > Project B is able to be built successfully. Project A is not dependent on > anything from repository1 it does not list that repository in its own > section. When building project A, it tries to resolve the > dependencies of B which includes C. However I am currently getting errors > when it tries to resolve the C. Below is an example of this error occurring. > As you can see the list of remote repositories does not display repository1 > as one of the repositories that was checked despite the fact that Project B > listed it in its POM. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > No versions are present in the repository for the artifact with a range [1,) > oldGroupId:projectC:jar:null > from the specified remote repositories: > central (http://repo1.maven.org/maven2), > repo2 (http://repo.some-repo.com/repo) > If I change project B to not use a range but to instead depend on a > non-relocated version of project C everything works fine and I do not get > this issue at all. The other and more correct solution to this issue is to > update project B to use the new groupIds however it forces me to release > project B immediately since all older released versions of B are broken by > using the old groupIds an this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-141) regression: Adding "jar" execution to the parent of a multi-module javadoc plugin causes "recursive invocations" error
[ http://jira.codehaus.org/browse/MJAVADOC-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MJAVADOC-141. Assignee: Wendy Smoak Resolution: Fixed Closing based on Vincent's comment that the cause was @aggregator, which has since been removed. > regression: Adding "jar" execution to the parent of a multi-module javadoc > plugin causes "recursive invocations" error > -- > > Key: MJAVADOC-141 > URL: http://jira.codehaus.org/browse/MJAVADOC-141 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Mike Youngstrom >Assignee: Wendy Smoak > Fix For: 2.4 > > > I have a multimodule project with the javadoc plugin declared in my parent. > > org.apache.maven.plugins > maven-javadoc-plugin > 2.3 > > true > > > > attach-javadocs > > jar > > > > > After upgrading to 2.3 and do a build I now get the error: > [WARNING] Removing: jar from forked lifecycle, to prevent recursive > invocation. > [INFO] No goals needed for project - skipping > Which then skips the processing of that module and later gives me dependency > errors because previous dependencies were not compiled. > If I remove jar processing from my plugin definition everything works fine > except no javadoc jars are created. -- 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-3415) Transfer errors cause junk metadata in the local repo
[ http://jira.codehaus.org/browse/MNG-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126248 ] Brett Porter commented on MNG-3415: --- using MNG-3341's IT as a basis should make it pretty easy to reproduce (just use an invalid wagon to trigger the error). However, what really needs to be rechecked is that no other metadata operations break as a result (most particularly, you don't want to end up downloading missing metadata every time if it doesn't exist) > Transfer errors cause junk metadata in the local repo > - > > Key: MNG-3415 > URL: http://jira.codehaus.org/browse/MNG-3415 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > Attachments: MNG-3415.diff > > > I see this all the time and I swear there was an issue for it, but now I > can't find it. Sometimes there is metadata in the repo, usually after an > offline build or a build where something went wrong downloading artifacts. > Maven will apparently decide based on the metadata that the file can never be > found and will simply fail on a missing artifact. You can tell this has > happened because no attempt has actually been made to download the artifact > from a repository. Subsequent clearing of (portions) the localrepo fixes the > issue. This is terribly confusing to new users...and annoying to everyone. -- 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-2979) Cross module dependencies for multi-module site
[ http://jira.codehaus.org/browse/MNG-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2979: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x Can you check this with 2.0.8? Seems like it might be related to MNG-2277 > Cross module dependencies for multi-module site > --- > > Key: MNG-2979 > URL: http://jira.codehaus.org/browse/MNG-2979 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.5 > Environment: Linux 2.6.18-gentoo-r6 #2 SMP PREEMPT Wed Feb 28 > 10:25:50 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux >Reporter: Wally Wallou >Priority: Minor > Fix For: 2.0.x > > Attachments: gwttk-m2.zip, package.txt, site.txt > > > Considering a multi-module project A which declares two sub-projects > (modules) B and C. Having module C indicating in its POM a dependency against > module B. Compilation and packaging work great without having to install > module B in maven local repository, it locate module B for module C using > declared aggregation at top level project A. > But for site goals it does not work, that is to say when maven try to > generate site for module C it tells that module B artifact cannot be found. > So we have to install module B to be able to generate module C site, whereas > it is not necessary for compile or package goals. > I think it would be great if site goals behaves like compile and package with > aggregation. It would be more coherent, and avoid to have to run install just > for site 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] Commented: (MJAVADOC-162) javadocExecutable unusable
[
http://jira.codehaus.org/browse/MJAVADOC-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126243
]
Wendy Smoak commented on MJAVADOC-162:
--
Vincent, you marked this for 2.4 back in January. Are you planning to work on
it, or should we bump it to 2.5? I'd like to stage 2.4 this weekend.
> javadocExecutable unusable
> --
>
> Key: MJAVADOC-162
> URL: http://jira.codehaus.org/browse/MJAVADOC-162
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows XP and non-Windows
>Reporter: Greg Thompson
> Fix For: 2.4
>
>
> AbstractJavadocMojo tries to be smart by seeing if the file indicated by
> javadocExecutable exists, but this is actually quite problematic. If you put
> the following in your config:
> blahblahblah${file.separator}javadoc
> then you'll get an error on Windows since the file is actually javadoc.exe,
> which is a pain since it's perfectly acceptable to omit the .exe when
> executing a command.
> If you put .exe in the config, then it won't work on non-Windows platforms
> since the files doesn't have .exe.
> Forcing users to add hackery to their POMs to add .exe in some cases and
> leave it off in others is onerous.
> Methinks it's much preferable to simply use the path provided by the config.
> If it doesn't exist, let CommandLineUtils.executeCommandLine (or something
> else) throw an exception.
--
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-3415) Transfer errors cause junk metadata in the local repo
[ http://jira.codehaus.org/browse/MNG-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3415: -- Attachment: MNG-3415.diff no time to test it today - but I think this patch would resolve this issue > Transfer errors cause junk metadata in the local repo > - > > Key: MNG-3415 > URL: http://jira.codehaus.org/browse/MNG-3415 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > Attachments: MNG-3415.diff > > > I see this all the time and I swear there was an issue for it, but now I > can't find it. Sometimes there is metadata in the repo, usually after an > offline build or a build where something went wrong downloading artifacts. > Maven will apparently decide based on the metadata that the file can never be > found and will simply fail on a missing artifact. You can tell this has > happened because no attempt has actually been made to download the artifact > from a repository. Subsequent clearing of (portions) the localrepo fixes the > issue. This is terribly confusing to new users...and annoying to everyone. -- 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-2994) Snapshot repositories are not checked when using ranges
[ http://jira.codehaus.org/browse/MNG-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2994: --- Affects Version/s: (was: 2.0.6) 2.0.10 > Snapshot repositories are not checked when using ranges > --- > > Key: MNG-2994 > URL: http://jira.codehaus.org/browse/MNG-2994 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.10 > Environment: Windows XP, Cygwin >Reporter: Mark Hobson >Assignee: Jason van Zyl > Fix For: Reviewed Pending Version Assignment > > Attachments: MNG-2994-2.patch, MNG-2994-3.patch, > MNG-2994-core-it.patch, patch.txt > > > The attached patch demonstrates the problem by adding it0121. If the test > repository has releases enabled, the test passes, when they are disabled, the > test fails. This appears to be due to DefaultArtifact.isSnapshot returning > false for unresolved ranges, thus causing snapshot repositories to be > disabled when resolving artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126241
]
Wendy Smoak commented on MJAVADOC-116:
--
As mentioned, I can't reproduce this with the attached example.
I'd like to stage the 2.4 release on Friday.
In order for this to be included, I need a sample project and steps to
reproduce the problem. Otherwise it will either be bumped to 2.5 or closed as
Cannot Reproduce. Thanks!
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: javadoc-plugin-test-case.zip, log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works 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] Updated: (MNG-3007) Resolving legacy dependency ignores transitive dependencies
[ http://jira.codehaus.org/browse/MNG-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3007: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x can we get a sample project? > Resolving legacy dependency ignores transitive dependencies > --- > > Key: MNG-3007 > URL: http://jira.codehaus.org/browse/MNG-3007 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.6 >Reporter: Dirk Olmes > Fix For: 2.0.x > > > Trying to resolve a dependency from a repo with legacy layout > (dist.codehaus.org) seems to ignore this dependency's transitive dependencies. > I stumbled over this issue while building mule: the xfire module depends on > jaxen which is available from dist.codehaus.org (legacy layout) and from > central (m2 repo layout). For xfire we need to have dist.codehaus.org in the > pom. > When pulling jaxen from the legacy layout all transitive dependencies, > although declared in the legacy pom, will not be included in this module's > dependencies. If I happen to have jaxen already fetched from central into my > local repo, the transitive dependencies will show up, causing the entire > build to fail. > IMHO the dependency resolution of m1 poms should consider that artifact's > transitive dependencies as it is the case with m2 poms. -- 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-3035) Maven caches missing snapshot dependencies, so further builds fail without checking the repo until the cache expires or -U is included to flush the cache
[ http://jira.codehaus.org/browse/MNG-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3035: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x > Maven caches missing snapshot dependencies, so further builds fail without > checking the repo until the cache expires or -U is included to flush the cache > - > > Key: MNG-3035 > URL: http://jira.codehaus.org/browse/MNG-3035 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.5 >Reporter: Tom Parker >Priority: Minor > Fix For: 2.0.x > > Attachments: MNG-3035.zip > > > The problem is caused by a slightly obscure sequence, in this example, I use > two projects, Server & Common. Server depends on Common: > Alice updates Server to depend on Common-1.2-SNAPSHOT instead of 1.1-SNAPSHOT > and commits that change. > Bob syncs that change and attempts a build of Server, maven checks for > Common-1.2-SNAPSHOT in the local repo, finds it missing and checks the global > repo, where it is also missing. Maven records this information in a cache and > fails the build. > Alice deploys Common-1.2-SNAPSHOT to the global repo. > Bob attempts to build Server again, maven checks it's cached information and > finds that Common-1.2-SNAPSHOT wasn't in the global repo last time, so fails > the build. > Maven should not fail the build due to missing dependencies simply because > the cache says the dependency was missing last time. It should check the > configured repos before failing. -- 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: (MJAVADOC-137) javadoc:javadoc always runs as "aggregator"
[ http://jira.codehaus.org/browse/MJAVADOC-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MJAVADOC-137. Resolution: Fixed > javadoc:javadoc always runs as "aggregator" > --- > > Key: MJAVADOC-137 > URL: http://jira.codehaus.org/browse/MJAVADOC-137 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Peter Hendriks >Priority: Critical > Fix For: 2.4 > > > In version 2.2, javadoc aggregation was configurable using the configuration > property "aggregate". In version 2.3, all javadoc goals got the @aggregator > attribute added to its mojos (through a change in > org/apache/maven/plugin/javadoc/AbstractJavadocMojo.java), and the goals now > always run aggregated regardless of the configuration setting. This breaks > our build as we require non-aggregated javadoc execution in our multi-module > poms. Please fix this so this is once again configurable and backwards > compatible with previous versions of the javadoc plug-in. -- 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-3144) Snapshots not updated when using uniqueVersion false
[ http://jira.codehaus.org/browse/MNG-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3144: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x > Snapshots not updated when using uniqueVersion false > > > Key: MNG-3144 > URL: http://jira.codehaus.org/browse/MNG-3144 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.7 >Reporter: Nicky Sandhu >Priority: Critical > Fix For: 2.0.x > > > The particular scenario here is > 1.) Deploy snapshot using uniqueVersion false in distribution management > 2.) Verify repository has latest snapshot and metadata is updated in build > number and timestamp > 3. ) Goto a developer's machine (not the same as from which it was deployed) > and do mvn -U or specify updates to be always in pom > 4.) Local cache shows the maven metadata xml file is updated but the snapshot > artifact (jar in this case) is not -- 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-1968) allow disabling of plugin version discovery
[ http://jira.codehaus.org/browse/MNG-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox reopened MNG-1968: Actually we should keep this for 2.1. In 2.1, we should require plugin versions for everything, have them defaulted in the superpom like 2.0. Auto update should only be used for invoking cli goals and only if there isn't already a version specified in plugins/pluginManagement > allow disabling of plugin version discovery > --- > > Key: MNG-1968 > URL: http://jira.codehaus.org/browse/MNG-1968 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 2.1 > > > for verifying reproducibility (and enable it on release:perform) -- 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-3441) Maven should always retrieve metadata to be updated from the deployment repository
[ http://jira.codehaus.org/browse/MNG-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3441. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 2.0.9 > Maven should always retrieve metadata to be updated from the deployment > repository > -- > > Key: MNG-3441 > URL: http://jira.codehaus.org/browse/MNG-3441 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.0.9 > > > Currently Maven will still use a mirror if available - however this can > result in the wrong metadata being used and deployed to the repository. -- 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-1968) allow disabling of plugin version discovery
[ http://jira.codehaus.org/browse/MNG-1968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-1968. -- Resolution: Duplicate duplicate / resolved by mng-3395 > allow disabling of plugin version discovery > --- > > Key: MNG-1968 > URL: http://jira.codehaus.org/browse/MNG-1968 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Plugins and Lifecycle >Reporter: Brett Porter > Fix For: 2.1 > > > for verifying reproducibility (and enable it on release:perform) -- 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-3078) artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but not saved to local repository
[ http://jira.codehaus.org/browse/MNG-3078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126238 ] Brian Fox commented on MNG-3078: can you make a sample IT for this? > artifact of packaging 'tar.gz' / dependency of type 'tar.gz downloaded, but > not saved to local repository > - > > Key: MNG-3078 > URL: http://jira.codehaus.org/browse/MNG-3078 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.6, 2.0.7 >Reporter: Peter Lynch >Priority: Critical > Fix For: 2.0.x > > > Using mvn deploy:deploy-file you can successfully upload a 'tar.gz' artifact > to a repository. > Example without classifier: > mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat > -Dversion=6.0.13 -Dpackaging=tar.gz -DrepositoryId=repo-central > -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ > -Dfile=apache-tomcat-6.0.13.tar.gz > Example with classifier > mvn deploy:deploy-file -DgroupId=org.apache.tomcat -DartifactId=apache-tomcat > -Dversion=6.0.13 -Dpackaging=tar.gz -Dclassifier=bin > -DrepositoryId=repo-central > -Durl=dav:http://repo.example.com:4000/maven-repos/repo-central/ > -Dfile=apache-tomcat-6.0.13.tar.gz > Once uploaded define a dependency in your pom to it. > Example without classifier > > pom > ... > > ... > > org.apache.tomcat > apache-tomcat > 6.0.13 > tar.gz > true > > ... > > ... > > Example with classifier > > pom > ... > > ... > > org.apache.tomcat > apache-tomcat > 6.0.13 > tar.gz > bin > true > > ... > > ... > > Now to reproduce the problem you could either do > mvn dependency:resolve > or > mvn assembly:assembly > (if the maven assembly plugin is configured with a dependency set that > unpacks this dependency for example) > > The reason I think this is a core bug and not an maven assembly plugin or > maven-dependency-plugin bug is because the problem happens in both of these > independent plugins. > When you run 'mvn dependency:resolve' you'll see that the dependency appears > downloaded but then the build fails with : > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > Missing: > -- > 1) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.tomcat > -DartifactId=apache-tomcat \ > -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz > -Dfile=/path/to/file > Alternatively, if you host your own repository you can deploy the file there: > mvn deploy:deploy-file -DgroupId=org.apache.tomcat > -DartifactId=apache-tomcat \ > -Dversion=6.0.13 -Dclassifier=bin -Dpackaging=tar.gz > -Dfile=/path/to/file \ >-Durl=[url] -DrepositoryId=[id] > Path to dependency: > 1) com.example:core:pom:1.0.0-A1-SNAPSHOT > 2) org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13 > -- > 1 required artifact is missing. > ... > ... and even stranger here is the log which proves the dependency was found > in the repo and downloaded, but NOT saved to local repository. > ... > [DEBUG] Trying repository repo-central > Downloading: > http://repo.example.com:4000/maven-repos/repo-central/org/apache/tomcat/apache-tomcat/6.0.13/apache-tomcat-6.0.13-bin.tar.gz > 5826K downloaded > [DEBUG] Unable to get resource > 'org.apache.tomcat:apache-tomcat:tar.gz:bin:6.0.13' from repository > repo-central (http://repo.example.com:4000/maven-repos/repo-central) > [DEBUG] Unable to download the artifact from any repository > ..and YOU MAY GET FOOLED into thinking all is well. mvn deploy:deploy-file > also installs the same artifact into your local repo. So if you follow above > steps and don't get an error it is because the deploy-file goal installed it > in your local repo. However when someone else tries to use your project they > will get above error. > So, first delete from your local repo. example: > rm -rf ~/.m2/repository/org/apache/tomcat/apache-tomcat > and then try to execute mvn dependency:resolve and it should fail as > described. > ...and finally I'll mention that doing the same thing with a 'zip' > type/packaging there is NO PROBLEM. > Ultimately when using the maven assembly plugin I should be able to specify > any type of dependency type supported by the maven assembly archiver. -- This message is automatically generated by JIRA. - If you think i
[jira] Commented: (MNG-3144) Snapshots not updated when using uniqueVersion false
[ http://jira.codehaus.org/browse/MNG-3144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126237 ] Brian Fox commented on MNG-3144: I'm sure this is working as we are using uniqueVersion=false. Are you using some kind of proxy? > Snapshots not updated when using uniqueVersion false > > > Key: MNG-3144 > URL: http://jira.codehaus.org/browse/MNG-3144 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.7 >Reporter: Nicky Sandhu >Priority: Critical > Fix For: Reviewed Pending Version Assignment > > > The particular scenario here is > 1.) Deploy snapshot using uniqueVersion false in distribution management > 2.) Verify repository has latest snapshot and metadata is updated in build > number and timestamp > 3. ) Goto a developer's machine (not the same as from which it was deployed) > and do mvn -U or specify updates to be always in pom > 4.) Local cache shows the maven metadata xml file is updated but the snapshot > artifact (jar in this case) is not -- 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-3411) got the error like(Searching repository for plugin with prefix: 'archetype',repository is black listed,The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not e
[ http://jira.codehaus.org/browse/MNG-3411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3411. -- Resolution: Duplicate This is caused by junk metadata in your repo. > got the error like(Searching repository for plugin with prefix: > 'archetype',repository is black listed,The plugin > 'org.apache.maven.plugins:maven-archetype-plugin' does not exits) > --- > > Key: MNG-3411 > URL: http://jira.codehaus.org/browse/MNG-3411 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Command Line >Affects Versions: 2.0.8 >Reporter: R >Priority: Blocker > > I start maven to use in my project but I got the errors Please help to solve > this. > C:\Documents and Settings\rahult4\Desktop>mvn archetype:create > -DgroupId=com.myc > ompany.app -DartifactId=my-app > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] The plugin 'org.apache.maven.plugins:maven-archetype-plugin' does not > exi > st or no valid version could be found > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: < 1 second > [INFO] Finished at: Tue Feb 19 16:27:14 IST 2008 > [INFO] Final Memory: 1M/2M > [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] Updated: (MNG-3415) Transfer errors cause junk metadata in the local repo
[ http://jira.codehaus.org/browse/MNG-3415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3415: --- Assignee: John Casey Fix Version/s: 2.0.9 > Transfer errors cause junk metadata in the local repo > - > > Key: MNG-3415 > URL: http://jira.codehaus.org/browse/MNG-3415 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brian Fox >Assignee: John Casey > Fix For: 2.0.9 > > > I see this all the time and I swear there was an issue for it, but now I > can't find it. Sometimes there is metadata in the repo, usually after an > offline build or a build where something went wrong downloading artifacts. > Maven will apparently decide based on the metadata that the file can never be > found and will simply fail on a missing artifact. You can tell this has > happened because no attempt has actually been made to download the artifact > from a repository. Subsequent clearing of (portions) the localrepo fixes the > issue. This is terribly confusing to new users...and annoying to everyone. -- 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-2928) Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,)
[ http://jira.codehaus.org/browse/MNG-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2928. -- Resolution: Cannot Reproduce Can't reproduce. If this is still occuring in 2.0.8/2.0.9 please reopen with a test project. > Null pointer exeception when introducing version range > [major.minor.build-SNAPSHOT,) > > > Key: MNG-2928 > URL: http://jira.codehaus.org/browse/MNG-2928 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: MAC OS X >Reporter: Dennis Schafroth >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: build.txt, pom.xml, pom.xml > > > Due to selection of "wrong" version of a library (SystemResultDomain 1.0.2), > an "hard-limit" was introduced on one project forcing the build to use at > least 1.0.4-SNAPSHOT). All others are soft versions, so I dont see an > inconsistency. > The dependency check fails with: > [DEBUG] > com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.2:compile (selected > for compile) > ... > [DEBUG] SystemResultDomain: resolved to version 1.0.4-20070402.154234-1 from > repository mobilepeople > [DEBUG] > com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.4-SNAPSHOT:compile > (setting version to: 1.0.4-SNAPSHOT from range: [1.0.4-SNAPSHOT,) > ) > [DEBUG] > com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.4-SNAPSHOT:compile > (removed - nearer found: null) > ... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for com.mobilepeople.resultdomain:SystemResultDomain > [INFO] > > [DEBUG] Trace > java.lang.NullPointerException: version was null for > com.mobilepeople.resultdomain:SystemResultDomain > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:118) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:96) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [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] Commented: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126231
]
Brian Fox commented on MNG-3438:
got a sample or scm url for xwiki to reproduce?
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:331)
> at org.apache.
[jira] Closed: (MNG-3372) dependency:tree throws exception
[ http://jira.codehaus.org/browse/MNG-3372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3372. -- Resolution: Cannot Reproduce Fix Version/s: (was: 2.0.9) Not able to reproduce this. > dependency:tree throws exception > > > Key: MNG-3372 > URL: http://jira.codehaus.org/browse/MNG-3372 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Simon Kitching >Assignee: Brian Fox > Attachments: pom.xml > > > Running >mvn -Papache > org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree > on a pom containing the following entry throws an exception, unless an > exclusion is applied as shown below. > > jasperreports > jasperreports > 2.0.0 > compile > > > > commons-digester > > commons-digester > > > xml-apis > xml-apis > > > eclipse > jdtcore > > > > > commons-digester > commons-digester > 1.8 > compile > > Exception: > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) > at > org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.flushDependencyManagement(DependencyTreeResolutionListener.java:524) > at > org.apache.maven.shared.dependency.tree.DependencyTreeResolutionListener.omitForNearer(DependencyTreeResolutionListener.java:209) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:487) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:462) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:234) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:370) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:370) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:76) > at > org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:102) > at > org.apache.maven.plugin.dependency.TreeMojo.execute(TreeMojo.java:218) > My uneducated guess is that for that particular version of the dependency, > neither the dependency's pom nor any parent pom defines a version for > commons-digester. > PS: dependency:tree rocks! -- 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-2635) DefaultArtifactCollector.recurse can lose versionRange
[
http://jira.codehaus.org/browse/MNG-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126226
]
Brian Fox commented on MNG-2635:
Can you see if this still occurs in later versions? The code is different and
without a test to validate, I don't want to just throw changes in here.
> DefaultArtifactCollector.recurse can lose versionRange
> --
>
> Key: MNG-2635
> URL: http://jira.codehaus.org/browse/MNG-2635
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
> Environment: Linux
>Reporter: Bud Osterberg
>Assignee: Brian Fox
> Fix For: Reviewed Pending Version Assignment
>
> Attachments: artifact_patch
>
>
> This affects maven 2.0.4 and 2.0.5 (at least).
> I'm not quite sure how to reproduce the bug in a simple test case, but we
> have a setup where running the command:
> mvn install site source:jar
> crashes in ArtifactUtils.copyArtifact because artifact.getVersionRange()
> returns null.
> The code that seems to be causing the problem is in
> DefaultArtifactCollector.recurse(). Because the Artifact sets the version in
> setVersionRange, but can't set the VersionRange from setVersion, the
> VersionRange should take precedence if it exists. A simple diff follows:
> Index:
> components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
> ===
> ---
> components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
> (revision 467177)
> +++
> components/maven-artifact/src/main/java/org/apache/maven/artifact/resolver/DefaultArtifactCollector.java
> (working copy)
> @@ -114,8 +114,13 @@
>
> fireEvent( ResolutionListener.MANAGE_ARTIFACT, listeners, node,
> artifact );
>
> -if ( artifact.getVersion() != null )
> +VersionRange range = artifact.getVersionRange();
> +if (range != null)
> {
> + node.getArtifact().setVersionRange(range);
> +}
> +else if ( artifact.getVersion() != null )
> +{
> node.getArtifact().setVersion( artifact.getVersion() );
> }
> if ( artifact.getScope() != null )
--
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-2928) Null pointer exeception when introducing version range [major.minor.build-SNAPSHOT,)
[ http://jira.codehaus.org/browse/MNG-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2928: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.9 this is not a dup of MNG-2123 > Null pointer exeception when introducing version range > [major.minor.build-SNAPSHOT,) > > > Key: MNG-2928 > URL: http://jira.codehaus.org/browse/MNG-2928 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 > Environment: MAC OS X >Reporter: Dennis Schafroth > Fix For: 2.0.9 > > Attachments: build.txt, pom.xml, pom.xml > > > Due to selection of "wrong" version of a library (SystemResultDomain 1.0.2), > an "hard-limit" was introduced on one project forcing the build to use at > least 1.0.4-SNAPSHOT). All others are soft versions, so I dont see an > inconsistency. > The dependency check fails with: > [DEBUG] > com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.2:compile (selected > for compile) > ... > [DEBUG] SystemResultDomain: resolved to version 1.0.4-20070402.154234-1 from > repository mobilepeople > [DEBUG] > com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.4-SNAPSHOT:compile > (setting version to: 1.0.4-SNAPSHOT from range: [1.0.4-SNAPSHOT,) > ) > [DEBUG] > com.mobilepeople.resultdomain:SystemResultDomain:jar:1.0.4-SNAPSHOT:compile > (removed - nearer found: null) > ... > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for com.mobilepeople.resultdomain:SystemResultDomain > [INFO] > > [DEBUG] Trace > java.lang.NullPointerException: version was null for > com.mobilepeople.resultdomain:SystemResultDomain > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:364) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:225) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:118) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:96) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [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] Closed: (MNG-3086) NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
[ http://jira.codehaus.org/browse/MNG-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-3086. -- Resolution: Fixed Fixed. See comments in MNG-2123 for possible workaround in the meantime. > NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) > > > Key: MNG-3086 > URL: http://jira.codehaus.org/browse/MNG-3086 > Project: Maven 2 > Issue Type: Bug > Components: Ant tasks >Affects Versions: 2.0.7 >Reporter: Thomas Leonard >Assignee: Brian Fox > Fix For: 2.0.9 > > > After upgrading from 2.0.6 to 2.0.7, our build fails with: > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136) > at > org.apache.maven.artifact.resolver.ResolutionNode.filterTrail(ResolutionNode.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:89) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > 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) > Thanks, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2123. -- Resolution: Fixed Fixed so that the correct version is selected from the range, without shoving RELEASE anywhere. The issue only happened if the first instance of the offending artifact was not a range, but the second instance was. Based on my unit testing, reversing the order of your dependencies in the pom should work around this until 2.0.9 > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-2123 > URL: http://jira.codehaus.org/browse/MNG-2123 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2, 2.0.3, 2.0.4 >Reporter: Carlos Sanchez >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: MNG-2123-maven-artifact.patch, > mng2123_versionRangeDependency.tar.bz2, pom.xml > > Original Estimate: 4 hours > Time Spent: 8 hours > Remaining Estimate: 0 minutes > > Struts 1.2.7 depends on commons-digester 1.6 and jasperreports 1.1.1 in [1.7,) > Build fails with a null pointer exception that is not very explanatory > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:test:jar:1.0-SNAPSHOT > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:361) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:222) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:115) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:88) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] >
[jira] Work logged: (MNG-2123) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
[ http://jira.codehaus.org/browse/MNG-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#action_112324 ] Brian Fox logged work on MNG-2123: -- Author: Brian Fox Created on: 05/Mar/08 07:05 PM Start Date: 05/Mar/08 07:05 PM Worklog Time Spent: 8 hours Issue Time Tracking --- Time Spent: 8 hours Remaining Estimate: 0 minutes (was: 4 hours) > NullPointerException when a dependency uses version range and another uses an > actual version incompatible with that range > - > > Key: MNG-2123 > URL: http://jira.codehaus.org/browse/MNG-2123 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.2, 2.0.3, 2.0.4 >Reporter: Carlos Sanchez >Assignee: Brian Fox > Fix For: 2.0.9 > > Attachments: MNG-2123-maven-artifact.patch, > mng2123_versionRangeDependency.tar.bz2, pom.xml > > Original Estimate: 4 hours > Time Spent: 8 hours > Remaining Estimate: 0 minutes > > Struts 1.2.7 depends on commons-digester 1.6 and jasperreports 1.1.1 in [1.7,) > Build fails with a null pointer exception that is not very explanatory > [INFO] Scanning for projects... > [INFO] > > [INFO] Building Unnamed - test:test:jar:1.0-SNAPSHOT > [INFO]task-segment: [test] > [INFO] > > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] version was null for commons-digester:commons-digester > [INFO] > > [INFO] Trace > java.lang.NullPointerException: version was null for > commons-digester:commons-digester > at > org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:361) > at > org.apache.maven.artifact.DefaultArtifact.getId(DefaultArtifact.java:222) > at > org.apache.maven.artifact.resolver.ResolutionNode.getDependencyTrail(ResolutionNode.java:115) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:88) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:223) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:182) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1117) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:366) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] > > [INFO] To
[jira] Closed: (MNG-3433) [regression] Integration test it0074 is broken
[ http://jira.codehaus.org/browse/MNG-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3433. --- Resolution: Fixed Fixed the backward compat aspect to add imports for Xpp3Dom. > [regression] Integration test it0074 is broken > -- > > Key: MNG-3433 > URL: http://jira.codehaus.org/browse/MNG-3433 > Project: Maven 2 > Issue Type: Bug > Components: integration tests >Affects Versions: 2.1-alpha-1 >Reporter: Brett Porter >Assignee: John Casey > Fix For: 2.1-alpha-1 > > > This is currently being demonstrated locally and in Continuum. > The error starts with: > org.apache.maven.it.VerificationException: Exit code was > non-zero: 100; log = > + Error stacktraces are turned on. > WAGON_VERSION: 1.0-beta-2 > [INFO] Attempting to resolve a version for plugin: > org.apache.maven.plugins:maven-compiler-plugin using meta-version: LATEST > [INFO] Using version: 2.1-SNAPSHOT of plugin: > org.apache.maven.plugins:maven-compiler-plugin > [INFO] Searching repository for plugin with prefix: 'clean'. > [INFO] Attempting to resolve a version for plugin: > org.apache.maven.plugins:maven-clean-plugin using meta-version: LATEST > [INFO] Using version: 2.3-SNAPSHOT of plugin: > org.apache.maven.plugins:maven-clean-plugin > [INFO] Attempting to resolve a version for plugin: > org.apache.maven.plugins:maven-eclipse-plugin using meta-version: LATEST > [INFO] artifact org.apache.maven.plugins:maven-eclipse-plugin: checking for > updates from central > [INFO] Using version: 2.5-SNAPSHOT of plugin: > org.apache.maven.plugins:maven-eclipse-plugin > [INFO] Scanning for projects... > [INFO] Starting forked execution [fork id: 2000253950] > [INFO] Compiling 1 source file to /var/tmp/it0074/target/classes > [INFO] Ending forked execution [fork id: 2000253950] > [INFO] Using as WTP server : null > [INFO] Adding default classpath contaigner: > org.eclipse.jdt.launching.JRE_CONTAINER > [INFO] Using source status cache: > /var/tmp/it0074/target/mvn-eclipse-cache.properties > --- > constituent[0]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-core-2.1-SNAPSHOT.jar > constituent[1]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-lifecycle-2.1-SNAPSHOT.jar > constituent[2]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/backport-util-concurrent-3.0.jar > constituent[3]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/jcl104-over-slf4j-1.5.0.jar > constituent[4]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-workspace-2.1-SNAPSHOT.jar > constituent[5]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-container-default-1.0-alpha-44.jar > constituent[6]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-common-1.0-beta-2.jar > constituent[7]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/doxia-sink-api-1.0-alpha-9.jar > constituent[8]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-utils-1.4.5.jar > constituent[9]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/xml-im-exporter-1.1.jar > constituent[10]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-http-shared-1.0-beta-2.jar > constituent[11]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/commons-cli-1.0.jar > constituent[12]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/jsch-0.1.27.jar > constituent[13]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/wagon-ssh-1.0-beta-2.jar > constituent[14]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/slf4j-simple-1.5.0.jar > constituent[15]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/maven-profile-2.1-SNAPSHOT.jar > constituent[16]: > file:/export/home/build/data/continuum/checkouts/514/target/maven-installation/apache-maven-2.1-SNAPSHOT/lib/plexus-interactivity-api-1.0-alpha-6.jar
[jira] Created: (MNG-3441) Maven should always retrieve metadata to be updated from the deployment repository
Maven should always retrieve metadata to be updated from the deployment repository -- Key: MNG-3441 URL: http://jira.codehaus.org/browse/MNG-3441 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Brett Porter Currently Maven will still use a mirror if available - however this can result in the wrong metadata being used and deployed to the repository. -- 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: (MPIR-85) Refactoring of dependency and dependency management report
[ http://jira.codehaus.org/browse/MPIR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Stolwijk updated MPIR-85: -- Attachment: refactor.patch Contains the Plugin, Artifact and Dependency Comparators for the refactoring, with unit tests. > Refactoring of dependency and dependency management report > -- > > Key: MPIR-85 > URL: http://jira.codehaus.org/browse/MPIR-85 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Stolwijk > Attachments: comparators.patch, refactor.patch, refactor.patch > > > I've tried to refactor the code from MPIR-83 a bit, because it used a lot of > copied code. > Important improvements: > - Created a AbstractProjectInfoRenderer and AbstractDependencyRenderer. > If this patch is accepted, I want to write all the renderers out of the > inforeports in separate classes, with more code sharing. This is a start of > that. > - I changed the unit tests, because the expected and actual were reversed. > This is the case in many of the info report unit tests. > Please tell me what you think of it. I know it is only a start. -- 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: (MPIR-85) Refactoring of dependency and dependency management report
[ http://jira.codehaus.org/browse/MPIR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Stolwijk updated MPIR-85: -- Attachment: comparators.patch And now the right file. ;) Added comparators and unit test for them in comparators.patch > Refactoring of dependency and dependency management report > -- > > Key: MPIR-85 > URL: http://jira.codehaus.org/browse/MPIR-85 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Nick Stolwijk > Attachments: comparators.patch, refactor.patch, refactor.patch > > > I've tried to refactor the code from MPIR-83 a bit, because it used a lot of > copied code. > Important improvements: > - Created a AbstractProjectInfoRenderer and AbstractDependencyRenderer. > If this patch is accepted, I want to write all the renderers out of the > inforeports in separate classes, with more code sharing. This is a start of > that. > - I changed the unit tests, because the expected and actual were reversed. > This is the case in many of the info report unit tests. > Please tell me what you think of it. I know it is only a start. -- 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-3439) incorrect child dependency selected when parent is not selected
[
http://jira.codehaus.org/browse/MNG-3439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-3439.
--
Assignee: Brian Fox
Resolution: Fixed
Fix Version/s: 2.0.9
this is a bug in the mock source object. Should not affect runtime.
> incorrect child dependency selected when parent is not selected
> ---
>
> Key: MNG-3439
> URL: http://jira.codehaus.org/browse/MNG-3439
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.8
>Reporter: Brian Fox
>Assignee: Brian Fox
> Fix For: 2.0.9
>
>
> I'm writing unit tests to reproduce MNG-2123 and I found a separate issue. I
> did the following
> a 1.0 ->b 1.0->c3.2->d1.1
> a 1.0 ->e1.0->c[1.0,3.0]->d1.0
> The available versions are c2.5,c3.2,d1.0,d1.1
> The resulting list is including d1.1 not 1.0
> d1.1 comes from the c3.2 which is not included, c2.5 was and thus d1.0 should
> have been.
> {noformat}
> public void testCompatibleRecommendedVersionWithChildren()
> throws ArtifactResolutionException,
> InvalidVersionSpecificationException
> {
> // this test puts two dependencies on C with 3.2 and [1.0,3.0] as the
> version.
> // it puts 2.5 in the pretend repo...we should get back 2.5
> ArtifactSpec a = createArtifactSpec( "a", "1.0" );
> ArtifactSpec b = a.addDependency( "b", "1.0" );
> ArtifactSpec e = a.addDependency( "e", "1.0" );
> ArtifactSpec c1 = b.addDependency( "c", "3.2" );
> ArtifactSpec d1 = c1.addDependency( "d","1.1" );
> e.addDependency( "c", "[1.0,3.0]" );
> // put it in the repo
> ArtifactSpec c = createArtifactSpec( "c", "2.5" );
> ArtifactSpec d = c.addDependency( "d","1.0" );
>
> source.addArtifact( c );
> source.addArtifact( d );
> source.addArtifact( c1 );
> source.addArtifact( d1 );
> ArtifactResolutionResult res = collect( a );
> assertEquals( "Check artifact list",
> createSet( new Object[] { a.artifact, b.artifact,
> e.artifact, c.artifact,d.artifact } ), res.getArtifacts() );
> assertEquals( "Check version", "2.5", getArtifact( "c",
> res.getArtifacts() ).getVersion() );
> }
> {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] Closed: (MNG-3440) artifact comparison should compare versions using normal version comparison logic
[ http://jira.codehaus.org/browse/MNG-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3440. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 2.1-alpha-1 > artifact comparison should compare versions using normal version comparison > logic > - > > Key: MNG-3440 > URL: http://jira.codehaus.org/browse/MNG-3440 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1-alpha-1 > > -- 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-292) Ability to overwrite existing files regardless of timestamp
Ability to overwrite existing files regardless of timestamp --- Key: MASSEMBLY-292 URL: http://jira.codehaus.org/browse/MASSEMBLY-292 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Affects Versions: 2.2-beta-2 Reporter: Herbert Hui Request to have an attribute in assembly descriptor that will overwrite existing files regardless of timestamp if set to true. Current behavior overwrites existing file only if existing file has an older date modified timestamp. Only workaround I'm aware of is to not use the assembly plugin and use ant copy task through the maven ant plugin. Example (overwrite attribute in fileset): assemble-data seed true ../../dist/data/seed -- 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-3440) artifact comparison should compare versions using normal version comparison logic
artifact comparison should compare versions using normal version comparison logic - Key: MNG-3440 URL: http://jira.codehaus.org/browse/MNG-3440 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Brett Porter -- 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-3439) incorrect child dependency selected when parent is not selected
incorrect child dependency selected when parent is not selected
---
Key: MNG-3439
URL: http://jira.codehaus.org/browse/MNG-3439
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 2.0.8
Reporter: Brian Fox
I'm writing unit tests to reproduce MNG-2123 and I found a separate issue. I
did the following
a 1.0 ->b 1.0->c3.2->d1.1
a 1.0 ->e1.0->c[1.0,3.0]->d1.0
The available versions are c2.5,c3.2,d1.0,d1.1
The resulting list is including d1.1 not 1.0
d1.1 comes from the c3.2 which is not included, c2.5 was and thus d1.0 should
have been.
{noformat}
public void testCompatibleRecommendedVersionWithChildren()
throws ArtifactResolutionException, InvalidVersionSpecificationException
{
// this test puts two dependencies on C with 3.2 and [1.0,3.0] as the
version.
// it puts 2.5 in the pretend repo...we should get back 2.5
ArtifactSpec a = createArtifactSpec( "a", "1.0" );
ArtifactSpec b = a.addDependency( "b", "1.0" );
ArtifactSpec e = a.addDependency( "e", "1.0" );
ArtifactSpec c1 = b.addDependency( "c", "3.2" );
ArtifactSpec d1 = c1.addDependency( "d","1.1" );
e.addDependency( "c", "[1.0,3.0]" );
// put it in the repo
ArtifactSpec c = createArtifactSpec( "c", "2.5" );
ArtifactSpec d = c.addDependency( "d","1.0" );
source.addArtifact( c );
source.addArtifact( d );
source.addArtifact( c1 );
source.addArtifact( d1 );
ArtifactResolutionResult res = collect( a );
assertEquals( "Check artifact list",
createSet( new Object[] { a.artifact, b.artifact,
e.artifact, c.artifact,d.artifact } ), res.getArtifacts() );
assertEquals( "Check version", "2.5", getArtifact( "c",
res.getArtifacts() ).getVersion() );
}
{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] Updated: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3438:
--
Fix Version/s: 2.0.9
I presume this worked in 2.0.8?
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:331)
> at org.apache.maven.Defaul
[jira] Closed: (MAVENUPLOAD-1925) please upload DynamicJasper 2.0.5
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Manuel Alvarez closed MAVENUPLOAD-1925. Resolution: Fixed bundle fixed in version 2.0.7, please continue upload process in http://jira.codehaus.org/browse/MAVENUPLOAD-1956 > please upload DynamicJasper 2.0.5 > - > > Key: MAVENUPLOAD-1925 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1925 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Juan Manuel Alvarez > > http://dynamicjasper.sourceforge.net/downloads/DynamicJasper-2.0.5-bundle.jar > http://dynamicjasper.sourceforge.net/ > http://dynamicjasper.sourceforge.net/team-list.html > I am DynamicJasper's project leader, please upload. > DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it > helps developers to save time when designing simple/medium complexity reports > generating the layout of the report elements automatically. It creates > reports dynamically, defining at runtime the columns, column width (auto > width), groups, variables, fonts, charts, crosstabs, sub reports (that can > also be dynamic), page size and everything else that you can define at design > time. -- 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-1956) please upload DynamicJasper 2.0.7
please upload DynamicJasper 2.0.7 - Key: MAVENUPLOAD-1956 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1956 Project: maven-upload-requests Issue Type: Wish Reporter: Juan Manuel Alvarez http://dynamicjasper.sourceforge.net/DynamicJasper-2.0.7-bundle.jar http://dynamicjasper.sourceforge.net/ http://dynamicjasper.sourceforge.net/team-list.html I am DynamicJasper's project leader, please upload. DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it helps developers to save time when designing simple/medium complexity reports generating the layout of the report elements automatically. It creates reports dynamically, defining at runtime the columns, column width (auto width), groups, variables, fonts, charts, crosstabs, sub reports (that can also be dynamic), page size and everything else that you can define at design time. -- 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-291) attach the resulting assembly not working as expected
attach the resulting assembly not working as expected - Key: MASSEMBLY-291 URL: http://jira.codehaus.org/browse/MASSEMBLY-291 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Maven version: 2.0.8 Java version: 1.5.0_14 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: Vlad Skarzhevskyy After changing to 2.2-beta-2 attach is not working in our project. This is configuration used: project: pom maven-assembly-plugin: package single true false The idea is to replace main artifact jar with created jar. packaging pom has been selected base on example form the site. May be this is wrong but used to work in version 2.1. Full Project here: https://microemulator.svn.sourceforge.net/svnroot/microemulator/branches/microemulator_2_0_2/microemulator PS We also have second sources assembly in the same pom.xml This assembly is installed to local repository! -- 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-3355) CLONE -${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no longer recognized
[
http://jira.codehaus.org/browse/MNG-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MNG-3355:
---
Fix Version/s: 2.0.9
> CLONE -${pom.build.sourceDirectory} and ${pom.build.testSourceDirectory} no
> longer recognized
> -
>
> Key: MNG-3355
> URL: http://jira.codehaus.org/browse/MNG-3355
> Project: Maven 2
> Issue Type: Bug
> Components: POM
> Environment: n/a
>Reporter: Venelin Mitov
> Fix For: 2.0.9
>
> Attachments: buglet.zip
>
>
> The properties ${pom.build.sourceDirectory} and
> ${pom.build.testSourceDirectory} (and perhaps others as well) are no longer
> recognized in pom.xml. The following pom fragment had the desired effect of
> copying resources from the sourceDirectory in version 2.0.3, but doesn't work
> in 2.0.4:
>
> src
> src-test
>
>
> ${pom.build.sourceDirectory}
>
> **/*.properties
>
>
>
>
>
> ${pom.build.testSourceDirectory}
>
> **/mockfiles/
>
>
>
> The attached project will fail on a 'mvn test' under maven 2.0.4 and succeed
> under 2.0.3
--
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-3086) NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136)
[ http://jira.codehaus.org/browse/MNG-3086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3086: --- Fix Version/s: (was: 2.0.x) 2.0.9 > NullPointerException in ResolutionNode.getTrail(ResolutionNode.java:136) > > > Key: MNG-3086 > URL: http://jira.codehaus.org/browse/MNG-3086 > Project: Maven 2 > Issue Type: Bug > Components: Ant tasks >Affects Versions: 2.0.7 >Reporter: Thomas Leonard > Fix For: 2.0.9 > > > After upgrading from 2.0.6 to 2.0.7, our build fails with: > [INFO] [resources:resources] > [INFO] Using default encoding to copy filtered resources. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.ResolutionNode.getTrail(ResolutionNode.java:136) > at > org.apache.maven.artifact.resolver.ResolutionNode.filterTrail(ResolutionNode.java:211) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:89) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > 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) > Thanks, -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-80) Add Java requirements to the Dependency Report
[ http://jira.codehaus.org/browse/MPIR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126164 ] SebbASF commented on MPIR-80: - I'd like to suggest a change to the text in the Java dependency paragraph. instead of: This project requires a minimum of Java 1.3. it would read something like: Version xxx of this project requires a minimum of Java 1.3. Updated patch to follow. > Add Java requirements to the Dependency Report > -- > > Key: MPIR-80 > URL: http://jira.codehaus.org/browse/MPIR-80 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Niall Pemberton > Attachments: maven-projectinfo-dependency-java-v2.patch, > maven-projectinfo-dependency-java-v3.patch, > maven-projectinfo-dependency-java.patch, maven-projectinfo-summary-java.patch > > > It would be nice to add a section to the dependency report showing the java > version requirements. > Attaching a patch which discovers the java version and compiler options from > the java-compiler-plugin configuration and outputs a "Java Version" section. > Has an option to configure whether or not this section is shown (default to > false). -- 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: (MPIR-80) Add Java requirements to the Dependency Report
[ http://jira.codehaus.org/browse/MPIR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126155 ] Niall Pemberton commented on MPIR-80: - I don't have the karma to remove attachments > Add Java requirements to the Dependency Report > -- > > Key: MPIR-80 > URL: http://jira.codehaus.org/browse/MPIR-80 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Niall Pemberton > Attachments: maven-projectinfo-dependency-java-v2.patch, > maven-projectinfo-dependency-java-v3.patch, > maven-projectinfo-dependency-java.patch, maven-projectinfo-summary-java.patch > > > It would be nice to add a section to the dependency report showing the java > version requirements. > Attaching a patch which discovers the java version and compiler options from > the java-compiler-plugin configuration and outputs a "Java Version" section. > Has an option to configure whether or not this section is shown (default to > false). -- 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-3394) Plugin versions inherited via cannot be overriden by . section of sub modules
[ http://jira.codehaus.org/browse/MNG-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126154 ] John Casey commented on MNG-3394: - the *Management sections of the POM were originally designed to provide default values, not overrides. This behavior was changed for dependencies in MNG-1577 IIRC, but I don't know when the change was made for plugins. The behavior should probably be controlled in the class org.apache.maven.project.injection.DefaultModelDefaultsInjector.java (in maven-project). I've looked into this class in both 2.0.x and trunk, and they're the same...not sure whether that means the change happened before the split (unlikely) or was ported across (more likely), but in both cases it looks like it only uses the pluginManagement version if the main version is missing and the pluginManagement version is not. I'm not really sure what's going on here, but hopefully that can shed a little light on the background for this. > Plugin versions inherited via cannot be overriden by > . section of sub modules > > > Key: MNG-3394 > URL: http://jira.codehaus.org/browse/MNG-3394 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Priority: Critical > Fix For: 2.0.9 > > Attachments: plugin-management-version.zip > > > See the comments in the module POM of the attached demo project for more > explanation. -- 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-3438) IIncompatibleClassChangeError
IIncompatibleClassChangeError
-
Key: MNG-3438
URL: http://jira.codehaus.org/browse/MNG-3438
Project: Maven 2
Issue Type: Bug
Components: General
Affects Versions: 2.0.9
Reporter: Vincent Massol
This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
{noformat}
[INFO]
[INFO] Building XWiki Platform - Applications - Selenium
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean]
[INFO] Deleting directory
/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
[INFO] [remote-resources:process {execution: xwiki-license-resources}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[WARNING] Attempting to build MavenProject instance for Artifact
(com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
type: maven-plugin; constructing POM artifact instead.
[INFO] [xwiki-xar:xar]
[INFO] Generating package.xml descriptor at
[/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
[FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
(java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
realms:
[FATAL ERROR] Plugin realm =
app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
urls[0] =
file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
urls[1] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
urls[2] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
urls[3] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
urls[4] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
urls[5] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
urls[7] =
file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
[FATAL ERROR] Container realm = plexus.core
urls[0] =
file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
urls[1] =
file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
urls[2] =
file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.IncompatibleClassChangeError
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
at
org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
at
org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:331)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:124)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:285)
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.class
[jira] Closed: (MNG-3437) Always updating local repository from remote repository
[ http://jira.codehaus.org/browse/MNG-3437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3437. --- Assignee: John Casey Resolution: Won't Fix Released artifacts are considered by Maven to be immutable. Therefore, they are never subject to updates. The updateInterval in the releases section of the repository definition really pertains only to metadata about things like the RELEASE and LATEST meta-versions, which are normally used to resolve plugins when you don't specify their versions in your POM. As you said, changing a released artifact is a BAD BAD thing. > Always updating local repository from remote repository > --- > > Key: MNG-3437 > URL: http://jira.codehaus.org/browse/MNG-3437 > Project: Maven 2 > Issue Type: Improvement > Components: Settings >Reporter: sachin kamdar >Assignee: John Casey > > With the following settings in the settings.xml file, > > ... > > inhouse-repo > Inhouse M2 Repo > http://inhouse.maven.repo > > true > always > warn > > > ... > > * Dev A has a copy of demo-1.0.0.jar in his local repository > * Dev B makes a code change to demo project and packages the jar without > updating the version in the POM (which I think is a BAD BAD thing). > * Dev B then deploys a changed demo-1.0.0.jar into Inhouse Remote Repository. > * When Dev A does his next build, despite of the always > setting the local repository doesn't get the newer copy from the Inhouse > Remote Repository. > Is this kind of expected? Does maven only looks at the version number of an > artifact to determines if they are different? And if all this is true then > under what circumstances would always fetch a newer artifact? > Is there any way I can get Maven to always update an artifact from Inhouse > Remote Repository into the local repository even though the version numbers > are same? -- 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: (MPIR-80) Add Java requirements to the Dependency Report
[ http://jira.codehaus.org/browse/MPIR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126143 ] SebbASF commented on MPIR-80: - The dependencies page needs to list which version of the POM was used to provide the information. This is already listed on the project summary page. > Add Java requirements to the Dependency Report > -- > > Key: MPIR-80 > URL: http://jira.codehaus.org/browse/MPIR-80 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Niall Pemberton > Attachments: maven-projectinfo-dependency-java-v2.patch, > maven-projectinfo-dependency-java-v3.patch, > maven-projectinfo-dependency-java.patch, maven-projectinfo-summary-java.patch > > > It would be nice to add a section to the dependency report showing the java > version requirements. > Attaching a patch which discovers the java version and compiler options from > the java-compiler-plugin configuration and outputs a "Java Version" section. > Has an option to configure whether or not this section is shown (default to > false). -- 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: (MPIR-80) Add Java requirements to the Dependency Report
[ http://jira.codehaus.org/browse/MPIR-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126139 ] SebbASF commented on MPIR-80: - @Niall: if patch v2 is obsolete, perhaps it should be deleted... @all: IMO put the information in both dependencies and project-summary. > Add Java requirements to the Dependency Report > -- > > Key: MPIR-80 > URL: http://jira.codehaus.org/browse/MPIR-80 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Niall Pemberton > Attachments: maven-projectinfo-dependency-java-v2.patch, > maven-projectinfo-dependency-java-v3.patch, > maven-projectinfo-dependency-java.patch, maven-projectinfo-summary-java.patch > > > It would be nice to add a section to the dependency report showing the java > version requirements. > Attaching a patch which discovers the java version and compiler options from > the java-compiler-plugin configuration and outputs a "Java Version" section. > Has an option to configure whether or not this section is shown (default to > false). -- 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: (SUREFIRE-468) test timeout handling
test timeout handling - Key: SUREFIRE-468 URL: http://jira.codehaus.org/browse/SUREFIRE-468 Project: Maven Surefire Issue Type: Bug Components: plugin, process forking Affects Versions: 2.4.2 Reporter: A When forkmode is always/prtest (probably that could be true for the last test and forkmode once) when one test hangs and timeout occurs, est suite execution stops and report file for the offending test not generated. That could mislead somebody to think all tests passed if all tests before the offending one passed. AFAICT that should be synchronized between one of these: 1. CommandLineUtils.executeCommandLine() 2. SurefireBooter.fork() 3. SurefireBooter.run() 4. SurefirePlugin.execute() Probably fork must detect a timeout. Then the timeout be gracefully handled by generating a report file for the test. Then continue execution of remaining tests. -- 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-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:all-tabpanel
]
Arnaud Heritier closed MECLIPSE-395.
Assignee: Arnaud Heritier
Resolution: Fixed
Fix Version/s: 2.5
Fixed by passing new properties in surefire (org.apache.maven.global-settings
and org.apache.maven.user-settings)
> Plugin tests are failing due to a wrong local repository path.
> --
>
> Key: MECLIPSE-395
> URL: http://jira.codehaus.org/browse/MECLIPSE-395
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Arnaud Heritier
>Assignee: Arnaud Heritier
> Fix For: 2.5
>
>
> In a corporate environment, we have the local repository not located in the
> standard location (${user.home}/.m2/repository).
> This is set in settings passed to maven with properties
> org.apache.maven.user-settings and org.apache.maven.global-settings (our
> settings are also not located in the standard locations
> ${user.home}/.m2/settings.xml and ${maven.home}/conf/settings.xml).
> Instead of using my local repository defined in our global settings, eclipse
> integration tests are using ${user.home}/.m2/repository, thus don't find
> dependencies. For example :
> {code}
> Error getting POM for ...
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> testing.mainLocalAsRemote (file:/C:/Documents and
> Settings//.m2/repository)
> {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] Created: (MECLIPSE-395) Plugin tests are failing due to a wrong local repository path.
Plugin tests are failing due to a wrong local repository path.
--
Key: MECLIPSE-395
URL: http://jira.codehaus.org/browse/MECLIPSE-395
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.5
Reporter: Arnaud Heritier
In a corporate environment, we have the local repository not located in the
standard location (${user.home}/.m2/repository).
This is set in settings passed to maven with properties
org.apache.maven.user-settings and org.apache.maven.global-settings (our
settings are also not located in the standard locations
${user.home}/.m2/settings.xml and ${maven.home}/conf/settings.xml).
Instead of using my local repository defined in our global settings, eclipse
integration tests are using ${user.home}/.m2/repository, thus don't find
dependencies. For example :
{code}
Error getting POM for ...
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
testing.mainLocalAsRemote (file:/C:/Documents and
Settings//.m2/repository)
{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] Created: (MJAR-100) Release preparation fails because jar plugin skips packaging of test jar
Release preparation fails because jar plugin skips packaging of test jar
Key: MJAR-100
URL: http://jira.codehaus.org/browse/MJAR-100
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Environment: maven - 2.0.8
Reporter: Ashish Vashishta
The release preparation goals fails when run with -DskipTests=true. The failure
occurs because the jar plugin doesn't create the *.tests.jar. The jar plugin
being used is 2.2.
When same goal is run with previous jar plugin version (2.1), everything works
fine.
The comparison of outputs from these two run indicate this behaviour.
1. When run with jar plugin version 2.2, following information is printed on
console
[INFO] [jar:jar]
[INFO] Building jar: D:\..\abc.jar
[INFO] [jar:jar {execution: default}]
[INFO] [jar:test-jar {execution: default}]
[INFO] Skipping packaging of the test-jar
2. While when run with jar plugin version 2.1, following information is printed
on console
[INFO] [jar:jar]
[INFO] Building jar: D:\..\abc.jar
[INFO] [jar:jar {execution: default}]
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar: D:\..\abc-tests.jar
--
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: (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:comment-tabpanel#action_126115
]
iooi edited comment on MRELEASE-330 at 3/5/08 6:08 AM:
--
project structure - second try
the project structure got hosed apparently because jira did interpret it as
wiki mark up or such. Here's the second try:
{code}
AvE24All
|
+- Applications
| |
| +- AvE24
| |
| \- AvE24Backoffice
|
+- Frameworks
| |
| \- AvE24Data
|
+- Static
| |
| \- www.ave24.de
|
\- WebServices
|
\- AvE24WS
{code}
was (Author: iooi):
project structure - second try
the project structure got hosed apparently because jira did interpret it as
wiki mark up or such. Here's the second try:
{code}
AvE24All
|
+- Applications
| |
| +- AvE24
| |
| \- AvE24Backoffice
|
+- Frameworks
| |
| \- AvE24Data
|
+- Static
| |
| \- www.ave24.de
|
\- WebServices
|
\- AvE24WS
{/code}
> 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
>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.
[jira] Issue Comment Edited: (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:comment-tabpanel#action_126115
]
iooi edited comment on MRELEASE-330 at 3/5/08 6:06 AM:
--
project structure - second try
the project structure got hosed apparently because jira did interpret it as
wiki mark up or such. Here's the second try:
{code}
AvE24All
|
+- Applications
| |
| +- AvE24
| |
| \- AvE24Backoffice
|
+- Frameworks
| |
| \- AvE24Data
|
+- Static
| |
| \- www.ave24.de
|
\- WebServices
|
\- AvE24WS
{/code}
was (Author: iooi):
project structure - second try
the project structure got hosed apparently because jira did interpret it as
wiki mark up or such. Here's the second try:
{code}
AvE24All
|
+- Applications
| |
| +- AvE24
| |
| \- AvE24Backoffice
|
+- Frameworks
| |
| \- AvE24Data
|
+- Static
| |
| \- www.ave24.de
|
\- WebServices
|
\- AvE24WS
{/code}
> 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
>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:
[jira] Commented: (MPH-26) New goal help:help to provide help on how to use helper plugins in maven
[
http://jira.codehaus.org/browse/MPH-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126116
]
B. Garvelink commented on MPH-26:
-
I completely agree with Eirik that the help plugin is too difficult to use. I'd
like to venture a bit further; I think the goal shouldn't be any less than the
ability to run
{code:none}
>mvn help maven-dependency-plugin#plugin artifactId
>mvn help compiler #plugin prefix
>mvn help#displays syntax for the above
{code}
Where plugins from both {{org.apache.maven.plugins}} and {{org.codehaus.mojo}}
should be accepted without specifying groupId. I suspect that this can be
implemented in a fairly clean manner by introducing a {{help}} lifecycle; a
launcher tweak may be required to infer {{-Dplugin=}} for the second parameter.
I think that's an acceptable price to pay.
I also agree with Andrea's comment in MPH-15 that the {{-Dfull=true}} output is
a bit verbose, and I think the normal output is too terse. I think the correct
level of default verbosity would be to render a console version of the first
three sections (intro, required parameters, optional parameters) of the
"x-mojo.html" pages in any plugin site
([e.g.|http://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html]).
The {{-Dfull=true}} parameter can remain supported in its current form.
Finally, an {{outputXML}} parameter as seen in the analysis mojos of the
{{maven-dependency-plugin}} would be invaluable.
> New goal help:help to provide help on how to use helper plugins in maven
>
>
> Key: MPH-26
> URL: http://jira.codehaus.org/browse/MPH-26
> Project: Maven 2.x Help Plugin
> Issue Type: Improvement
>Affects Versions: 2.0
>Reporter: Eirik Maus
>
> It is almost impossible to remember the usage of the helper utility plugins
> in maven. Every single time I have problems with transient dependencies I end
> up searching google for "maven help plugin" and "maven dependency plugin".
> That is not good enough.
> The help plugin should have a goal called help, describing the usage of the
> plugin. This would make help (or, rather, a bootstrap on how to use the help
> system) available under the obvious command "mvn help:help". This goal could
> also hint about the existence of the dependency plugin, since many of the
> difficult problems when using maven are related to complex transitive
> dependencies.
> The command "mvn -help" should also describe the use of the
> maven-help-plugin, but I will create a separate issue in the maven core
> module for that.
--
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
