[jira] Created: (MECLIPSE-498) eclipse:eclipse generates inaccurate .project file for ejb-client dependency
eclipse:eclipse generates inaccurate .project file for ejb-client dependency Key: MECLIPSE-498 URL: http://jira.codehaus.org/browse/MECLIPSE-498 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Marius Grama I have a pom.xml in which i specify among the dependencies and ejb library and its ejb-client generated library dependencies : . myproject my-artifact-ejb 0.0.1-SNAPSHOT ejb-client myproject my-artifact-ejb 0.0.1-SNAPSHOT ejb . When I run maven having this program arguments : -e clean eclipse:clean eclipse:eclipse package install -Dmaven.test.skip=true -Declipse.useProjectReferences=false -Declipse.useProjectReferences=false everything runs smoothly and I have all the libraries added in the classpath. When I drop -Declipse.useProjectReferences=false program argument my .project generated file looks a bit like this : uniqa-testservice-service-testserviceimpl-iiop-client uniqa-testservice-service-testserviceimpl-iiop-client xxx my-artifact-ejb my-artifact-ejb and in the .classpath file : . my-artifact-ejb is a project which exists in the same workspace as my project. I am rather new to Maven, but it seems to me that this is a bug for eclipse:eclipse. Please correct me if I am wrong. -- 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-3808) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152229#action_152229 ] Carlos Sanchez commented on MNG-3808: - also for some reason, as commented in the unit test, the configurations of reports don't seem to be merged > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MNG-3808 > URL: http://jira.codehaus.org/browse/MNG-3808 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, > Sites & Reporting >Affects Versions: 2.0.9 > Environment: maven 2.0.4, windows 2000 >Reporter: David Vicente >Priority: Critical > Attachments: MNG-3808.patch > > > I have created a maven 2 report : Dashboard report which aggregate all > reports results in one report. > My plugin must be executed as the last one even if i can't bind the > "post-site" phase or use the "aggregator" annotation. > I declare my report plugin as the last one in the reporting section of my POM. > When i run mvn site on a single project, it's ok, my plugin has been > executed as the last one. > The reports list has been ordered as declared in my POM. > But if i run "mvn site" on a multi-project POM, the reports list isn't > ordered as before. > I think, it's the same problem as > http://jira.codehaus.org/browse/MNG-1994?page=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-3808) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-3808: Testcase included: yes Patch Submitted: [Yes] > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MNG-3808 > URL: http://jira.codehaus.org/browse/MNG-3808 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, > Sites & Reporting >Affects Versions: 2.0.9 > Environment: maven 2.0.4, windows 2000 >Reporter: David Vicente >Priority: Critical > Attachments: MNG-3808.patch > > > I have created a maven 2 report : Dashboard report which aggregate all > reports results in one report. > My plugin must be executed as the last one even if i can't bind the > "post-site" phase or use the "aggregator" annotation. > I declare my report plugin as the last one in the reporting section of my POM. > When i run mvn site on a single project, it's ok, my plugin has been > executed as the last one. > The reports list has been ordered as declared in my POM. > But if i run "mvn site" on a multi-project POM, the reports list isn't > ordered as before. > I think, it's the same problem as > http://jira.codehaus.org/browse/MNG-1994?page=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-3808) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-3808: Attachment: MNG-3808.patch Patch against 2.1.x with unit test mergeReportPluginLists behavior copied from mergePluginLists which was fixed in related issues > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MNG-3808 > URL: http://jira.codehaus.org/browse/MNG-3808 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, > Sites & Reporting >Affects Versions: 2.0.9 > Environment: maven 2.0.4, windows 2000 >Reporter: David Vicente >Priority: Critical > Attachments: MNG-3808.patch > > > I have created a maven 2 report : Dashboard report which aggregate all > reports results in one report. > My plugin must be executed as the last one even if i can't bind the > "post-site" phase or use the "aggregator" annotation. > I declare my report plugin as the last one in the reporting section of my POM. > When i run mvn site on a single project, it's ok, my plugin has been > executed as the last one. > The reports list has been ordered as declared in my POM. > But if i run "mvn site" on a multi-project POM, the reports list isn't > ordered as before. > I think, it's the same problem as > http://jira.codehaus.org/browse/MNG-1994?page=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] Created: (MCHECKSTYLE-105) Update to Checkstyle 5.0-beta01
Update to Checkstyle 5.0-beta01 --- Key: MCHECKSTYLE-105 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Felix Röthenbacher Attachments: patch.diff Checkstyle 5.0-beta01 adds support for generics, etc. See http://checkstyle.sourceforge.net/5.x/releasenotes.html for a list of new features. Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is available from a public Maven repository. Patch updates plugin to changed API / implementation. -- 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-1994) Execution order of child plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-1994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-1994: Assignee: John Casey why was this issue closed as Won't Fix? > Execution order of child plugins is arbitrary if inheritance is involved > > > Key: MNG-1994 > URL: http://jira.codehaus.org/browse/MNG-1994 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.1 >Reporter: John Didion >Assignee: John Casey >Priority: Critical > Attachments: mergePluginLists.txt > > > This is related to MNG-1499, but different, and, in my opinion, equally > important. It makes sense that the order of plugin execution should be the > same as it appears in the POM. For example, I have two plugins: one that > generates a batch file and one that executes it. These plugins must run in > order or the build will fail. However, the current implementation of > ModelUtils.mergePluginLists does not respect the order of child plugins. > There is also a seperate bug in that the assembledPlugins map is being > checked for the presence of child plugins before adding them to the > mergedPlugins list, but nothing is ever added to assembledPlugins. So if a > plugin exists in a parent and a child, it will end up appearing twice in the > child's plugin list. > I have re-written this method to fix both these problems. See attached. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3775) [regression] Problem in dependency resolution with exclusion, pom parent
[ http://jira.codehaus.org/browse/MNG-3775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3775: -- Fix Version/s: 2.0.11 Summary: [regression] Problem in dependency resolution with exclusion, pom parent (was: Problem in dependency resolution with exclusion, pom parent) this is a regression from 2.0.8 -> 2.0.9 > [regression] Problem in dependency resolution with exclusion, pom parent > > > Key: MNG-3775 > URL: http://jira.codehaus.org/browse/MNG-3775 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9 >Reporter: Bertrand Paquet > Fix For: 2.0.11 > > Attachments: bug_maven.zip, bug_maven_test.zip > > > See projects in attachement. > Parent projet uses SEAM pom parent, and declares jboss-seam as dependency, > excluding javax.el > First project uses parent project, and declares javax.el as dependency > mvn dependency:list on first, you can see javax.el > Second project uses parent project, and declares first project as dependency. > It should have javax.el on classpath (because of first project), but it > doesn't. > mvn dependency:list on second, javax.el disappears ! -- 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: (MSHARED-77) DependencyTreeResolutionListener throws NullPointerException
DependencyTreeResolutionListener throws NullPointerException Key: MSHARED-77 URL: http://jira.codehaus.org/browse/MSHARED-77 Project: Maven Shared Components Issue Type: Bug Components: maven-dependency-tree Affects Versions: maven-dependency-tree 1.2 Environment: Maven version: 2.0.10-RC1 Java version: 1.4.2_18 OS name: "linux" version: "2.6.27.4-core2" arch: "i386" Family: "unix" Reporter: Christian Schulte Priority: Blocker Having groupId artifactId [1.5,) compile inside dependencyManagement mvn site fails with java.lang.NullPointerException: version was null for groupId:artifactId 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.manageArtifactScope(DependencyTreeResolutionListener.java:362) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:563) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.fireEvent(DefaultArtifactCollector.java:516) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.manageArtifact(DefaultArtifactCollector.java:454) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:311) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:424) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74) at org.apache.maven.shared.dependency.tree.DefaultDependencyTreeBuilder.buildDependencyTree(DefaultDependencyTreeBuilder.java:97) at org.apache.maven.report.projectinfo.DependenciesReport.resolveProject(DependenciesReport.java:267) at org.apache.maven.report.projectinfo.DependenciesReport.executeReport(DependenciesReport.java:228) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:90) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:133) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:100) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) 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:324) 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-3808) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-3808: Component/s: Sites & Reporting Plugins and Lifecycle Inheritance and Interpolation > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MNG-3808 > URL: http://jira.codehaus.org/browse/MNG-3808 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation, Plugins and Lifecycle, > Sites & Reporting >Affects Versions: 2.0.9 > Environment: maven 2.0.4, windows 2000 >Reporter: David Vicente >Priority: Critical > > I have created a maven 2 report : Dashboard report which aggregate all > reports results in one report. > My plugin must be executed as the last one even if i can't bind the > "post-site" phase or use the "aggregator" annotation. > I declare my report plugin as the last one in the reporting section of my POM. > When i run mvn site on a single project, it's ok, my plugin has been > executed as the last one. > The reports list has been ordered as declared in my POM. > But if i run "mvn site" on a multi-project POM, the reports list isn't > ordered as before. > I think, it's the same problem as > http://jira.codehaus.org/browse/MNG-1994?page=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] Moved: (MNG-3808) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-3808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez moved MSITE-188 to MNG-3808: --- Affects Version/s: (was: 2.0-beta-4) 2.0.9 Complexity: Intermediate Key: MNG-3808 (was: MSITE-188) Project: Maven 2 (was: Maven 2.x Site Plugin) > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MNG-3808 > URL: http://jira.codehaus.org/browse/MNG-3808 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 > Environment: maven 2.0.4, windows 2000 >Reporter: David Vicente >Priority: Critical > > I have created a maven 2 report : Dashboard report which aggregate all > reports results in one report. > My plugin must be executed as the last one even if i can't bind the > "post-site" phase or use the "aggregator" annotation. > I declare my report plugin as the last one in the reporting section of my POM. > When i run mvn site on a single project, it's ok, my plugin has been > executed as the last one. > The reports list has been ordered as declared in my POM. > But if i run "mvn site" on a multi-project POM, the reports list isn't > ordered as before. > I think, it's the same problem as > http://jira.codehaus.org/browse/MNG-1994?page=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] Closed: (MNG-3385) PluginManagement does not work for report-plugins
[ http://jira.codehaus.org/browse/MNG-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MNG-3385. --- Assignee: Carlos Sanchez Resolution: Duplicate Fix Version/s: (was: 3.0) See linked issues > PluginManagement does not work for report-plugins > - > > Key: MNG-3385 > URL: http://jira.codehaus.org/browse/MNG-3385 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.8 >Reporter: Andreas Höhmann >Assignee: Carlos Sanchez > > >... > > > org.apache.maven.plugins > maven-pmd-plugin > 2.2 > > > >... > > > > > maven-pmd-plugin > > > > mvn site ... use pmd-2.4-SNAPSHOT instead of the defined 2.2 ... why? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-495) excludes should support *
[ http://jira.codehaus.org/browse/MECLIPSE-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-495: - Component/s: Core : Dependencies resolution and build path (.classpath) > excludes should support * > - > > Key: MECLIPSE-495 > URL: http://jira.codehaus.org/browse/MECLIPSE-495 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.5.1 > Environment: Windows Vista, Maven 2.0.9 >Reporter: Will Horn > Attachments: MECLIPSE-495.patch > > > I am using eclipse:eclipse (with pde=true) and the manifest is handwritten to > find OSGi bundles for its dependencies in the Eclipse target platform (the > org.eclipse.pde.core.requiredPlugins classpath container). > As a result, I don't want the eclipse:eclipse goal to generate classpath (and > Bundle-Classpath) entries for all of my 30 or so dependencies. Currently I > can work around it by adding a huge list of excludes, but I really just want > to exclude everything. > I think this is related to http://jira.codehaus.org/browse/MECLIPSE-79 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-456) Allow for manifest customization
[ http://jira.codehaus.org/browse/MECLIPSE-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-456: - Component/s: Core : Dependencies resolution and build path (.classpath) > Allow for manifest customization > > > Key: MECLIPSE-456 > URL: http://jira.codehaus.org/browse/MECLIPSE-456 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.5.1 >Reporter: Michael Johns >Priority: Minor > > It would be nice to have the ability to customize the manifest, much the same > way the maven-jar-plugin and maven-war-plugin allow. They use the > maven-archiver. See > http://maven.apache.org/shared/maven-archiver/examples/manifest.html for some > ideas of what can be accomplished. > Our application reads some information from the manifest dynamically to let > us know what version of the code we've deployed, and while it works great > when built and deployed on the server, we can't make it work in our dev > environments due to how the plugin limits what we can put in the manifest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-423) NullPointerException when existing Manifest.MF file has no Class-Path element
[
http://jira.codehaus.org/browse/MECLIPSE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-423:
-
Component/s: Core : Dependencies resolution and build path (.classpath)
> NullPointerException when existing Manifest.MF file has no Class-Path element
> -
>
> Key: MECLIPSE-423
> URL: http://jira.codehaus.org/browse/MECLIPSE-423
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5
>Reporter: Michael Johns
>Assignee: Barrie Treloar
>Priority: Minor
> Fix For: 2.6
>
> Attachments: pom.xml
>
>
> A NullPointerException arises when running the rad goal against a project
> containing a manifest that has no Class-Path element. The exception is
> caught and the only error on the screen is "No
> \META-INF\MANIFEST.MF file found". The problem is in the
> RadManifestWriter.orderClasspath() method. It needs to check newValue for
> null before trying to split it up.
> Here's the manifest I had that caused the problem:
> {code}
> Manifest-Version: 1.0
> Build-Jdk: 1.4.2
> Built-By: Michael Johns
> Created-By: Apache Maven
> {code}
> Notice that it has no Class-Path element.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-368) Dependency configuration in DependencyManagement with exclusions is ignored
[ http://jira.codehaus.org/browse/MECLIPSE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-368: - Component/s: Core : Dependencies resolution and build path (.classpath) > Dependency configuration in DependencyManagement with exclusions is ignored > --- > > Key: MECLIPSE-368 > URL: http://jira.codehaus.org/browse/MECLIPSE-368 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.4 > Environment: Ubuntu Linux 7.10 >Reporter: jh > Attachments: exclusion-example-20080116.zip, MECLIPSE-368.patch > > > A transitive dependency which is defined in the DependencyManagement section > with exclusions does not take these exclusions into account when generating > an eclipse classpath. > Example: > - childProject has a dependency 'acegi-security-tiger' > - parentProject has a dependencyManagement section that defines the version > and the exclusions > - acegi-security-tiger has a transitive dependency to acegi-security > - parentProject has defined acegi-security and a number of exclusions one of > which is spring-remoting 1.2.7 > - childProject's classpath ends up with spring-remoting 1.2.7 as dependency > - we are using spring 2.5.1 which does not have spring-remoting > If I check dependencies with dependency:tree -Dscope=null the dependency > resolving of acegi-security-tiger stops with acegi-security and no other > transitive dependencies are added (all are excluded) > Workaround is to add acegi-security in childProject's pom. > Main concern here is that dependency resolution in the eclipse plugin seems > to be different from the dependency plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-433) Plugin could write out a .webspheredeploy for RAD
[ http://jira.codehaus.org/browse/MECLIPSE-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-433: - Component/s: RAD support > Plugin could write out a .webspheredeploy for RAD > - > > Key: MECLIPSE-433 > URL: http://jira.codehaus.org/browse/MECLIPSE-433 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: RAD support >Affects Versions: 2.5.1 >Reporter: Michael Johns >Priority: Minor > Attachments: MECLIPSE-433.patch, RadWebSphereDeployWriter.java > > > RAD uses a file called .webspheredeploy to help in deploying EJB projects. > The plugin could very easily write this file out to save a developer from > having to check-in what should be a generated resource. Right now, this is > the only resource (that I can tell) that the plugin doesn't generate but > really could if it wanted to. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-432) RAD goal should support security-role element in application.xml
[ http://jira.codehaus.org/browse/MECLIPSE-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-432: - Component/s: RAD support > RAD goal should support security-role element in application.xml > > > Key: MECLIPSE-432 > URL: http://jira.codehaus.org/browse/MECLIPSE-432 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: RAD support >Affects Versions: 2.5.1 >Reporter: Michael Johns > Attachments: MECLIPSE-432.2.patch, MECLIPSE-432.3.patch, > MECLIPSE-432.patch, SecurityRole.java > > > The ear plugin supports the writing of elements in the > generated application.xml. This plugin should support the same thing so that > the development-time application.xml can be identical with the one that's > ultimately generated as part of a package. > Attached patch is just code stolen from the ear plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-466) application.xml generated incorrectly for 3rd party ejb modules
[ http://jira.codehaus.org/browse/MECLIPSE-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-466: - Component/s: WTP support > application.xml generated incorrectly for 3rd party ejb modules > --- > > Key: MECLIPSE-466 > URL: http://jira.codehaus.org/browse/MECLIPSE-466 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5.1 >Reporter: Siarhei Dudzin > Fix For: 2.6 > > Attachments: test-project.tar.gz > > > As you may know by default the project version is not added to the project > name. In case I have 3rd party ejb modules from a maven repository (jboss > seam for example) the version number for those modules is removed from the > generated application.xml as well which breaks the WTP deployment: the server > can't find the 3rd party ejb jar because it expects the jar also be without > the version number. > Looks like during generation of application.xml there is no distinction made > between dependencies from projects and libraries. > I included a test case. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-452) mvn clean breaks eclipse configuration if wtpapplicationxml = true: files in target/eclipseEar are deleted
[
http://jira.codehaus.org/browse/MECLIPSE-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-452:
-
Component/s: WTP support
> mvn clean breaks eclipse configuration if wtpapplicationxml = true: files in
> target/eclipseEar are deleted
> --
>
> Key: MECLIPSE-452
> URL: http://jira.codehaus.org/browse/MECLIPSE-452
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Affects Versions: 2.6
> Environment: Linux, wtp 2.0, Eclipse 3.3
>Reporter: Gabriele Contini
>
> When the parameter wtpapplicationxml is set to true in an ear project some
> file is written to target/eclipseEar
> and this location is added to the file org.eclipse.wst.common.component for
> deployment
> Subsequent executions of
> {code}
> mvn clean
> {code}
> delete the directory and break the eclipse configuration.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-448) connector projects (RAR) are not added to .components in EAR projects
[
http://jira.codehaus.org/browse/MECLIPSE-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-448:
-
Component/s: WTP support
> connector projects (RAR) are not added to .components in EAR projects
> -
>
> Key: MECLIPSE-448
> URL: http://jira.codehaus.org/browse/MECLIPSE-448
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Affects Versions: 2.5.1
>Reporter: Gabriele Contini
> Attachments: MECLIPSE-448-maven-eclipse-plugin.patch
>
>
> There is an issue generating wtp configuration for multi-module j2ee
> applications that use connectors.
> Suppose you have a "connector project" to access an external data source
> packaged as a RAR (Resource Archive) and an Eclipse "enterprise application
> project" with packaging EAR.
> The EAR includes the RAR between its dependencies. Below you can see the
> correct EAR structure as deployed by maven:
> myapp.ear
>|- myapp-ejb.ejb
>|- myapp-jcr-connector.rar
>|- myapp-web.war
>|- META-INF
>| |- application.xml
>| |- ...
>|- WEB-INF
>|- ...
> here is a snippet from: myapp/jcr-connector/pom.xml
>
> myapp-jcr-connector
> rar
> ...
> here is a snippet from: myapp/ear/pom.xml
>
> ${pom.groupId}
> myapp-jcr-connector
> ${pom.version}
> rar
>
> When the wtp configuration of the "Enterprise Application Project" is
> generated the "Connector Project" is not referenced in the
> org.eclipse.wst.common.component (of the Enterprise project) file thus making
> the deployment of the connector artifact fail.
> By the way the connector it's not included in the generated application.xml
> too, but this file can be easily overridden.
> Here is how the rar should be referenced in the application.xml:
>
> myapp-jcr-connector.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] Updated: (MECLIPSE-431) Non-project EJB dependencies need a version number in application.xml
[ http://jira.codehaus.org/browse/MECLIPSE-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-431: - Component/s: WTP support > Non-project EJB dependencies need a version number in application.xml > - > > Key: MECLIPSE-431 > URL: http://jira.codehaus.org/browse/MECLIPSE-431 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.5.1 >Reporter: Michael Johns > Attachments: MECLIPSE-431.patch > > > This relates to issue MECLIPSE-430. When including EJBs that were built > previously (ie, not part of the same multi-module project as the ear), the > application.xml needs to include their version number. -- 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: (MDEP-185) Dependency:copy does not work for 0 byte files
[ http://jira.codehaus.org/browse/MDEP-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152210#action_152210 ] Brian Fox commented on MDEP-185: can you attach a test project? > Dependency:copy does not work for 0 byte files > -- > > Key: MDEP-185 > URL: http://jira.codehaus.org/browse/MDEP-185 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug >Reporter: Manfred Moser >Assignee: Brian Fox > > When using dependency:copy against a file deployed to the repository with 0 > bytes the plugin reports that the artifact can not be found even if a 0 byte > file is there. Workaround of course is to make it one byte but that can cause > problems depending on what the artifact is needed for. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-97) Allow providing custom target for eclipse use
[ http://jira.codehaus.org/browse/MECLIPSE-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier updated MECLIPSE-97: Component/s: Core : Dependencies resolution and build path > Allow providing custom target for eclipse use > - > > Key: MECLIPSE-97 > URL: http://jira.codehaus.org/browse/MECLIPSE-97 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path >Reporter: Jukka Lindström > > .project files created with eclipse:eclipse point to the same compliation > target directory as maven (that is target/classes). However I would want > eclipse to use different target directories than maven because maven clean > will also trigger a eclipse build and this causes problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-451) EJB projects are not correctly referenced in .component
[
http://jira.codehaus.org/browse/MECLIPSE-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MECLIPSE-451:
-
Component/s: WTP support
> EJB projects are not correctly referenced in .component
>
>
> Key: MECLIPSE-451
> URL: http://jira.codehaus.org/browse/MECLIPSE-451
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
> Environment: Eclipse 3.3, Wtp 2.0, Jboss 4.2, Linux
>Reporter: Gabriele Contini
>Priority: Critical
>
> There is a problem generating wtp 2.0 configuration for multi-module j2ee
> applications using ejb 3.0.
> Here is my project structure.
> {noformat}
> myapp
>|--ear
>| |-- .settings
>| ||--- org.eclipse.wst.common.component
>| |
>| |-- pom.xml
>|--ejb
>| |-- pom.xml
>|
>|
> {noformat}
> here is a snippet from: myapp/ejb/pom.xml
> {code:xml}
>
> myapp-ejb
> ejb
> ...
> {code}
> here is a snippet from: myapp/ear/pom.xml
> {code:xml}
>
> ${pom.groupId}
> myapp-ejb
> ${pom.version}
> ejb
>
> {code}
> and here is a snippet from the generated org.eclipse.wst.common.component
> file in the ear project.
> {code:xml}
> handle="module:/resource/myapp-ejb/myapp-ejb">
> EjbModule_9473961
> uses
>
> {code}
> Thus inside the ear generated by eclipse i can find an artifact: myapp-ejb.ejb
> Whereas the generated application.xml the module is referenced with .jar
> extension:
> {code:xml}
>
> ---
>
> myapp-ejb.jar
>
> {code}
> I tried to override the application.xml with a custom one, but it seems that
> jboss doesn't like at all the extension ".ejb" for ejb 3.0 jars.
> To make it work i modified by hand the generated
> org.eclipse.wst.common.component file in the ear project like this:
> {code:xml}
> handle="module:/resource/unirepo-core/unirepo-core">
> EjbModule_12684337
> uses
>
> {code}
> At the moment this file must be modified by hand every time i generate the
> eclipse configuration.
--
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-3770) pom gets trancated when deploying to repository
[ http://jira.codehaus.org/browse/MNG-3770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152208#action_152208 ] Vadim Strizhevsky commented on MNG-3770: Having exactly the same issue. We upgraded from continuum 1.1 to 1.2 and it started happening. Maven version has not changed (2.0.9). Is there any simple resolution to this. > pom gets trancated when deploying to repository > --- > > Key: MNG-3770 > URL: http://jira.codehaus.org/browse/MNG-3770 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.9 > Environment: redhat4 >Reporter: elmoumen > Attachments: good.xml, trancated.xml > > > i have a problem deploying artifacts to repository > if the artifact exists the pom is trancated else no pb > i'm using redhat4, maven2.0.9 and hudson -- 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: (MECLIPSE-496) Possible to process generated-classes?
[ http://jira.codehaus.org/browse/MECLIPSE-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152205#action_152205 ] Arnaud Heritier commented on MECLIPSE-496: -- Can you provide a testcase please ?? > Possible to process generated-classes? > -- > > Key: MECLIPSE-496 > URL: http://jira.codehaus.org/browse/MECLIPSE-496 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: Core : Dependencies resolution and build path > Environment: Windows XP SP2, Sun Java 6 >Reporter: Jerry Shea >Priority: Minor > > I am using xmlbeans with the eclipse plugin and when I run > mvn clean xmlbeans:xmlbeans eclipse:eclipse > the eclipse plugin generates my project and works out that there is a > directory called target\generated-sources\xmlbeans and creates that as a > source folder in the eclipse project ( path="target/generated-sources/xmlbeans"/>). > All good so far. The xmlbeans plugin also generates some classes into > target\generated-classes\xmlbeans - would it be possible for the eclipse > plugin also generate an entry in the eclipse project for these generated > classes as below? > -- 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: (MDEP-185) Dependency:copy does not work for 0 byte files
Dependency:copy does not work for 0 byte files -- Key: MDEP-185 URL: http://jira.codehaus.org/browse/MDEP-185 Project: Maven 2.x Dependency Plugin Issue Type: Bug Reporter: Manfred Moser Assignee: Brian Fox When using dependency:copy against a file deployed to the repository with 0 bytes the plugin reports that the artifact can not be found even if a 0 byte file is there. Workaround of course is to make it one byte but that can cause problems depending on what the artifact is needed for. -- 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: (MDEP-68) Make dependency:unpack of tar files support symlinks
[ http://jira.codehaus.org/browse/MDEP-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152200#action_152200 ] Manfred Moser commented on MDEP-68: --- This should also be an option for the copy goal so that large files do not have to be copied from the local repo to a local path but rather just create a symlink. E.g. we have large database dumps in nexus and use them for regression tests. If a symlink could be created we would not have to copy them prior to restoring.. > Make dependency:unpack of tar files support symlinks > > > Key: MDEP-68 > URL: http://jira.codehaus.org/browse/MDEP-68 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: unpack, unpack-dependencies >Reporter: Steinar Bang >Assignee: Brian Fox > > Could dependency:unpack of tar file be made to support symlinks? The use > case is deploying unix/linux shared libraries, with symlinks between > different versions of the libraries. > The current behaviour is that the symlinks becomes 0 byte sized files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-274) autoVersionSubModules could be improved for release:branch
[ http://jira.codehaus.org/browse/MRELEASE-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152199#action_152199 ] Joshua Pollak commented on MRELEASE-274: It seems to me that -DautoVersionSubmodules=true has no effect. I am still prompted for the version number for modules of my top level pom (with pom) > autoVersionSubModules could be improved for release:branch > -- > > Key: MRELEASE-274 > URL: http://jira.codehaus.org/browse/MRELEASE-274 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-7, 2.0 > Environment: All >Reporter: Wouter Hermeling >Priority: Minor > > When doing a release:branch and setting autoVersionSubModules to true, i > would like to have the versions of the submodules modified the same way as > the parent instead of asking for the new version to use. -- 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: (MRESOURCES-75) Problems on resource filtering interpolation
[ http://jira.codehaus.org/browse/MRESOURCES-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRESOURCES-75: --- Fix Version/s: (was: 2.4) > Problems on resource filtering interpolation > > > Key: MRESOURCES-75 > URL: http://jira.codehaus.org/browse/MRESOURCES-75 > Project: Maven 2.x Resources Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Marvin Froeder >Assignee: John Casey > Attachments: patch.zip > > > Hi, > I created a maven plugin, and this plugin add so properties to the project at > validate phase. > Then, when resources-plugin copy resources to outputDirectory it is not > interpolating the variables add by my plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3807) Maven is not interpolatin Properties at plugin configuration
[
http://jira.codehaus.org/browse/MNG-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152198#action_152198
]
John Casey commented on MNG-3807:
-
This is related to the version of the plexus container we're using in maven.
With more recent versions, the PropertiesConverter (used to convert XML to a
Properties instance for plugin parameter injection) does evaluate embedded
expressions. However, as of 1.0-alpha-9 of the plexus container, this new code
was not in place.
It seems we have two options for fixing this:
1. create a maintenance branch based on plexus 1.0-alpha-9 and fix the
PropertiesConverter there, then release a new revision for use in maven
2. move maven onto a more recent plexus version, which will entail quite a bit
of work since the component model has changed in important ways since alpha-9.
My personal opinion is that #2 is preferable if it's reasonably easy to do (not
sure on this). This would modernize Maven WRT the plexus container, and enable
us to track a little more closely with the progress in plexus in future.
However, we could fix the PropertiesConverter itself very quickly, making #1 a
much more expedient option.
> Maven is not interpolatin Properties at plugin configuration
>
>
> Key: MNG-3807
> URL: http://jira.codehaus.org/browse/MNG-3807
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9, 2.1.0-M1
>Reporter: Marvin Froeder
> Fix For: 2.1.0-M2
>
>
> My plugin has a configuration like this:
> {noformat}
> /**
> * My Properties.
> *
> * @parameter
> */
> private Properties myProperties;
> {noformat}
> When I configure like this:
> {noformat}
>
>
> propertyName1
> ${buildnumber}
>
>
> {noformat}
> Maven doesn't interpolate the buildnumber. But the value is available at
> project.getProperties().
--
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-3807) Maven is not interpolatin Properties at plugin configuration
[
http://jira.codehaus.org/browse/MNG-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated MNG-3807:
Fix Version/s: 2.1.0-M2
> Maven is not interpolatin Properties at plugin configuration
>
>
> Key: MNG-3807
> URL: http://jira.codehaus.org/browse/MNG-3807
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9, 2.1.0-M1
>Reporter: Marvin Froeder
> Fix For: 2.1.0-M2
>
>
> My plugin has a configuration like this:
> {noformat}
> /**
> * My Properties.
> *
> * @parameter
> */
> private Properties myProperties;
> {noformat}
> When I configure like this:
> {noformat}
>
>
> propertyName1
> ${buildnumber}
>
>
> {noformat}
> Maven doesn't interpolate the buildnumber. But the value is available at
> project.getProperties().
--
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: (MRESOURCES-75) Problems on resource filtering interpolation
[ http://jira.codehaus.org/browse/MRESOURCES-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MRESOURCES-75. Assignee: John Casey Resolution: Cannot Reproduce I've been through this patch, along with the pre-existing code, and even created a test project to try expressing the issue myself, using the buildnumber plugin from mojo.codehaus.org. I cannot reproduce using the 2.3 resources plugin, and the patch duplicates the interpolation logic already present in the filtering component, only using the PluginParameterExpressionEvaluator. I've also talked with Marvin, and verified that he had accidentally specified version 2.2 of the resources plugin in the pluginManagement of a parent POM. By adjusting the version in my test project to 2.2, I've duplicated the problem. This means the problem was solved in the 2.3 release, so I'm closing this now as no further work needs to be done. > Problems on resource filtering interpolation > > > Key: MRESOURCES-75 > URL: http://jira.codehaus.org/browse/MRESOURCES-75 > Project: Maven 2.x Resources Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Marvin Froeder >Assignee: John Casey > Fix For: 2.4 > > Attachments: patch.zip > > > Hi, > I created a maven plugin, and this plugin add so properties to the project at > validate phase. > Then, when resources-plugin copy resources to outputDirectory it is not > interpolating the variables add by my plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-173) Allow command line specification of versions
[ http://jira.codehaus.org/browse/MRELEASE-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152192#action_152192 ] Joshua Pollak commented on MRELEASE-173: Does this feature apply to the branch goal as well? I'd like to be able to do: mvn release:branch -DbranchVersion=1.2-myFeature -DbranchName=myFeature Can 2.0-beta-8 be released so we can start testing this feature? > Allow command line specification of versions > > > Key: MRELEASE-173 > URL: http://jira.codehaus.org/browse/MRELEASE-173 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-3, 2.0-beta-4, 2.0-beta-5 >Reporter: Chris Tucker >Assignee: Paul Gier > Fix For: 2.0-beta-8 > > Attachments: release-version.diff > > > It is convenient in a batchMode environment to specify the version to release > and the new version to update SNAPSHOT artifacts to. The attached patch > against maven-release-manager and maven-release-plugin provides the basic > functionality to allow this. > The maven-release-plugin will now accept two new arguments: > -DreleaseVersion= > -DdevVersion= > For example, to release version 1.2 of a project and move up to version > 2.0-SNAPSHOT one would issue: > $ mvn release:clean release:prepare -DreleaseVersion=1.2 -DdevVersion=2.0 > --batch-mode > This patch is against current trunk (471862). It currently doesn't support > resuming, so a release:clean is necessary if a previous release attempt has > been prepared. -- 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-3805) Ordering of extension class path is indeterministic
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152189#action_152189 ] Benjamin Bentmann commented on MNG-3805: A (currently disabled) IT is online. > Ordering of extension class path is indeterministic > --- > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann > Attachments: deterministic-dependency-ordering.patch, log-bad.txt, > log-good.txt > > > One part of Maven where class path ordering hasn't already been fixed in the > past is the extension class path. Apart from a proposed patch, two logs from > our IT testmng3599useHttpProxyForWebDAV are attached. Both were run against > Maven 2.0.10-RC1, with the only difference being one using JDK 1.4 and the > other one 1.6. Not only do these logs substantially differ, the build on JDK > 1.6 even fails due to picking up the wrong extension classes. -- 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: (MRESOURCES-75) Problems on resource filtering interpolation
[ http://jira.codehaus.org/browse/MRESOURCES-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRESOURCES-75: --- Fix Version/s: 2.4 Issue Type: New Feature (was: Bug) > Problems on resource filtering interpolation > > > Key: MRESOURCES-75 > URL: http://jira.codehaus.org/browse/MRESOURCES-75 > Project: Maven 2.x Resources Plugin > Issue Type: New Feature >Affects Versions: 2.3 >Reporter: Marvin Froeder > Fix For: 2.4 > > Attachments: patch.zip > > > Hi, > I created a maven plugin, and this plugin add so properties to the project at > validate phase. > Then, when resources-plugin copy resources to outputDirectory it is not > interpolating the variables add by my plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3805) Ordering of extension class path is indeterministic
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3805: --- Attachment: (was: deterministic-dependency-ordering.patch) > Ordering of extension class path is indeterministic > --- > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann > Attachments: deterministic-dependency-ordering.patch, log-bad.txt, > log-good.txt > > > One part of Maven where class path ordering hasn't already been fixed in the > past is the extension class path. Apart from a proposed patch, two logs from > our IT testmng3599useHttpProxyForWebDAV are attached. Both were run against > Maven 2.0.10-RC1, with the only difference being one using JDK 1.4 and the > other one 1.6. Not only do these logs substantially differ, the build on JDK > 1.6 even fails due to picking up the wrong extension classes. -- 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-3805) Ordering of extension class path is indeterministic
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3805: --- Attachment: deterministic-dependency-ordering.patch > Ordering of extension class path is indeterministic > --- > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann > Attachments: deterministic-dependency-ordering.patch, log-bad.txt, > log-good.txt > > > One part of Maven where class path ordering hasn't already been fixed in the > past is the extension class path. Apart from a proposed patch, two logs from > our IT testmng3599useHttpProxyForWebDAV are attached. Both were run against > Maven 2.0.10-RC1, with the only difference being one using JDK 1.4 and the > other one 1.6. Not only do these logs substantially differ, the build on JDK > 1.6 even fails due to picking up the wrong extension classes. -- 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: (ARCHETYPE-81) Archetype not downloaded until pom is placed in working dir
[ http://jira.codehaus.org/browse/ARCHETYPE-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152182#action_152182 ] Raphaël Piéroni commented on ARCHETYPE-81: -- Hi Tim, could you please try with the new archetype:generate goal using the 2.0-alpha-4 version of the plugin, to see if it is not to be closed by obsolescence. > Archetype not downloaded until pom is placed in working dir > --- > > Key: ARCHETYPE-81 > URL: http://jira.codehaus.org/browse/ARCHETYPE-81 > Project: Maven Archetype > Issue Type: Bug > Components: Plugin >Affects Versions: 1.0-alpha-4 >Reporter: Tim Reilly > Fix For: 2.0-alpha-5 > > > Our archetype is hosted internally in the company repository. > Our settings.xml contains profiles with the internal repository locations. > I mkdir C:\temp\archtest > I execute mvn archetype:create -D etc > I get "could not download archetype ... from central > Next I put a valid pom.xml in the working dir > I execute mvn archetype:create -D etc > I get an expected error since the directory is not empty, but now if I check > my local repository the archetype is downloaded from the company repository. > !! Why wasn't it found until a pom.xml is in the directory? > Now I delete the pom.xml > Now I can build sucessfully. > It would appear the profiles where we define our repositories are not being > used until the pom.xml is available. But even mvn -P archetype:create doesn't > resolve the 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] Commented: (MRESOURCES-75) Problems on resource filtering interpolation
[
http://jira.codehaus.org/browse/MRESOURCES-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152178#action_152178
]
Olivier Lamy commented on MRESOURCES-75:
Thanks for the patch.
Perso, I'd prefer something like :
{code:java}
mavenResourcesExecution.setExpressionEvaluator(ExpressionEvaluator
expressionEvaluator);
{code}
To not break the current interface.
> Problems on resource filtering interpolation
>
>
> Key: MRESOURCES-75
> URL: http://jira.codehaus.org/browse/MRESOURCES-75
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.3
>Reporter: Marvin Froeder
> Attachments: patch.zip
>
>
> Hi,
> I created a maven plugin, and this plugin add so properties to the project at
> validate phase.
> Then, when resources-plugin copy resources to outputDirectory it is not
> interpolating the variables add by my plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3807) Maven is not interpolatin Properties at plugin configuration
[
http://jira.codehaus.org/browse/MNG-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marvin Froeder updated MNG-3807:
Affects Version/s: 2.0.9
2.1.0-M1
> Maven is not interpolatin Properties at plugin configuration
>
>
> Key: MNG-3807
> URL: http://jira.codehaus.org/browse/MNG-3807
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.9, 2.1.0-M1
>Reporter: Marvin Froeder
>
> My plugin has a configuration like this:
> {noformat}
> /**
> * My Properties.
> *
> * @parameter
> */
> private Properties myProperties;
> {noformat}
> When I configure like this:
> {noformat}
>
>
> propertyName1
> ${buildnumber}
>
>
> {noformat}
> Maven doesn't interpolate the buildnumber. But the value is available at
> project.getProperties().
--
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-3807) Maven is not interpolatin Properties at plugin configuration
[
http://jira.codehaus.org/browse/MNG-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marvin Froeder updated MNG-3807:
Description:
My plugin has a configuration like this:
{quote}
/**
* My Properties.
*
* @parameter
*/
private Properties myProperties;
{quote}
When I configure like this:
{quote}
propertyName1
${buildnumber}
{quote}
Maven doesn't interpolate the buildnumber. But the value is available at
project.getProperties().
was:
My plugin has a configuration like this:
/**
* My Properties.
*
* @parameter
*/
private Properties myProperties;
When I configure like this:
propertyName1
${buildnumber}
Maven doesn't interpolate the buildnumber. But the value is available at
project.getProperties().
> Maven is not interpolatin Properties at plugin configuration
>
>
> Key: MNG-3807
> URL: http://jira.codehaus.org/browse/MNG-3807
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Marvin Froeder
>
> My plugin has a configuration like this:
> {quote}
> /**
> * My Properties.
> *
> * @parameter
> */
> private Properties myProperties;
> {quote}
> When I configure like this:
> {quote}
>
>
> propertyName1
> ${buildnumber}
>
>
> {quote}
> Maven doesn't interpolate the buildnumber. But the value is available at
> project.getProperties().
--
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-3807) Maven is not interpolatin Properties at plugin configuration
[
http://jira.codehaus.org/browse/MNG-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marvin Froeder updated MNG-3807:
Description:
My plugin has a configuration like this:
{noformat}
/**
* My Properties.
*
* @parameter
*/
private Properties myProperties;
{noformat}
When I configure like this:
{noformat}
propertyName1
${buildnumber}
{noformat}
Maven doesn't interpolate the buildnumber. But the value is available at
project.getProperties().
was:
My plugin has a configuration like this:
{quote}
/**
* My Properties.
*
* @parameter
*/
private Properties myProperties;
{quote}
When I configure like this:
{quote}
propertyName1
${buildnumber}
{quote}
Maven doesn't interpolate the buildnumber. But the value is available at
project.getProperties().
> Maven is not interpolatin Properties at plugin configuration
>
>
> Key: MNG-3807
> URL: http://jira.codehaus.org/browse/MNG-3807
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Marvin Froeder
>
> My plugin has a configuration like this:
> {noformat}
> /**
> * My Properties.
> *
> * @parameter
> */
> private Properties myProperties;
> {noformat}
> When I configure like this:
> {noformat}
>
>
> propertyName1
> ${buildnumber}
>
>
> {noformat}
> Maven doesn't interpolate the buildnumber. But the value is available at
> project.getProperties().
--
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-3807) Maven is not interpolatin Properties at plugin configuration
Maven is not interpolatin Properties at plugin configuration
Key: MNG-3807
URL: http://jira.codehaus.org/browse/MNG-3807
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Reporter: Marvin Froeder
My plugin has a configuration like this:
/**
* My Properties.
*
* @parameter
*/
private Properties myProperties;
When I configure like this:
propertyName1
${buildnumber}
Maven doesn't interpolate the buildnumber. But the value is available at
project.getProperties().
--
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: (MRESOURCES-75) Problems on resource filtering interpolation
[ http://jira.codehaus.org/browse/MRESOURCES-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MRESOURCES-75: Affects Version/s: 2.3 > Problems on resource filtering interpolation > > > Key: MRESOURCES-75 > URL: http://jira.codehaus.org/browse/MRESOURCES-75 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Marvin Froeder > Attachments: patch.zip > > > Hi, > I created a maven plugin, and this plugin add so properties to the project at > validate phase. > Then, when resources-plugin copy resources to outputDirectory it is not > interpolating the variables add by my plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-75) Problems on resource filtering interpolation
Problems on resource filtering interpolation Key: MRESOURCES-75 URL: http://jira.codehaus.org/browse/MRESOURCES-75 Project: Maven 2.x Resources Plugin Issue Type: Bug Reporter: Marvin Froeder Attachments: patch.zip Hi, I created a maven plugin, and this plugin add so properties to the project at validate phase. Then, when resources-plugin copy resources to outputDirectory it is not interpolating the variables add by my plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-381) url syntax not good enough for the git scm provider
[
http://jira.codehaus.org/browse/MRELEASE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152175#action_152175
]
John Hampton commented on MRELEASE-381:
---
I think that 3 is the only correct solution. 1 and 2 do not work for private
repositories. Private repositories require the [EMAIL
PROTECTED]:olamy/scm-git-test-one-module for both checkout and checkin.
> url syntax not good enough for the git scm provider
> ---
>
> Key: MRELEASE-381
> URL: http://jira.codehaus.org/browse/MRELEASE-381
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-7
>Reporter: Torsten Curdt
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 2.0-beta-9
>
>
> The problem is that git supports 2 different URL schemes. For the normal RFC
> 2396 standard and ssh style. So in theory all these styles should work:
> normal anonymous absolute:
> {code}git clone git://github.com/olamy/scm-git-test-one-module.git{code}
> normal anonymous relative:
> {code}git clone git://github.com:olamy/scm-git-test-one-module.git{code}
> normal developer absolute:
> {code}git clone ssh://[EMAIL
> PROTECTED]/olamy/scm-git-test-one-module.git{code}
> normal developer relative:
> {code}git clone ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module{code}
> ssh developer absolute:
> {code}git clone [EMAIL PROTECTED]/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> {code}git clone [EMAIL PROTECTED]:olamy/scm-git-test-one-module{code}
> In reality the ssh:// URL is not always supported. (For example github does
> not). In fact they suggest to use
> normal anonymous absolute:
> {code}git://github.com/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> [EMAIL PROTECTED]:olamy/scm-git-test-one-module.git{code}
> For the initial checkout the developer will use the command line and set
> "[EMAIL PROTECTED]:olamy/scm-git-test-one-module.git" as the remote address.
> So subsequent commits and tags (from the plugin) can work just fine as the
> URL does not need to be specified anymore. But when the release plugin checks
> out the code it will fail if the proper developer url "ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module" (normal developer relative) is
> set. (As the maven pom seems to expect that format).
> There are 3 ways to fix or work around this:
> 1) Use the normal anonymous URLs for both connections (developer and
> anonymous) inside the pom. This will confused developers though as the
> generated site tells the new developers to use the anonymous URL to checkout
> the code. They will not be able to push if they do.
> 2) Have the scm/release plugin ignore the developer URL and use the anonymous
> URL for the checkout. Again this will be confusing on the generated site as
> the normal developer rel/abs URLs might not be supported.
> 3) Somehow store the URL in the format "[EMAIL
> PROTECTED]:olamy/scm-git-test-one-module" in the pom. The problem is that the
> POM expects the normal (RFC 2396) format AFAIU.
--
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-381) url syntax not good enough for the git scm provider
[
http://jira.codehaus.org/browse/MRELEASE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152175#action_152175
]
[EMAIL PROTECTED] edited comment on MRELEASE-381 at 10/28/08 12:12 PM:
--
I think that 3 is the only correct solution. 1 and 2 do not work for github
private repositories. Private repositories require the [EMAIL
PROTECTED]:olamy/scm-git-test-one-module for both checkout and checkin.
was (Author: [EMAIL PROTECTED]):
I think that 3 is the only correct solution. 1 and 2 do not work for
private repositories. Private repositories require the [EMAIL
PROTECTED]:olamy/scm-git-test-one-module for both checkout and checkin.
> url syntax not good enough for the git scm provider
> ---
>
> Key: MRELEASE-381
> URL: http://jira.codehaus.org/browse/MRELEASE-381
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: scm
>Affects Versions: 2.0-beta-7
>Reporter: Torsten Curdt
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 2.0-beta-9
>
>
> The problem is that git supports 2 different URL schemes. For the normal RFC
> 2396 standard and ssh style. So in theory all these styles should work:
> normal anonymous absolute:
> {code}git clone git://github.com/olamy/scm-git-test-one-module.git{code}
> normal anonymous relative:
> {code}git clone git://github.com:olamy/scm-git-test-one-module.git{code}
> normal developer absolute:
> {code}git clone ssh://[EMAIL
> PROTECTED]/olamy/scm-git-test-one-module.git{code}
> normal developer relative:
> {code}git clone ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module{code}
> ssh developer absolute:
> {code}git clone [EMAIL PROTECTED]/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> {code}git clone [EMAIL PROTECTED]:olamy/scm-git-test-one-module{code}
> In reality the ssh:// URL is not always supported. (For example github does
> not). In fact they suggest to use
> normal anonymous absolute:
> {code}git://github.com/olamy/scm-git-test-one-module.git{code}
> ssh developer relative:
> [EMAIL PROTECTED]:olamy/scm-git-test-one-module.git{code}
> For the initial checkout the developer will use the command line and set
> "[EMAIL PROTECTED]:olamy/scm-git-test-one-module.git" as the remote address.
> So subsequent commits and tags (from the plugin) can work just fine as the
> URL does not need to be specified anymore. But when the release plugin checks
> out the code it will fail if the proper developer url "ssh://[EMAIL
> PROTECTED]/~git/olamy/scm-git-test-one-module" (normal developer relative) is
> set. (As the maven pom seems to expect that format).
> There are 3 ways to fix or work around this:
> 1) Use the normal anonymous URLs for both connections (developer and
> anonymous) inside the pom. This will confused developers though as the
> generated site tells the new developers to use the anonymous URL to checkout
> the code. They will not be able to push if they do.
> 2) Have the scm/release plugin ignore the developer URL and use the anonymous
> URL for the checkout. Again this will be confusing on the generated site as
> the normal developer rel/abs URLs might not be supported.
> 3) Somehow store the URL in the format "[EMAIL
> PROTECTED]:olamy/scm-git-test-one-module" in the pom. The problem is that the
> POM expects the normal (RFC 2396) format AFAIU.
--
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: (MANTTASKS-4) System scope not working properly in Maven Antlib
[
http://jira.codehaus.org/browse/MANTTASKS-4?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152173#action_152173
]
Sam Mesh commented on MANTTASKS-4:
--
I'd like to see ant following maven as much as possible like the following:
pom.xml
${basedir}/..
system
${viewRoot}/lib/lib.jar
maven-build.properties
viewRoot=${basedir}/..
maven-build.xml
> System scope not working properly in Maven Antlib
> -
>
> Key: MANTTASKS-4
> URL: http://jira.codehaus.org/browse/MANTTASKS-4
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
> Environment: Mac OS X
>Reporter: Greg Luck
> Attachments: MANTTASKS-4-maven-ant-tasks.patch
>
>
> If I add the following
>
> javax.cache
> jcache
> not_released
> system
>
>
> /Users/gluck/work/ehcache/trunk/tools/jcache.jar
>
> When I so a run I get dropping
> /Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar
> from path as it doesn't exist
> [javac] net/sf/ehcache/jcache/CacheListenerAdaptor.java added as
> net/sf/ehcache/jcache/CacheListenerAdaptor.class doesn't exist.
> [javac] net/sf/ehcache/jcache/Entry.java added as
> net/sf/ehcache/jcache/Entry.class doesn't exist.
> [javac] net/sf/ehcache/jcache/JCache.java added as
> net/sf/ehcache/jcache/JCache.class doesn't exist.
> [javac] net/sf/ehcache/jcache/JCacheFactory.java added as
> net/sf/ehcache/jcache/JCacheFactory.class doesn't exist.
> [javac] net/sf/ehcache/jcache/package.html skipped - don't know how to
> handle it
> dropping
> /Users/gluck/.m2/repository/javax/cache/jcache/not_released/jcache-not_released.jar
> from path as it doesn't exist
> It should not be looking for it there.
> To reproduce just try and use the system scope and systemPath.
--
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-2254) Please synchronize with http://svn.puremvc.org/PureMVC_Java_MultiCore/repo/ repository for release 1.0
Please synchronize with http://svn.puremvc.org/PureMVC_Java_MultiCore/repo/ repository for release 1.0 --- Key: MAVENUPLOAD-2254 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2254 Project: Maven Upload Requests Issue Type: Wish Reporter: Anthony Quinault "org.puremvc","/home/maven/repository-staging/to-ibiblio/maven-puremvc","svn","Anthony Quinault","[EMAIL PROTECTED]",,"http://svn.puremvc.org/PureMVC_Java_MultiCore/repo"; -- 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-3599) webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/MNG-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3599: --- Attachment: webdav.log > webdav does not set http-proxy correctly > > > Key: MNG-3599 > URL: http://jira.codehaus.org/browse/MNG-3599 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1.0-M1 > > Attachments: MNG-3599.patch, webdav.log > > > patch is attached to WAGON-82 > (0001-Make-the-artifact-manager-using-wagons-ProxyInfoProv.patch), utilising > the new APIs in beta-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] Issue Comment Edited: (MNG-3599) webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/MNG-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152148#action_152148 ] bentmann edited comment on MNG-3599 at 10/28/08 10:44 AM: --- The correspondig IT indicates that this is in principle also fixed in 2.0.10 as expected from the SVN history. However, due to MNG-3805 the behavior is not reliable. The wrong dependency resolution picks commons-httpclient 3.0 instead of 3.1 which seems to cause a LinkageError while loading the WebDAV beta-3 wagon, which in turn causes fallback to the bundled beta-2 version. was (Author: bentmann): The correspondig IT indicates that this is in principle also fixed in 2.0.10 as expected from the SVN history. However, due to MNG-3805 the behavior is not reliable. > webdav does not set http-proxy correctly > > > Key: MNG-3599 > URL: http://jira.codehaus.org/browse/MNG-3599 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1.0-M1 > > Attachments: MNG-3599.patch > > > patch is attached to WAGON-82 > (0001-Make-the-artifact-manager-using-wagons-ProxyInfoProv.patch), utilising > the new APIs in beta-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-3805) Ordering of extension class path is indeterministic
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3805: --- Summary: Ordering of extension class path is indeterministic (was: Prefer LinkedHashMap/-Set over HashMap/-Set for artifacts/dependencies for determinsitic ordering) > Ordering of extension class path is indeterministic > --- > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann > Attachments: deterministic-dependency-ordering.patch, log-bad.txt, > log-good.txt > > > One part of Maven where class path ordering hasn't already been fixed in the > past is the extension class path. Apart from a proposed patch, two logs from > our IT testmng3599useHttpProxyForWebDAV are attached. Both were run against > Maven 2.0.10-RC1, with the only difference being one using JDK 1.4 and the > other one 1.6. Not only do these logs substantially differ, the build on JDK > 1.6 even fails due to picking up the wrong extension classes. -- 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: (MNGSITE-42) Update docs about Maven's class loading
[ http://jira.codehaus.org/browse/MNGSITE-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150616#action_150616 ] bentmann edited comment on MNGSITE-42 at 10/28/08 8:23 AM: A list of some issues related to class loading that might be worth to cover in a specification: - MNG-214 - MNG-655 - MNG-1323 - MNG-1898 - MNG-2225 - MNG-2228 - MNG-2749 - MNG-2795 - MNG-2831 - MNG-2892 - MNG-3012 - MNG-3181 - MSITE-60 was (Author: bentmann): A list of some issues related to class loading that might be worth to cover in a specification: - MNG-214 - MNG-655 - MNG-1323 - MNG-1898 - MNG-2225 - MNG-2228 - MNG-2749 - MNG-2795 - MNG-2892 - MNG-3012 - MNG-3181 - MSITE-60 > Update docs about Maven's class loading > --- > > Key: MNGSITE-42 > URL: http://jira.codehaus.org/browse/MNGSITE-42 > Project: Maven 2 Project Web Site > Issue Type: Improvement >Reporter: Benjamin Bentmann >Priority: Minor > > The article about [Maven's class > loading|http://maven.apache.org/guides/mini/guide-maven-classloading.html] > seems to be outdated, e.g. there is no "core" directory nor is plexus-utils > (fully) included in the core realm (shaded starting with Maven 2.0.6). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3806) NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range
NullPointerException when a dependency uses version range and another uses an actual version incompatible with that range - Key: MNG-3806 URL: http://jira.codehaus.org/browse/MNG-3806 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.1.0-M1, 2.0.9 Environment: Windows XP SP2, Maven see above, JDK 6 Reporter: Michael Osipov Priority: Critical Attachments: debug-2.0.9.log, debug-2.1.0-M1.log This is simply a regression/reoccurence of MNG-2123, test dependency makes the whole system fail. Debug logs are attached. If I test with slf4j-nop with soft version 1.5.5 it works flawlessly. Here is the source: http://svn.fckeditor.net/FCKeditor.Java/trunk/ r2607 run with "mvn site package assembly:assembly" -- 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-3599) webdav does not set http-proxy correctly
[ http://jira.codehaus.org/browse/MNG-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152148#action_152148 ] Benjamin Bentmann commented on MNG-3599: The correspondig IT indicates that this is in principle also fixed in 2.0.10 as expected from the SVN history. However, due to MNG-3805 the behavior is not reliable. > webdav does not set http-proxy correctly > > > Key: MNG-3599 > URL: http://jira.codehaus.org/browse/MNG-3599 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1.0-M1 > > Attachments: MNG-3599.patch > > > patch is attached to WAGON-82 > (0001-Make-the-artifact-manager-using-wagons-ProxyInfoProv.patch), utilising > the new APIs in beta-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-3805) Prefer LinkedHashMap/-Set over HashMap/-Set for artifacts/dependencies for determinsitic ordering
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3805: --- Attachment: (was: deterministic-map-ordering.patch) > Prefer LinkedHashMap/-Set over HashMap/-Set for artifacts/dependencies for > determinsitic ordering > - > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann > Attachments: deterministic-dependency-ordering.patch, log-bad.txt, > log-good.txt > > > One part of Maven where class path ordering hasn't already been fixed in the > past is the extension class path. Apart from a proposed patch, two logs from > our IT testmng3599useHttpProxyForWebDAV are attached. Both were run against > Maven 2.0.10-RC1, with the only difference being one using JDK 1.4 and the > other one 1.6. Not only do these logs substantially differ, the build on JDK > 1.6 even fails due to picking up the wrong extension classes. -- 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-3805) Prefer LinkedHashMap/-Set over HashMap/-Set for artifacts/dependencies for determinsitic ordering
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3805: --- Priority: Major (was: Trivial) Description: One part of Maven where class path ordering hasn't already been fixed in the past is the extension class path. Apart from a proposed patch, two logs from our IT testmng3599useHttpProxyForWebDAV are attached. Both were run against Maven 2.0.10-RC1, with the only difference being one using JDK 1.4 and the other one 1.6. Not only do these logs substantially differ, the build on JDK 1.6 even fails due to picking up the wrong extension classes. (was: Sometimes order is important, Maven is learning that the hard way (MNG-1412, MNG-3118, SUREFIRE-61, ...). Methods that don't know for sure that ordering is irrelevant should follow "better safe than sorry" and keep the ordering of input collections. This is basically a clone of MARTIFACT-9, this time aimed at the 2.0.x and 2.1.x branches.) Attachment: log-good.txt log-bad.txt deterministic-dependency-ordering.patch Issue Type: Bug (was: Improvement) Summary: Prefer LinkedHashMap/-Set over HashMap/-Set for artifacts/dependencies for determinsitic ordering (was: Prefer LinkedHashMap over HashMap in ArtifactUtils) > Prefer LinkedHashMap/-Set over HashMap/-Set for artifacts/dependencies for > determinsitic ordering > - > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann > Attachments: deterministic-dependency-ordering.patch, > deterministic-map-ordering.patch, log-bad.txt, log-good.txt > > > One part of Maven where class path ordering hasn't already been fixed in the > past is the extension class path. Apart from a proposed patch, two logs from > our IT testmng3599useHttpProxyForWebDAV are attached. Both were run against > Maven 2.0.10-RC1, with the only difference being one using JDK 1.4 and the > other one 1.6. Not only do these logs substantially differ, the build on JDK > 1.6 even fails due to picking up the wrong extension classes. -- 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-3805) Prefer LinkedHashMap over HashMap in ArtifactUtils
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3805: --- Attachment: deterministic-map-ordering.patch > Prefer LinkedHashMap over HashMap in ArtifactUtils > -- > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: deterministic-map-ordering.patch > > > Sometimes order is important, Maven is learning that the hard way (MNG-1412, > MNG-3118, SUREFIRE-61, ...). Methods that don't know for sure that ordering > is irrelevant should follow "better safe than sorry" and keep the ordering of > input collections. > This is basically a clone of MARTIFACT-9, this time aimed at the 2.0.x and > 2.1.x branches. -- 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-3805) Prefer LinkedHashMap over HashMap in ArtifactUtils
[ http://jira.codehaus.org/browse/MNG-3805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3805: --- Attachment: (was: deterministic-map-ordering.patch) > Prefer LinkedHashMap over HashMap in ArtifactUtils > -- > > Key: MNG-3805 > URL: http://jira.codehaus.org/browse/MNG-3805 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories, Dependencies >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: deterministic-map-ordering.patch > > > Sometimes order is important, Maven is learning that the hard way (MNG-1412, > MNG-3118, SUREFIRE-61, ...). Methods that don't know for sure that ordering > is irrelevant should follow "better safe than sorry" and keep the ordering of > input collections. > This is basically a clone of MARTIFACT-9, this time aimed at the 2.0.x and > 2.1.x branches. -- 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-3805) Prefer LinkedHashMap over HashMap in ArtifactUtils
Prefer LinkedHashMap over HashMap in ArtifactUtils -- Key: MNG-3805 URL: http://jira.codehaus.org/browse/MNG-3805 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories, Dependencies Affects Versions: 2.1.0-M1, 2.0.9 Reporter: Benjamin Bentmann Priority: Trivial Attachments: deterministic-map-ordering.patch Sometimes order is important, Maven is learning that the hard way (MNG-1412, MNG-3118, SUREFIRE-61, ...). Methods that don't know for sure that ordering is irrelevant should follow "better safe than sorry" and keep the ordering of input collections. This is basically a clone of MARTIFACT-9, this time aimed at the 2.0.x and 2.1.x branches. -- 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: (DOXIA-105) review error handling
[ http://jira.codehaus.org/browse/DOXIA-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152136#action_152136 ] Vincent Siveton commented on DOXIA-105: --- Applied in [r708527|http://svn.apache.org/viewvc?rev=708527&view=rev] Leave open to review all errors. > review error handling > - > > Key: DOXIA-105 > URL: http://jira.codehaus.org/browse/DOXIA-105 > Project: Maven Doxia > Issue Type: Improvement > Components: Core >Reporter: Brett Porter > Fix For: 1.0 > > Attachments: DOXIA-105_1.diff > > > Issue to revise how errors are handled through Doxia as there seem to be > occasional stack traces shown for non-fatal errors, and some errors being > swallowed. -- 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: (MCOMPILER-64) "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space after update to java 1.6.0_04
[ http://jira.codehaus.org/browse/MCOMPILER-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152133#action_152133 ] Steinar Bang commented on MCOMPILER-64: --- I upgraded to maven 2.0.9, but the problem persisted. I found this link http://mail-archives.apache.org/mod_mbox/tuscany-dev/200809.mbox/[EMAIL PROTECTED] and changed MAVEN_OPTS from -Xmx512m to -Xmx512m -XX:MaxPermSize=384m And the problem went away. > "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space > after update to java 1.6.0_04 > > > Key: MCOMPILER-64 > URL: http://jira.codehaus.org/browse/MCOMPILER-64 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Maven version: 2.0.8 > Java version: 1.6.0_04 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Joern Huxhorn >Priority: Critical > > After upgrading to java 1.6.0_04 i can't build a big multi-module project > anymore. > java.exe keeps allocating more and more memory (ca. 260MB) until it crashes > with an error like the following: > Failure executing javac, but could not parse the error: > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: PermGen space > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:620) > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) > at java.net.URLClassLoader.access$000(URLClassLoader.java:56) > at java.net.URLClassLoader$1.run(URLClassLoader.java:195) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:188) > at > org.codehaus.plexus.compiler.javac.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:56) > at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) > at com.sun.tools.javac.comp.Annotate.(Annotate.java:52) > at com.sun.tools.javac.comp.Annotate.instance(Annotate.java:36) > at com.sun.tools.javac.jvm.ClassReader.(ClassReader.java:215) > at com.sun.tools.javac.jvm.ClassReader.instance(ClassReader.java:168) > at com.sun.tools.javac.main.JavaCompiler.(JavaCompiler.java:293) > at > com.sun.tools.javac.main.JavaCompiler.instance(JavaCompiler.java:72) > at com.sun.tools.javac.main.Main.compile(Main.java:340) > at com.sun.tools.javac.main.Main.compile(Main.java:279) > at com.sun.tools.javac.main.Main.compile(Main.java:270) > at com.sun.tools.javac.Main.compile(Main.java:87) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:420) > at > org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:141) > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:493) > at > org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:102) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > 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) > Executing the same command with this setup > Maven version: 2.0.8 > Java version: 1.5.0_13 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > works perfectly. java.exe allocates at most 110MB. > Increasing the PermGen space using -XX:MaxPermSize=512M didn't help, either... > This is probably a java regression introduced with j6u4 but it could also be > a problem in org.codehaus.plexus.compiler.javac.IsolatedClassLoader. > I didn't experience any other problems with the new java version, so far. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2251) Aspectj 16.2. upload bundle
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152132#action_152132 ] David J. M. Karlsen commented on MAVENUPLOAD-2251: -- This bundle had bad md5 filenames - this is fixed now (same location) > Aspectj 16.2. upload bundle > --- > > Key: MAVENUPLOAD-2251 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2251 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: David J. M. Karlsen > > Upload bundle for aspectj 1.6.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] Commented: (MAVENUPLOAD-2250) Upload bundle for opensymhony.org's quartz scheduler
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152131#action_152131 ] David J. M. Karlsen commented on MAVENUPLOAD-2250: -- Not this (the attached one) archive at least: skunk:/tmp/x$ unzip ../org.opensymphony.quartz.161.zip Archive: ../org.opensymphony.quartz.161.zip creating: org/ creating: org/opensymphony/ creating: org/opensymphony/quartz/ creating: org/opensymphony/quartz/quartz-jboss/ creating: org/opensymphony/quartz/quartz-jboss/1.6.1/ inflating: org/opensymphony/quartz/quartz-jboss/1.6.1/quartz-jboss-1.6.1.pom.sha1 inflating: org/opensymphony/quartz/quartz-jboss/1.6.1/quartz-jboss-1.6.1.jar.sha1 inflating: org/opensymphony/quartz/quartz-jboss/1.6.1/quartz-jboss-1.6.1.jar.md5 inflating: org/opensymphony/quartz/quartz-jboss/1.6.1/quartz-jboss-1.6.1.pom.md5 inflating: org/opensymphony/quartz/quartz-jboss/1.6.1/quartz-jboss-1.6.1.pom inflating: org/opensymphony/quartz/quartz-jboss/1.6.1/quartz-jboss-1.6.1.jar creating: org/opensymphony/quartz/quartz-oracle/ creating: org/opensymphony/quartz/quartz-oracle/1.6.1/ inflating: org/opensymphony/quartz/quartz-oracle/1.6.1/quartz-oracle-1.6.1.pom.sha1 inflating: org/opensymphony/quartz/quartz-oracle/1.6.1/quartz-oracle-1.6.1.jar.sha1 inflating: org/opensymphony/quartz/quartz-oracle/1.6.1/quartz-oracle-1.6.1.jar.md5 inflating: org/opensymphony/quartz/quartz-oracle/1.6.1/quartz-oracle-1.6.1.pom.md5 inflating: org/opensymphony/quartz/quartz-oracle/1.6.1/quartz-oracle-1.6.1.pom inflating: org/opensymphony/quartz/quartz-oracle/1.6.1/quartz-oracle-1.6.1.jar creating: org/opensymphony/quartz/quartz-weblogic/ creating: org/opensymphony/quartz/quartz-weblogic/1.6.1/ inflating: org/opensymphony/quartz/quartz-weblogic/1.6.1/quartz-weblogic-1.6.1.pom.sha1 inflating: org/opensymphony/quartz/quartz-weblogic/1.6.1/quartz-weblogic-1.6.1.jar.sha1 inflating: org/opensymphony/quartz/quartz-weblogic/1.6.1/quartz-weblogic-1.6.1.jar.md5 inflating: org/opensymphony/quartz/quartz-weblogic/1.6.1/quartz-weblogic-1.6.1.pom.md5 inflating: org/opensymphony/quartz/quartz-weblogic/1.6.1/quartz-weblogic-1.6.1.pom inflating: org/opensymphony/quartz/quartz-weblogic/1.6.1/quartz-weblogic-1.6.1.jar creating: org/opensymphony/quartz/quartz-all/ creating: org/opensymphony/quartz/quartz-all/1.6.1/ inflating: org/opensymphony/quartz/quartz-all/1.6.1/quartz-all-1.6.1.pom.sha1 inflating: org/opensymphony/quartz/quartz-all/1.6.1/quartz-all-1.6.1.jar.sha1 inflating: org/opensymphony/quartz/quartz-all/1.6.1/quartz-all-1.6.1.jar.md5 inflating: org/opensymphony/quartz/quartz-all/1.6.1/quartz-all-1.6.1.pom.md5 inflating: org/opensymphony/quartz/quartz-all/1.6.1/quartz-all-1.6.1.pom inflating: org/opensymphony/quartz/quartz-all/1.6.1/quartz-all-1.6.1.jar creating: org/opensymphony/quartz/quartz/ creating: org/opensymphony/quartz/quartz/1.6.1/ inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1-javadoc.jar.sha1 inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1-javadoc.jar.md5 inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1-javadoc.jar inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1.pom.sha1 inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1.jar.sha1 inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1.jar.md5 inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1.pom.md5 inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1.jar inflating: org/opensymphony/quartz/quartz/1.6.1/quartz-1.6.1.pom skunk:/tmp/x$ unzip ../org.opensymphony.quartz.161.zip skunk:/tmp/x$ find . -name skunk:/tmp/x$ > Upload bundle for opensymhony.org's quartz scheduler > > > Key: MAVENUPLOAD-2250 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2250 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: David J. M. Karlsen > Attachments: org.opensymphony.quartz.161.zip > > > Bundle attached as file upload -- 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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152129#action_152129 ] Ceki Gulcu commented on MNG-2045: - Thank you Joerg. The change you suggested worked beautifully. > Maven can't compile against sibling test-jar dependency in multiproject (Test > Attached) > --- > > Key: MNG-2045 > URL: http://jira.codehaus.org/browse/MNG-2045 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: WinXP >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 2.0.11 > > Attachments: it1021.tar.gz, mng-2045-ittest.zip, > MNG-2045-maven-project-r577340.patch1, MNG-2045-maven-project-r577340.patch2, > sample.zip > > > I have 2 projects under a parent like so: > --Parent > --- sample-jar > --- sample-jar-user > sample-jar builds and installs a test-jar along with the normal jar. > sample-jar-user depends on the test-jar at compile time. When I build from > the parent folder, the build fails because it can't find the class. When I go > to sample-jar-user and build, it works fine. > In the attached test case, to reproduce: > from the root folder, run mvn clean install - See it fail. > cd sample-jar-user; mvn clean install - see it succeed. > I remember reading somewhere that in multiprojects, maven attempts to locate > the sibling classes in the source tree instead of using the jars from the > repository. I'm guessing the problem is here that it's not looking in > ../sample-jar/target/test-classes for this code, but really one should expect > this to come from 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: (MNG-3766) toolchains not found in extensions
[ http://jira.codehaus.org/browse/MNG-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3766: -- Fix Version/s: (was: 2.0.11) 2.1.0-M2 agreed. I'd originally intended this only for 2.1.0-M2, had just thought to investigate the impact of a potential fix before pulling the trigger on 2.0.10 > toolchains not found in extensions > -- > > Key: MNG-3766 > URL: http://jira.codehaus.org/browse/MNG-3766 > Project: Maven 2 > Issue Type: Bug > Components: Settings >Affects Versions: 2.0.9, 2.1.0-M1 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 2.1.0-M2 > > > There's currently no way to plugin in new toolchains without placing them in > M2_HOME/lib. For wagons to be available in extensions, the extension manager > explicitly registers them - so I propose to do the same in 2.1.0-M2 for > toolchains, and only support the Java toolchains in 2.0.9. -- 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-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152123#action_152123
]
Henrik Brautaset Aronsen commented on MNG-3057:
---
Hi Maxim.
I'm attaching [^maven-install-parent.patch], which is the one I've been using
locally for awhile. It fixes dots in property names and the properties
replacements you mentioned, as well as the failing unit tests.
I am not using nested properties and mvn deploy myself, and haven't given that
much thought -- sorry about that.
I don't think the maven team have any plans of including *this* patch, but
there's ongoing work in MNG-624 to do something simliar which [might be
included in Maven
2.1.0-M6|http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan] .
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch, maven-install-parent.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
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-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henrik Brautaset Aronsen updated MNG-3057:
--
Attachment: maven-install-parent.patch
> properties not expanded in generated POMs when building A/B/C nested projects
> -
>
> Key: MNG-3057
> URL: http://jira.codehaus.org/browse/MNG-3057
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.7
>Reporter: George Armhold
> Fix For: 2.0.x
>
> Attachments: example.tar.gz, generated-poms.tar.gz,
> InstallMojo.java.patch, InstallMojo.java.patch, maven-install-parent.patch
>
>
> Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
> I checked out and built 2.0.8 because I was interested in Jason van Zyl's
> patch for MNG-2619- "building from the middle pom of a
> (parent,child,grandchild) heirarchy fails". The fix works for the most part,
> but there still seems to be a problem with the poms that get generated during
> the install goal. The poms that get installed into .m2/repository do not
> have properties interpolated. If I run maven like:
>$ mvn install -Dglobal-version=1.0.0
> I get poms with the string "${global-version}" embedded in the resulting poms
> rather than what I specify on the command line (or in settings.xml). The
> build works properly aside from this, and if I do "mvn help:effective-pom"
> the properties are correctly interpolated.
> I've attached a tarfile with an example A/B/C build structure that exhibits
> this behavior, as well as the generated poms.
> Many thanks for your attention.
--
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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[
http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152118#action_152118
]
Joerg Schaible commented on MNG-2045:
-
For whatever it is worth, you may define the dependency as
{code:xml}
ch.qos.logback
logback-core
test-jar
test
{code}
at least such a declaration works in quite some of our projects.
> Maven can't compile against sibling test-jar dependency in multiproject (Test
> Attached)
> ---
>
> Key: MNG-2045
> URL: http://jira.codehaus.org/browse/MNG-2045
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: WinXP
>Reporter: Brian Fox
>Assignee: Brian Fox
> Fix For: 2.0.11
>
> Attachments: it1021.tar.gz, mng-2045-ittest.zip,
> MNG-2045-maven-project-r577340.patch1, MNG-2045-maven-project-r577340.patch2,
> sample.zip
>
>
> I have 2 projects under a parent like so:
> --Parent
> --- sample-jar
> --- sample-jar-user
> sample-jar builds and installs a test-jar along with the normal jar.
> sample-jar-user depends on the test-jar at compile time. When I build from
> the parent folder, the build fails because it can't find the class. When I go
> to sample-jar-user and build, it works fine.
> In the attached test case, to reproduce:
> from the root folder, run mvn clean install - See it fail.
> cd sample-jar-user; mvn clean install - see it succeed.
> I remember reading somewhere that in multiprojects, maven attempts to locate
> the sibling classes in the source tree instead of using the jars from the
> repository. I'm guessing the problem is here that it's not looking in
> ../sample-jar/target/test-classes for this code, but really one should expect
> this to come from 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
