[jira] Commented: (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
http://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=253921#action_253921
]
luke w patterson commented on MNG-4998:
---
maybe ${project.properties.myProperty} could be initialized if ${myProperty}
isn't null
how about -
for non-pluginconfiguration sections:
* ${project.properties.myProperty} is evaluated static/eager to whatever
${myProperty} evaluates to
* if ${myProperty} is null, then it is left as
${project.properties.myProperty}
for pluginconfiguration sections:
* ${project.properties.myProperty} is initialized with whatever ${myProperty}
evaluates to
* plugins can override the initial value
* the effective-pom/pre-run interpolation always sees/displays it as
${project.properties.myProperty}
Variables interpolation: dynamic in Maven 2, static in Maven 3
--
Key: MNG-4998
URL: http://jira.codehaus.org/browse/MNG-4998
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.2
Reporter: Evgeny Goldin
Please, see
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
It demonstrates two examples where expression with ${variables} are
interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
properties and effect expressions interpolated later, Maven 3 also allows
to update properties but all expressions are interpolated with their old
values.
I believe Maven 2 dynamic behavior is much more preferable than Maven 3
Ant-like stickiness to what's defined in properties.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
http://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=253734#action_253734
]
luke w patterson commented on MNG-4998:
---
what about using a new expression like ${project.properties.myProperty} ?
in the plugin configuration section, it will be resolved dynamic/lazy
in other sections either:
* not interpolated (evaluates to the original string of
${project.properties.myProperty})
* it is resolved static/eager
the existing references to ${myProperty} would be resolved just like they are
now
Variables interpolation: dynamic in Maven 2, static in Maven 3
--
Key: MNG-4998
URL: http://jira.codehaus.org/browse/MNG-4998
Project: Maven 2 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.2
Reporter: Evgeny Goldin
Please, see
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
It demonstrates two examples where expression with ${variables} are
interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
properties and effect expressions interpolated later, Maven 3 also allows
to update properties but all expressions are interpolated with their old
values.
I believe Maven 2 dynamic behavior is much more preferable than Maven 3
Ant-like stickiness to what's defined in properties.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MINVOKER-112) duplicate script classpath entries are not filtered out, can cause ClassCastException
[
http://jira.codehaus.org/browse/MINVOKER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
luke w patterson updated MINVOKER-112:
--
Attachment: script-classpath-duplicates-fix.patch
(attaching fix patch)
Here's a small, clean patch to fix the issue.
It simply removes any class path entries that are duplicated. Like I mentioned
earlier, the logic could probably be smarter, and could try to merge the
dependencies using GAV awareness, but this is a good start for now. This patch
fixes situations that would otherwise be clearly wrong (two of same jars on
classpath). I don't think it could cause any passivity issues later if the
logic was made more robust.
duplicate script classpath entries are not filtered out, can cause
ClassCastException
-
Key: MINVOKER-112
URL: http://jira.codehaus.org/browse/MINVOKER-112
Project: Maven 2.x Invoker Plugin
Issue Type: Bug
Reporter: luke w patterson
Attachments: script-classpath-duplicates-fix.patch,
script-classpath-duplicates-it.patch
(it test case attached)
when addTestClassPath
http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#addTestClassPath
is set to true but the consuming project also depends on groovy or
beanshell, scripts fail with ClassCastException,
because the jars end up on the classpath twice
error example:
{noformat}
groovy.lang.GroovyRuntimeException: Failed to create Script instance for
class: class Script1. Reason: java.lang.ClassCastException: Script1 cannot be
cast to groovy.lang.GroovyObject
at
org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:432)
at groovy.lang.GroovyShell.parse(GroovyShell.java:584)
at groovy.lang.GroovyShell.parse(GroovyShell.java:564)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:542)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:518)
at
org.apache.maven.plugin.invoker.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
{noformat}
I created a fix locally, but it's rough right now. Will polish it up and
submit later. Basically, it adds
{code}
/**
* @parameter expression=${plugin.artifacts}
* @required
* @readonly
*/
private List pluginArtifacts;
{code}
to AbstractInvokerMojo, and then spins through the Artifacts, retrieving
their file paths, and removes those from the list sent to
scriptRunner.setClassPath
Granted, the proposed fix could be smarter, cause it only filters out exact
matches, but it's better than the current behavior.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MINVOKER-113) update to Groovy 1.7.5 (from 1.5.6)
update to Groovy 1.7.5 (from 1.5.6) --- Key: MINVOKER-113 URL: http://jira.codehaus.org/browse/MINVOKER-113 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: luke w patterson Attachments: update-groovy.patch (patch attached, assumes MINVOKER-112 patch has been applied) There have been many fixes, and all sorts of new stuff has been added, but the thing I'm most interested in is Grape http://groovy.codehaus.org/Grape. Having Grape would also solve MINVOKER-63, since the dependency could just be grabbed right in the script. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MCHECKSTYLE-129) Unable To Load configLocation From URL
[ http://jira.codehaus.org/browse/MCHECKSTYLE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=249289#action_249289 ] luke w patterson commented on MCHECKSTYLE-129: -- You shouldn't need to do anything special besides update the version to 2.6. It worked for me after updating. Are you explicitly setting plugin version? (remembering that versions in build and reporting sections are configured separately) When you run with -X, what version does it say you are using? Unable To Load configLocation From URL -- Key: MCHECKSTYLE-129 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-129 Project: Maven 2.x Checkstyle Plugin Issue Type: Bug Affects Versions: 2.5 Environment: Windows Vista Maven 2.2.1 Reporter: Allan Shoup Assignee: Olivier Lamy Priority: Blocker Fix For: 2.6 Attachments: checkstyle-new.zip, checkstyle-old.zip With maven-checkstyle-plugin 2.5, I can no longer specify a URL in the configLocation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MINVOKER-114) Update plugin code to use Java 5 language features
Update plugin code to use Java 5 language features -- Key: MINVOKER-114 URL: http://jira.codehaus.org/browse/MINVOKER-114 Project: Maven 2.x Invoker Plugin Issue Type: Improvement Reporter: luke w patterson Attachments: invoker-java-5.patch (Huge patch attached. Hopefully it can get reviewed/applied soon, before it becomes stale. Luckily the patch consists only of low-risk changes that shouldn't affect the logic functionality.) Since the plugin now requires Java 5 anyways (MINVOKER-111), might as well update the code to take advantage of better language features. * Removed all unavoidable raw type warnings. * Where possible/equivalent, converted Iterator-based loops to enhanced for loops. * Removed unnecessary dependencies to Iterator. * Removed unnecessary casts. * Enabled useJava5 parameter of modello-maven-plugin. These changes should make it easier to maintain the code later. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MINVOKER-112) duplicate script classpath entries are not filtered out, can cause ClassCastException
duplicate script classpath entries are not filtered out, can cause
ClassCastException
-
Key: MINVOKER-112
URL: http://jira.codehaus.org/browse/MINVOKER-112
Project: Maven 2.x Invoker Plugin
Issue Type: Bug
Reporter: luke w patterson
Attachments: script-classpath-duplicates-it.patch
(it test case attached)
when addTestClassPath
http://maven.apache.org/plugins/maven-invoker-plugin/run-mojo.html#addTestClassPath
is set to true but the consuming project also depends on groovy or beanshell,
scripts fail with ClassCastException,
because the jars end up on the classpath twice
error example:
{noformat}
groovy.lang.GroovyRuntimeException: Failed to create Script instance for class:
class Script1. Reason: java.lang.ClassCastException: Script1 cannot be cast to
groovy.lang.GroovyObject
at
org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:432)
at groovy.lang.GroovyShell.parse(GroovyShell.java:584)
at groovy.lang.GroovyShell.parse(GroovyShell.java:564)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:542)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:518)
at
org.apache.maven.plugin.invoker.GroovyScriptInterpreter.evaluateScript(GroovyScriptInterpreter.java:83)
{noformat}
I created a fix locally, but it's rough right now. Will polish it up and
submit later. Basically, it adds
{code}
/**
* @parameter expression=${plugin.artifacts}
* @required
* @readonly
*/
private List pluginArtifacts;
{code}
to AbstractInvokerMojo, and then spins through the Artifacts, retrieving their
file paths, and removes those from the list sent to scriptRunner.setClassPath
Granted, the proposed fix could be smarter, cause it only filters out exact
matches, but it's better than the current behavior.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-297) Wagon SCM does not automatically create missing directories during deployment
[ http://jira.codehaus.org/browse/WAGON-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=248620#action_248620 ] luke w patterson commented on WAGON-297: mvn-svn-wagon is the way to go: http://code.google.com/p/maven-svn-wagon/ Wagon SCM does not automatically create missing directories during deployment - Key: WAGON-297 URL: http://jira.codehaus.org/browse/WAGON-297 Project: Maven Wagon Issue Type: Bug Components: wagon-scm Affects Versions: 1.0-beta-6 Reporter: Maria Odea Ching Attachments: WAGON-297.patch, WAGON-297.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-334) Run a build on generated project during integration test
[
http://jira.codehaus.org/browse/ARCHETYPE-334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=237012#action_237012
]
luke w patterson commented on ARCHETYPE-334:
some related discussion here:
http://maven.40175.n5.nabble.com/unit-testing-archetypes-td75257.html#a75257
Run a build on generated project during integration test
Key: ARCHETYPE-334
URL: http://jira.codehaus.org/browse/ARCHETYPE-334
Project: Maven Archetype
Issue Type: New Feature
Components: Plugin
Affects Versions: 2.0-alpha-5
Reporter: Jesse Glick
Priority: Minor
Currently it seems that {{archetype:integration-test}} just creates some
projects from the archetype with defined parameters and compares their
contents to golden copies. (By the way
http://maven.apache.org/archetype/maven-archetype-plugin/integration-test-mojo.html
does not document this in any way; I had to read {{IntegrationTestMojo}}
source to find this out.)
While that might be useful if you happen to have very complex Velocity
templates and need to test that property substitution works the right way
with different inputs, most archetypes have rather simple templates that just
substitute {{artifactId}} and the like, in which case verifying that the
created POM matches some fixed text is worse than useless: if you make any
changes to the archetype, you are simply going to make identical changes to
the test's golden files.
What would be much more useful in my experience is to check that the newly
generated project actually builds. For example, run {{mvn post-clean verify}}
and check that at a minimum the build completes normally. This would catch
common mistakes you might make when editing archetypes: mistyping a plugin or
dependency name, introducing compilation errors into Java sources, etc. It
would also be valuable to check that no warnings are emitted - such as the
infamous {{File encoding has not been set...}} message when
{{project.build.sourceEncoding}} has been forgotten.
(You could also run {{mvn post-site}}, checking for warnings/errors, and
compare {{target/site}} to a golden copy.)
CI builders running integration tests might also do so with a pristine local
repository (plus cache manager mirroring official public repos), which would
catch accidental references to unreleased plugin/dependency versions that the
archetype developer happened to have in their local 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] Created: (ARCHETYPE-328) Allow goals to be attached to post Velocity template process in archetype generation
Allow goals to be attached to post Velocity template process in archetype generation Key: ARCHETYPE-328 URL: http://jira.codehaus.org/browse/ARCHETYPE-328 Project: Maven Archetype Issue Type: New Feature Reporter: luke w patterson see user proposal doc: http://docs.codehaus.org/display/MAVENUSER/Allow+goals+to+be+attached+to+post+Velocity+template+process+in+archetype+generation -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-145) Outputting dependency resolution/tree in a well known _machine readable_ output format
[
http://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=229685#action_229685
]
luke w patterson commented on MDEP-145:
---
pretty cool, Alexander
flexible approach
Outputting dependency resolution/tree in a well known _machine readable_
output format
--
Key: MDEP-145
URL: http://jira.codehaus.org/browse/MDEP-145
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: resolve, tree
Affects Versions: 2.0
Reporter: Samuel Le Berrigaud
Assignee: Brian Fox
Fix For: 2.2
Attachments: MDEP-145-velocity.patch, MDEP-145.zip, treegraph.patch
Currently (at least on trunk) one can output the dependencies in a file.
However the file output doesn't follow any specific format, except from being
the exact same output than on the console.
I would be nice to have an easily parse-able, format so that tools could
leverage the dependency resolution/tree. I am thinking for example of
continuous integration tools that could report on added/removed/updated
dependencies on modules.
The format could be xml, json or something else. I've been playing with the
current output to make it so that:
* the first line describes the current module for which dependency resolution
is done, formatted as such: {{groupId:artifactId:packaging:version}}
* every following line is a dependency (indented by 2 or more spaces),
formatted as such: {{groupId:artifactId:packaging:version:scope}}
This already is easy to parse.
What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-566) prepare goal fails if localRepoDirectory doesn't exist, should instead create it
prepare goal fails if localRepoDirectory doesn't exist, should instead create
it
--
Key: MRELEASE-566
URL: http://jira.codehaus.org/browse/MRELEASE-566
Project: Maven 2.x Release Plugin
Issue Type: Bug
Reporter: luke w patterson
Attachments: maven-release-plugin-local-repo.patch
(patch attached, no testcase but it is fairly straightforward)
if the directory listed in the localRepoDirectory [1] parameter of
release:prepare doesn't exist, the build fails
e.g. if I set {code}
localRepoDirectory${project.build.directory}\local-repo-during-release/localRepoDirectory
{code}
I get error:
{code}
java.lang.IllegalArgumentException: Local repository location:
'blah\target\local-repo-during-release' is NOT a directory.
at
org.apache.maven.shared.invoker.MavenCommandLineBuilder.setEnvironmentPaths(MavenCommandLineBuilder.java:359)
at
org.apache.maven.shared.invoker.MavenCommandLineBuilder.build(MavenCommandLineBuilder.java:90)
at
org.apache.maven.shared.invoker.DefaultInvoker.execute(DefaultInvoker.java:91)
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:387)
at
org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:413)
at
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:82)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:42)
at
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.simulate(RunPrepareGoalsPhase.java:54)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:199)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:140)
at
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:103)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:211)
at
org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:181)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{code}
Ideally, one could avoid the null check in the patch, but then a lot of tests
would have to be updated, and I wasn't sure if it was worth it.
Thanks
[1]
http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#localRepoDirectory
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MENFORCER-100) Strings generated through ExpressionEvaluator aren't BeanShell-escaped
Strings generated through ExpressionEvaluator aren't BeanShell-escaped
--
Key: MENFORCER-100
URL: http://jira.codehaus.org/browse/MENFORCER-100
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Reporter: luke w patterson
... moving over from mailing list
http://old.nabble.com/enforcer-BeanShell-script%2C-retrieving-escaped-stuff-from-ExpressionEvaluator-td28626298.html
characters like '/' and such need to be escaped properly when injected into
BeanShell Interpreter
expressions like ${project.basedir} could easily contain the '/' character
'/' info for BeanShell:
http://www.beanshell.org/manual/bshmanual.html#Working_with_Dirctories_and_Paths
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (ARCHETYPE-299) create-from-project doesn't need to add extensionstrue/extensions to template pom
create-from-project doesn't need to add extensionstrue/extensions to template pom - Key: ARCHETYPE-299 URL: http://jira.codehaus.org/browse/ARCHETYPE-299 Project: Maven Archetype Issue Type: Improvement Components: Creator Reporter: luke w patterson Priority: Minor the archetype:create-from-project goal creates a pom with build extensions extension groupIdorg.apache.maven.archetype/groupId artifactIdarchetype-packaging/artifactId version2.0-alpha-4/version /extension /extensions plugins plugin artifactIdmaven-archetype-plugin/artifactId version2.0-alpha-4/version extensionstrue/extensions /plugin /plugins /build from what I understand, the extensionstrue/extensions part isn't needed maven-archetype-plugin's component.xml: http://www.jarvana.com/jarvana/view/org/apache/maven/plugins/maven-archetype-plugin/2.0-alpha-4/maven-archetype-plugin-2.0-alpha-4.jar!/META-INF/plexus/components.xml archetype-packaging's components.xml: http://www.jarvana.com/jarvana/view/org/apache/maven/archetype/archetype-packaging/2.0-alpha-4/archetype-packaging-2.0-alpha-4.jar!/META-INF/plexus/components.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-57) Support empty directory creation
[ http://jira.codehaus.org/browse/ARCHETYPE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215960#action_215960 ] luke w patterson commented on ARCHETYPE-57: --- Greg Wittel wrote: Just a comment that I've filed ARCHETYPE-289 to try to get them to fix this. The workaround that Marek posted works: http://jira.codehaus.org/browse/ARCHETYPE-57?focusedCommentId=208054page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_208054 I just use archetype-metadata.xml now, and don't use archetype.xml at all. Not sure why both exist. How metadata on an archetype is stored? http://maven.apache.org/plugins/maven-archetype-plugin/specification/archetype-metadata.html Support empty directory creation Key: ARCHETYPE-57 URL: http://jira.codehaus.org/browse/ARCHETYPE-57 Project: Maven Archetype Issue Type: Improvement Components: Creator Affects Versions: 1.0-alpha-4 Reporter: Mark Hobson Fix For: 2.0-alpha-4 Attachments: ARCHETYPE-57-patch archetype.xml currently provides no way of creating empty directories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-47) use an xml schema for archetype.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=214730#action_214730 ] luke w patterson commented on ARCHETYPE-47: --- an xsd generated from Modello descriptor archetype.mdo has just been published (with documentation) good news, couple of questions: * is this the right url http://maven.apache.org/xsd/archetype-1.0.0.xsd ? don't see anything there yet * will an xsd for archetype-metadata.xml be published also? use an xml schema for archetype.xml --- Key: ARCHETYPE-47 URL: http://jira.codehaus.org/browse/ARCHETYPE-47 Project: Maven Archetype Issue Type: New Feature Affects Versions: 1.0-alpha-5 Environment: all Reporter: Gregory Kick Attachments: archetype-v1_0_0.png, archetype-v1_0_0.xsd like pom.xml and settings.xml, i would like to see archetype.xml have an xml schema. not only does it provide quick validation, but it is useful for auto-completion in xml editors. it could also have applications in the maven-archetype-plugin because jaxb can provide quick-and-easy unmarshalling. i have included a schema constructed to match the description found in http://maven.apache.org/guides/mini/guide-creating-archetypes.html . it has been attached with a diagram of the structure for those not familiar with schema syntax. it's pretty simple. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-245) goal to check classpath for duplicate resources/classes
[ http://jira.codehaus.org/browse/MDEP-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=214007#action_214007 ] luke w patterson commented on MDEP-245: --- One option for now is JBoss' Tattletale tool: http://www.jboss.org/tattletale an example of its use: http://insuchaworld.blogspot.com/2010/03/using-jboss-tattletale-tool-in-maven.html goal to check classpath for duplicate resources/classes --- Key: MDEP-245 URL: http://jira.codehaus.org/browse/MDEP-245 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Reporter: Joerg Schaible Assignee: Brian Fox Priority: Minor The classpath sometimes contains unintended duplicate resources and classes e.g.: # an artifact is present in two different versions at the same time, because it changed its groupId or artifactId, but no relocation POM has been provided by the artifact's author # an artifact has been split into several artifacts (avalon-famework = avalon-framework-api and avalon-framework-impl) # an artifact has a collection of foreign classes (CGLIB 2.x contains stuff from ASM 1.5) A new goal of the dependency plugin might detect such cases. Obviously there are cases, when this is expected (stax-api implements stuff provided also by JDK 6) or cannot be avoided in general (even xpp3_min contains two classes from xmlpull-api) or is even part of the spec (SPI files in META-INF/services). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (MSHARED-98) Maven2OsgiConverter unnecessarily pads version numbers
[ http://jira.codehaus.org/browse/MSHARED-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=212823#action_212823 ] luke w patterson commented on MSHARED-98: - saw something that might be related, throwing this out there so there's a trail: Fix inconsistent maven-osgi version conversion between maven-bundle-plugin and DefaultMaven2OsgiConverter https://issues.apache.org/jira/browse/FELIX-2173 Maven2OsgiConverter unnecessarily pads version numbers -- Key: MSHARED-98 URL: http://jira.codehaus.org/browse/MSHARED-98 Project: Maven Shared Components Issue Type: Bug Components: maven-osgi Reporter: Matthew Beermann Attachments: MSHARED-98-maven-osgi.patch, MSHARED-98-maven-osgi.patch In DefaultMavenOsgiConverter#getVersion(), there's logic to the effect of: /* convert * 1.string - 1.0.0.string * 1.2.string - 1.2.0.string * 1 - 1.0.0 * 1.1- 1.1.0 */ ...which is unnecessary; the version number only needs to be padded out to three places when there's a qualifier present. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=204969#action_204969 ] luke w patterson commented on ARCHETYPE-273: Here is a new patch ... New mojo has been renamed to ImportMojo ... since it now supports importing not only all archetypes but also importing just single fully specified archetype Thanks Stevo, I applied the patch locally and tested it. I only ran into one issue: org.apache.maven.archetype.source.ArchetypeDataSourceException: Error parsing archetype catalog. at org.apache.maven.archetype.source.CatalogArchetypeDataSource.readCatalog(CatalogArchetypeDataSource.java:202) at org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:114) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:210) at org.apache.maven.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:201) at org.apache.maven.archetype.mojos.ImportMojo.execute(ImportMojo.java:153) You'll get that error if the remote repo's archetype-catalog.xml file is missing or empty. At first I thought it was just an ordering issue in ImportMojo.execute, where the single import stuff should be done first, but as I dig deeper it looks like there are some more checks around the archetype entry's existence in archetype-catalog.xml. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-220__273_interactive_combo.patch, org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-277) add goal to import archetype into local catalog
add goal to import archetype into local catalog --- Key: ARCHETYPE-277 URL: http://jira.codehaus.org/browse/ARCHETYPE-277 Project: Maven Archetype Issue Type: Improvement Reporter: luke w patterson similar in purpose to ARCHETYPE-273, import-archetype would simply import one archetype from a repo (local or remote) into the local catalog -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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: (ARCHETYPE-278) add property to generate goal which imports archetype into local catalog
add property to generate goal which imports archetype into local catalog Key: ARCHETYPE-278 URL: http://jira.codehaus.org/browse/ARCHETYPE-278 Project: Maven Archetype Issue Type: Improvement Reporter: luke w patterson during the generate goal, the new property would determine if the archetype currently being run will be imported/appended to local catalog this would be much more convenient than crawling the local repo after running a new archetype -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203860#action_203860 ] luke w patterson commented on ARCHETYPE-273: Stevo said: [regarding individual archetype imports] Nevertheless, IMO a separate issue should be created for this. agreed, I created: add goal to import archetype into local catalog ARCHETYPE-277 add property to generate goal which imports archetype into local catalog ARCHETYPE-278 add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203867#action_203867 ] luke w patterson commented on ARCHETYPE-273: while if I understood Luke well he'd like support for importing single archetype Yes I want to be able to publish individual archetypes without necessarily updating/managing/publishing a catalog file. I would want a Maven CLI command which can import my archetype into the local catalog so they can use it later (through CLI or m2eclipse). I guess if your patch is applied I could just attach (using build-helper-maven-plugin) a catalog file to each of my archetypes, and have them import that catalog. That is if it doesn't have to be named a specific name (archetype-catalog.xml). add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (ARCHETYPE-276) Allow archetypes to declare minimum version of maven-archetype-plugin they need
Allow archetypes to declare minimum version of maven-archetype-plugin they need
---
Key: ARCHETYPE-276
URL: http://jira.codehaus.org/browse/ARCHETYPE-276
Project: Maven Archetype
Issue Type: Improvement
Reporter: luke w patterson
In my archetype, I want to specify the minimum version of
maven-archetype-plugin which I expect/need.
e.g. if I want to use features enabled in ARCHETYPE-192, stuff like this:
requiredProperty key=myModule /
requiredProperty key=package
defaultValueorg.foo.bar.${myModule}.${myApp}/defaultValue
If my archetype assumes that replacement functionality is in place, and it
ends up not being in place, I'll have directories named ${myModule} and
${myApp}.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-273) add goal to import remote archetype catalog into local catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203731#action_203731 ] luke w patterson commented on ARCHETYPE-273: Dan, I was looking over your patch to see if it could be augmented to include what I consider to be a necessary goal: import-archetype import-archetype would simply import one archetype from a repo (local or remote) into the local catalog Does your patch provide any foundation code for for an import-archetype goal? I'll keep reading through it. add goal to import remote archetype catalog into local catalog -- Key: ARCHETYPE-273 URL: http://jira.codehaus.org/browse/ARCHETYPE-273 Project: Maven Archetype Issue Type: New Feature Components: Archetypes Affects Versions: 2.0-alpha-4 Reporter: Dan Allen Attachments: org.apache.maven.archetype.maven-archetype-ARCHETYPE-273__220_combo.patch If I've just published a new archetype, I need to be able to provide the developer with a command that allows them to educate their local catalog about the new archetypes that area available. Currently, it's possible to specify an archetype catalog for a single run of the generate goal: mvn archetype:generate -DarchetypeCatalog=http://example.com/maven2 But the catalog is transient. Those entries are not remembered. The next time I run the generate goal... mvn archetype:generate ...the archetypes in the catalog provided in the previous command are not offered as options. This is especially problematic when using an IDE to create a new Maven project, because the mechanism for providing an archetype catalog differs in each IDE. We want them to be in the local repository. Simply point, it's too much information for the developer to have to reconcile, especially since using an archetype is likely the developer's first exposure to your project. It needs to be simple. What I'm looking for is a command that I can give the developer to import the entries from a remote archetype catalog. A discovery mechanism so to speak. I envision the following sequence to work: mvn archetype:import -DarchetypeCatalog=http://example.com/maven2 mvn archetype:generate At this point, the developer would see options for the imported archetypes. The import goal could even download the archetype JAR files at the same time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-57) Support empty directory creation
[ http://jira.codehaus.org/browse/ARCHETYPE-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203420#action_203420 ] luke w patterson commented on ARCHETYPE-57: --- Is this bug truly fixed? At this point one can only specify individual files to be created but not empty directories. http://maven.apache.org/guides/mini/guide-creating-archetypes.html I can't get this to work. I wonder if it is an OS thing. I'm using Windows. Does anyone know of an archetype in the wild that is taking advantage of this feature? I'd like to see what it does when I run it on my box. Support empty directory creation Key: ARCHETYPE-57 URL: http://jira.codehaus.org/browse/ARCHETYPE-57 Project: Maven Archetype Issue Type: Improvement Components: Creator Affects Versions: 1.0-alpha-4 Reporter: Mark Hobson Fix For: 2.0-alpha-4 Attachments: ARCHETYPE-57-patch archetype.xml currently provides no way of creating empty directories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-231) Create a single dependency resolution plugin
[ http://jira.codehaus.org/browse/MDEP-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=203296#action_203296 ] luke w patterson commented on MDEP-231: --- There have been times when a goal like this would have been useful to me. To be able to resolve an individual artifact from the command line without first creating a dummy pom. Create a single dependency resolution plugin Key: MDEP-231 URL: http://jira.codehaus.org/browse/MDEP-231 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: resolve Affects Versions: 2.1, 2.2 Reporter: Marvin Froeder Assignee: John Casey Fix For: 2.2 Attachments: maven-dependency-plugin.patch, maven-dependency-plugin.patch, maven-dependency-plugin.patch The attached patch has a new goal that allows a single dependency to be resolved, like this: mvn org.apache.maven.plugins:maven-dependency-plugin:2.2-SNAPSHOT:resolve-single -DgroupId=com.acme -DartifactId=dummy -Dversion=1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-145) Outputting dependency resolution/tree in a well known _machine readable_ output format
[
http://jira.codehaus.org/browse/MDEP-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=184141#action_184141
]
luke w patterson commented on MDEP-145:
---
Any plans to output XML POMish format?
dependencies
dependency
groupIdfooGroupId/groupId
artifactIdfooArtifactId/artifactId
version1/version
scopecompile/scope
/dependency
dependency
groupIdbarGroupId/groupId
artifactIdbarArtifactId/artifactId
version1/version
scopetest/scope
/dependency
/dependencies
Outputting dependency resolution/tree in a well known _machine readable_
output format
--
Key: MDEP-145
URL: http://jira.codehaus.org/browse/MDEP-145
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: resolve, tree
Affects Versions: 2.0
Reporter: Samuel Le Berrigaud
Assignee: Brian Fox
Fix For: 2.2
Attachments: MDEP-145.zip, treegraph.patch
Currently (at least on trunk) one can output the dependencies in a file.
However the file output doesn't follow any specific format, except from being
the exact same output than on the console.
I would be nice to have an easily parse-able, format so that tools could
leverage the dependency resolution/tree. I am thinking for example of
continuous integration tools that could report on added/removed/updated
dependencies on modules.
The format could be xml, json or something else. I've been playing with the
current output to make it so that:
* the first line describes the current module for which dependency resolution
is done, formatted as such: {{groupId:artifactId:packaging:version}}
* every following line is a dependency (indented by 2 or more spaces),
formatted as such: {{groupId:artifactId:packaging:version:scope}}
This already is easy to parse.
What do you think?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3704) NPE in DefaultLIfecycleExecutor when run from within Hudson builds
[
http://jira.codehaus.org/browse/MNG-3704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=170001#action_170001
]
luke w patterson commented on MNG-3704:
---
I still see the same issue too, whenever I run to site with Clover reports.
Is this related to
https://hudson.dev.java.net/issues/show_bug.cgi?id=2373
?
I'm using Maven 2.1.0-M1 / Hudson 1.291 / Clover 2.4.3
NPE in DefaultLIfecycleExecutor when run from within Hudson builds
--
Key: MNG-3704
URL: http://jira.codehaus.org/browse/MNG-3704
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.10
Reporter: John Casey
Assignee: John Casey
Priority: Blocker
Fix For: 2.1.0-M1
{noformat}
[INFO] [clean:clean]
[HUDSON] Archiving /home/j2ee-hudson/.hudson/jobs/CXF/workspace/trunk/pom.xml
to
/home/j2ee-hudson/.hudson/jobs/CXF/modules/org.apache.cxf$cxf/builds/2008-08-11_16-49-47/archive/org.apache.cxf/cxf/2.1.2-SNAPSHOT/pom.xml
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.restoreDynamicState(DefaultLifecycleExecutor.java:779)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:636)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:533)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:512)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:364)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:325)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:176)
at
org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:42)
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:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at hudson.maven.agent.Main.launch(Main.java:133)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:135)
at
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:536)
at
hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:482)
at hudson.remoting.UserRequest.perform(UserRequest.java:69)
at hudson.remoting.UserRequest.perform(UserRequest.java:23)
at hudson.remoting.Request$2.run(Request.java:206)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGELOG-67) Add parameter to allow errors during build
[
http://jira.codehaus.org/browse/MCHANGELOG-67?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=170009#action_170009
]
luke w patterson commented on MCHANGELOG-67:
What is the current workaround for the scenario of when a project is copied or
branched temporarily?
I am trying to build from a branch and the build blows up when it gets to
changelog.
I like the idea:
An optional boolean parameter such as ${maven.changelog.error.ignore} could be
quite convenient in such cases.
Add parameter to allow errors during build
--
Key: MCHANGELOG-67
URL: http://jira.codehaus.org/browse/MCHANGELOG-67
Project: Maven 2.x Changelog Plugin
Issue Type: New Feature
Reporter: Shelley Baker
Priority: Minor
Adding a parameter to prevent BUILD ERRORs when an error occurs in the
changelog plugin could be quite convenient in certain cases. For example,
when a project is copied or branched temporarily (or initially created), the
SCM URLs defined in the POM may not always be updated. When the SCM path is
not found, it causes the entire build to fail.
{noformat}
[INFO] Generate Change Log report.
[INFO] Generating changed sets xml to: C:\the-project\target\changelog.xml
[INFO] Executing: svn --non-interactive log -v -r {2007-06-25 15:25:29
+}:{2007-07-26 15:25:29 +}
https://scm.url/svn/the.group.id/trunk/the-project/
[INFO] Working directory: C:\the-project\src\main\java
[ERROR] Provider message:
[ERROR] The svn command failed.
[ERROR] Command output:
[ERROR] svn: REPORT request failed on
'/svn/!svn/bc/28239/the.group.id/trunk/the-project'
svn: '/svn/!svn/bc/28239/the.group.id/trunk/the-project' path not found
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error during page generation
Embedded error: Error rendering Maven report: An error is occurred during
changelog command :
Command failed.
{noformat}
An optional boolean parameter such as ${maven.changelog.error.ignore} could
be quite convenient in such cases.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-295) Make the distributionManagement.site.url configurable from the command line
[ http://jira.codehaus.org/browse/MSITE-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=169906#action_169906 ] luke w patterson commented on MSITE-295: this feature is needed, it would align with deploy's altDeploymentRepository parameter http://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#altDeploymentRepository Make the distributionManagement.site.url configurable from the command line --- Key: MSITE-295 URL: http://jira.codehaus.org/browse/MSITE-295 Project: Maven 2.x Site Plugin Issue Type: Improvement Components: site:deploy Affects Versions: 2.0-beta-6 Reporter: Gabriel Falkenberg It should be possible to override the attribute distributionManagement.site.url from the command line like this: mvn site:site site:deploy -DdistributionManagement.site.url=file:///some/local/or/external/path/ This would not really be necessary if site:stage worked like it should but is needed since it does not. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-459) missing artifact references with pde mode enabled
[ http://jira.codehaus.org/browse/MECLIPSE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=167502#action_167502 ] luke w patterson commented on MECLIPSE-459: --- I see the same problem. When pde is enabled, some bundle dependencies are missing. missing artifact references with pde mode enabled - Key: MECLIPSE-459 URL: http://jira.codehaus.org/browse/MECLIPSE-459 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath), PDE support Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.5.1 Environment: Maven version: 2.0.9 Java version: 1.5.0_11 OS name: linux version: 2.6.15-51-686 arch: i386 Family: unix Reporter: Benjamin Voigt Priority: Critical Attachments: pde_dep_missing.zip Some artifacts are not referenced after executing mvn eclipse:eclipse and having pde mode enabled. The strange thing is, that this does only happen for particluar versions of an artifact. Two artifacts that I found with this problem are jetty (org.mortbay.jetty) and slf4j-log4j12 (org.slf4j-log4j12). Jetty versions beyond 6.1.5 work with pde enabled, higher versions do not. Same for slf4j-log4j12 versions = 1.1.0. Attached is an example project demonstrating the problem. Turn pde mode on/off in the pom and execute mvn eclipse:eclipse. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3762) Relocation not working for plugins
[
http://jira.codehaus.org/browse/MNG-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=150102#action_150102
]
luke w patterson commented on MNG-3762:
---
I should have given a more thorough explanation. I moved the requirement for
org.mortbay.jetty:maven-jetty-plugin:7.0.0pre3 from plugins to dependencies
just to verify that the relocation metadata was correct.
The download was successful when Maven saw maven-jetty-plugin as a dependency
instead of a plugin.
Relocation not working for plugins
--
Key: MNG-3762
URL: http://jira.codehaus.org/browse/MNG-3762
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Environment: Maven version: 2.0.9
Java version: 1.5.0_13
OS name: mac os x version: 10.5.4 arch: i386 Family: unix
Reporter: Wendy Smoak
As discussed on the user list, the relocation pom for the Jetty plugin does
not seem to work correctly.
See: http://www.nabble.com/Does-relocation-work-for-plugins--td19618624.html
To reproduce, create a project from the webapp archetype, and introduce the
Jetty plugin:
{noformat}
build
...
plugins
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version7.0.0pre3/version
/plugin
/plugins
{noformat}
Attempting to build the project results in an error:
{noformat}
$ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] Building mywebapp Maven Webapp
[INFO]task-segment: [install]
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/mortbay/jetty/maven-jetty-plugin/7.0.0pre3/maven-jetty-plugin-7.0.0pre3.jar
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] A required plugin was not found: Plugin could not be found -
check that the goal name is correct: Unable to download the artifact
from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.mortbay.jetty
-DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
-Dpackaging=maven-plugin -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
-DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Mon Sep 22 19:02:01 MST 2008
[INFO] Final Memory: 3M/7M
[INFO]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3769) Excluding transitive dependencies does not work
[
http://jira.codehaus.org/browse/MNG-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
luke w patterson updated MNG-3769:
--
Attachment: MNG-3769-debugging-info.zip
With the pom.xml from attachment 1, I captured some info that might be useful
for anyone debugging this.
See MNG-3769-debugging-info.zip
step 0:
created empty local repo directory /2.0.9-repo
created empty local repo directory /2.1.0-M1-repo
step 1: using maven 2.0.9 pointing to /2.0.9-repo, ran
org.apache.maven.plugins:maven-dependency-plugin:2.0:tree, goal completed
console capture is in step1-2.0.9-tree.txt
content listing of /2.0.9-repo is in step1-2.0.9-repo-contents.txt
step 2: using maven 2.1.0-M1 pointing to /2.1.0-M1-repo, ran
org.apache.maven.plugins:maven-dependency-plugin:2.0:tree, goal completed
console capture is in step2-2.1.0-M1-tree.txt
content listing of /2.1.0-M1-repo is in step2-2.1.0-M1-repo-contents.txt
step 3: using maven 2.1.0-M1 pointing to /2.0.9-repo, ran
org.apache.maven.plugins:maven-dependency-plugin:2.0:tree, goal failed
console capture is in step3-2.1.0-M1-tree.txt
content listing of /2.0.9-repo is in step3-2.0.9-repo-contents.txt
Excluding transitive dependencies does not work
---
Key: MNG-3769
URL: http://jira.codehaus.org/browse/MNG-3769
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.1.0-M1
Reporter: Dirk Olmes
Priority: Blocker
Attachments: MNG-3769-debugging-info.zip, pom.xml
I'm trying to exclude transitive dependencies of a dependency. This works
fine with 2.0.9, however it does not work with 2.1.0-M1.
Run {{mvn dependency:tree}} on the attached pom.xml with 2.0.9 and note how
there is no javax.activation in the tree. Re-run with 2.1.0-M1 and note how
javax.activation shows up in the dependencies tree.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-3769) Excluding transitive dependencies does not work
[
http://jira.codehaus.org/browse/MNG-3769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
luke w patterson updated MNG-3769:
--
Attachment: MNG-3769-debugging-info-2.zip
Oops, last attachment didn't have debugging turned on during dependency:tree.
This attachment does.
Excluding transitive dependencies does not work
---
Key: MNG-3769
URL: http://jira.codehaus.org/browse/MNG-3769
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.1.0-M1
Reporter: Dirk Olmes
Priority: Blocker
Attachments: MNG-3769-debugging-info-2.zip,
MNG-3769-debugging-info.zip, pom.xml
I'm trying to exclude transitive dependencies of a dependency. This works
fine with 2.0.9, however it does not work with 2.1.0-M1.
Run {{mvn dependency:tree}} on the attached pom.xml with 2.0.9 and note how
there is no javax.activation in the tree. Re-run with 2.1.0-M1 and note how
javax.activation shows up in the dependencies tree.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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-3762) Relocation not working for plugins
[
http://jira.codehaus.org/browse/MNG-3762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=149857#action_149857
]
luke w patterson commented on MNG-3762:
---
Just to make sure the relocation metadata was correct, I modified your example
from
plugins
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version7.0.0pre3/version
/plugin
/plugins
to
dependencies
dependency
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version7.0.0pre3/version
/dependency
/dependencies
and it downloaded fine.
Relocation not working for plugins
--
Key: MNG-3762
URL: http://jira.codehaus.org/browse/MNG-3762
Project: Maven 2
Issue Type: Bug
Affects Versions: 2.0.9
Environment: Maven version: 2.0.9
Java version: 1.5.0_13
OS name: mac os x version: 10.5.4 arch: i386 Family: unix
Reporter: Wendy Smoak
As discussed on the user list, the relocation pom for the Jetty plugin does
not seem to work correctly.
See: http://www.nabble.com/Does-relocation-work-for-plugins--td19618624.html
To reproduce, create a project from the webapp archetype, and introduce the
Jetty plugin:
{noformat}
build
...
plugins
plugin
groupIdorg.mortbay.jetty/groupId
artifactIdmaven-jetty-plugin/artifactId
version7.0.0pre3/version
/plugin
/plugins
{noformat}
Attempting to build the project results in an error:
{noformat}
$ mvn install
[INFO] Scanning for projects...
[INFO]
[INFO] Building mywebapp Maven Webapp
[INFO]task-segment: [install]
[INFO]
Downloading:
http://repo1.maven.org/maven2/org/mortbay/jetty/maven-jetty-plugin/7.0.0pre3/maven-jetty-plugin-7.0.0pre3.jar
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] A required plugin was not found: Plugin could not be found -
check that the goal name is correct: Unable to download the artifact
from any repository
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.mortbay.jetty
-DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
-Dpackaging=maven-plugin -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=org.mortbay.jetty
-DartifactId=maven-jetty-plugin -Dversion=7.0.0pre3
-Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url]
-DrepositoryId=[id]
org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
org.mortbay.jetty:maven-jetty-plugin:maven-plugin:7.0.0pre3
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Mon Sep 22 19:02:01 MST 2008
[INFO] Final Memory: 3M/7M
[INFO]
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2873) Unable to find transitive dependencies when they have been relocated.
[ http://jira.codehaus.org/browse/MNG-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=146252#action_146252 ] luke w patterson commented on MNG-2873: --- Have you tried 2.0.10-RC11 [1]? Even though the scenario you described is a little different than MNG-3380, I think that fix will cover this too. [1] - http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC11/org/apache/maven/apache-maven/2.0.10-RC11/ Unable to find transitive dependencies when they have been relocated. - Key: MNG-2873 URL: http://jira.codehaus.org/browse/MNG-2873 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Micah Whitacre Fix For: 2.0.11 Attachments: MNG2873.ZIP I have two projects A and B. Project A is dependent on B. Project B has compile time on project C which is deployed to a repository, repository1. The newest version, 2.0, of project C has since been relocated from oldGroupId to newGroupId. The relocation POMs are working correctly and Project B is able to be built successfully. Project A is not dependent on anything from repository1 it does not list that repository in its own repositories/ section. When building project A, it tries to resolve the dependencies of B which includes C. However I am currently getting errors when it tries to resolve the C. Below is an example of this error occurring. As you can see the list of remote repositories does not display repository1 as one of the repositories that was checked despite the fact that Project B listed it in its POM. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. No versions are present in the repository for the artifact with a range [1,) oldGroupId:projectC:jar:null from the specified remote repositories: central (http://repo1.maven.org/maven2), repo2 (http://repo.some-repo.com/repo) If I change project B to not use a range but to instead depend on a non-relocated version of project C everything works fine and I do not get this issue at all. The other and more correct solution to this issue is to update project B to use the new groupIds however it forces me to release project B immediately since all older released versions of B are broken by using the old groupIds an this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143170#action_143170 ] luke w patterson commented on MNG-3380: --- I tested with 2.0.10-RC2 [1] the production scenario that originally highlighted this issue. Issue Resolved. Thanks for your dedicated effort in moving 2.0.10 along. [1] - http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC2 MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Assignee: John Casey Fix For: 2.0.10, 2.1-alpha-1 Attachments: MNG-3380-integration-test.zip, MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace changes, it is about 10 lines different. Thanks, Luke -- This message is automatically generated by
[jira] Updated: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] luke w patterson updated MNG-3380: -- Attachment: MNG-3380-integration-test.zip new integration test MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-integration-test.zip, MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace changes, it is about 10 lines different. Thanks, Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=131444#action_131444 ] luke w patterson commented on MNG-3380: --- I attached a new integration test for this condition. (MNG-3380-integration-test.zip) The test fails in all of these: 2.0.7 2.0.8 2.0.9 2.1-SNAPSHOT (rev 649863 of trunk) Without a fix, plugins cannot rely on org.apache.maven.project.MavenProject#getArtifacts(). Results could be inaccurate if you use dependencyManagement and have relocated transitive dependencies. Summary of integration test: --- project.getArtifacts() direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile other-groupId:other-artifactId-a:jar:1:compile other-groupId:other-artifactId-b:jar:1:compile -- should be here, but isn't other-groupId:other-artifactId-c:jar:1:compile -- is here, but shouldn't be --- MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-integration-test.zip, MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \-
[jira] Commented: (MNG-3052) Transitive Dependency not found when repo is not listed
[ http://jira.codehaus.org/browse/MNG-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130754#action_130754 ] luke w patterson commented on MNG-3052: --- In 2.0.8, it only worked for me after I modified distributionManagement to include uniqueVersionfalse/uniqueVersion. In 2.0.9, it seems to work ok without modifications. Transitive Dependency not found when repo is not listed --- Key: MNG-3052 URL: http://jira.codehaus.org/browse/MNG-3052 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0.5 Reporter: Micah Whitacre Priority: Critical Attachments: InheritLegacyRepo.zip, mng_3052.zip I have seen the situation where a build fails because a project has a transitive dependency that only exists in a repository not listed by my project. An example of this is I have Projects A, B, and C. Where A depends on B, and B on C. B has been released to remote repo 1, and C has been released to remote repo 2. Since A just directly depends on B it only lists remote repo 1 in its POM. However when I try to build project A the build fail because it can't resolve its transitive dependency C in any of the dependencies it is checking (repo 1 only). It is my understanding that for project A I shouldn't have to list the remote repos to resolve transitive dependencies. I should only have to list the repos to get to B and Maven then should use the POM of B to resolve C. Is that not correct? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130760#action_130760 ] luke w patterson commented on MNG-3380: --- The problem still exists with 2.0.9. Until the bug is fixed, the assembly plugin I'm using won't receive accurate information. Relocated transitive dependencies can be either missing or wrong during tree resolution. MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace changes, it is about 10 lines different. Thanks, Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:
[jira] Commented: (MNG-3031) Within a model duplicate dependency declarations should be considered an error and halt execution
[ http://jira.codehaus.org/browse/MNG-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_123309 ] luke w patterson commented on MNG-3031: --- I am working with OSGi bundles. In top-level product assembly projects, I need the ability to specify multiple bundle versions for concurrent use. How would this proposal affect my scenario? Within a model duplicate dependency declarations should be considered an error and halt execution - Key: MNG-3031 URL: http://jira.codehaus.org/browse/MNG-3031 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.x, 2.1 Reporter: Jason van Zyl Fix For: Reviewed Pending Version Assignment A warning is not good enough as you'll still get unpredictable behavior. Ideally this would not be allowed and caught during a session in an IDE but from the command line as part of the validation of the model duplicate dependencies should shut down execution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122782 ] luke w patterson commented on MNG-3380: --- Thanks for the info, Vincent. Please let me know if the new patch is better. Just keep in mind that the patch is not elegant at all. Basically, I check to see if ArtifactMetadataSource changes the artifact (due to relocation) when it retrieves ResolutionGroup. If it does change it, I repeat the portion of code that checks for managed versions. That was a quick hack because I couldn't find a place in the logic which was aware of all factors involved. Thanks, Luke MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace
[jira] Updated: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] luke w patterson updated MNG-3380: -- Attachment: MNG-3380-maven-artifact.patch MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: MNG-3380-maven-artifact.patch, patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace changes, it is about 10 lines different. Thanks, Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
[ http://jira.codehaus.org/browse/MNG-3380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122812 ] luke w patterson commented on MNG-3380: --- Wojciech, Is this the scenario you are describing? project modelVersion4.0.0/modelVersion groupIdparent-groupId/groupId artifactIdparent-artifactId/artifactId version1/version packagingpom/packaging dependencyManagement dependencies dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId version2.6.2/version /dependency /dependencies /dependencyManagement /project project parent groupIdparent-groupId/groupId artifactIdparent-artifactId/artifactId version1/version /parent modelVersion4.0.0/modelVersion artifactIdchild-artifactId/artifactId dependencies dependency groupIdxerces/groupId artifactIdxercesImpl/artifactId /dependency dependency groupIdgroovy/groupId artifactIdgroovy/artifactId version1.0/version /dependency /dependencies /project If so, 2.0.8 seemed to handle it correctly: [dependency:tree] parent-groupId:child-artifactId:jar:1 +- xerces:xercesImpl:jar:2.6.2:compile \- groovy:groovy:jar:1.0:compile +- antlr:antlr:jar:2.7.5:compile +- asm:asm:jar:2.2:compile +- (xerces:xercesImpl:jar:2.6.2:compile - version managed from 2.4.0; omitted for duplicate) +- xml-apis:xml-apis:jar:1.0.b2:compile +- commons-cli:commons-cli:jar:1.0:compile | +- (commons-logging:commons-logging:jar:1.0:compile - omitted for conflict with 1.0.4) | \- commons-lang:commons-lang:jar:1.0:compile | \- (junit:junit:jar:3.7:compile - omitted for conflict with 3.8.2) +- ant:ant:jar:1.6.5:compile +- ant:ant-junit:jar:1.6.5:compile +- ant:ant-launcher:jar:1.6.5:compile +- junit:junit:jar:3.8.2:compile +- jmock:jmock:jar:1.1.0:compile | \- (junit:junit:jar:3.8.1:compile - omitted for conflict with 3.8.2) +- jmock:jmock-cglib:jar:1.1.0:compile | +- (jmock:jmock:jar:1.1.0:compile - omitted for duplicate) | \- cglib:cglib-full:jar:2.0:compile +- cglib:cglib-nodep:jar:2.1_3:compile +- asm:asm-util:jar:2.2:compile +- asm:asm-attrs:jar:2.2:compile +- asm:asm-analysis:jar:2.2:compile +- asm:asm-tree:jar:2.2:compile +- bsf:bsf:jar:2.4.0:compile | \- (commons-logging:commons-logging:jar:1.0.4:compile - omitted for conflict with 1.0) +- mx4j:mx4j:jar:3.0.1:compile +- mockobjects:mockobjects-core:jar:0.09:compile +- openejb:openejb-loader:jar:1.0:compile | +- openejb:openejb-core:jar:1.0:compile | | +- (org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0:compile - omitted for duplicate) | | +- (org.apache.geronimo.specs:geronimo-ejb_2.1_spec:jar:1.0:compile - omitted for duplicate) | | +- (org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:1.0:compile - omitted for duplicate) | | +- (org.apache.geronimo.specs:geronimo-servlet_2.4_spec:jar:1.0:compile - omitted for duplicate) | | +- (log4j:log4j:jar:1.2.8:compile - omitted for duplicate) | | +- backport-util-concurrent:backport-util-concurrent:jar:2.0_01_pd:compile | | +- (xerces:xercesImpl:jar:2.6.2:compile - version managed from 2.6.0; omitted for duplicate) | | +- (xml-apis:xml-apis:jar:1.0.b2:compile - omitted for duplicate) | | +- castor:castor:jar:0.9.9.0-pre:compile | | +- oro:oro:jar:2.0.8:compile | | +- (commons-logging:commons-logging:jar:1.0.3:compile - omitted for conflict with 1.0) | | \- idb:idb:jar:3.26:compile | +- org.apache.geronimo.specs:geronimo-jta_1.0.1B_spec:jar:1.0:compile | +- org.apache.geronimo.specs:geronimo-ejb_2.1_spec:jar:1.0:compile | +- org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:1.0:compile | +- org.apache.geronimo.specs:geronimo-servlet_2.4_spec:jar:1.0:compile | \- log4j:log4j:jar:1.2.8:compile +- axion:axion:jar:1.0-M3-dev:compile | +- (commons-collections:commons-collections:jar:3.0:compile - omitted for conflict with 3.2) | +- (commons-primitives:commons-primitives:jar:1.0:compile - omitted for duplicate) | +- (commons-logging:commons-logging:jar:1.0:compile - omitted for duplicate) | +- commons-codec:commons-codec:jar:1.2:compile | +- (junit:junit:jar:3.8.1:compile - omitted for conflict with 3.8.2) | \- net.java.dev.javacc:javacc:jar:3.2:compile +- commons-logging:commons-logging:jar:1.0.4:compile +- commons-collections:commons-collections:jar:3.2:compile +- commons-primitives:commons-primitives:jar:1.0:compile +- regexp:regexp:jar:1.3:compile +- javax.servlet:servlet-api:jar:2.4:compile +- javax.servlet:jsp-api:jar:2.0:compile | \- (javax.servlet:servlet-api:jar:2.4:compile - omitted for duplicate) +-
[jira] Created: (MNG-3380) MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation
MavenMetadataSource retrieves ResolutionGroup without consulting ManagedVersionMap, is problem when relocation -- Key: MNG-3380 URL: http://jira.codehaus.org/browse/MNG-3380 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.8 Reporter: luke w patterson Attachments: patch.txt, repo.zip Consider the following scenario: project modelVersion4.0.0/modelVersion groupIdroot-groupId/groupId artifactIdroot-artifactId/artifactId version1/version dependencies dependency groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version /dependency /dependencies dependencyManagement dependencies dependency groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version /dependency /dependencies /dependencyManagement /project project modelVersion4.0.0/modelVersion groupIddirect-dependency-groupId/groupId artifactIddirect-dependency-artifactId/artifactId version1/version dependencies dependency groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-old-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version distributionManagement relocation groupIdtransitive-dependency-new-groupId/groupId /relocation /distributionManagement /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version1/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency /dependencies /project project modelVersion4.0.0/modelVersion groupIdtransitive-dependency-new-groupId/groupId artifactIdtransitive-dependency-artifactId/artifactId version2/version dependencies dependency groupIdother-groupId/groupId artifactIdother-artifactId-a/artifactId version1/version /dependency dependency groupIdother-groupId/groupId artifactIdother-artifactId-b/artifactId version1/version /dependency /dependencies /project -- actual dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile -- expected dependency:tree root-groupId:root-artifactId:jar:1 \- direct-dependency-groupId:direct-dependency-artifactId:jar:1:compile \- transitive-dependency-new-groupId:transitive-dependency-artifactId:jar:2:compile (version managed from 1) \- other-groupId:other-artifactId-a:jar:1:compile \- other-groupId:other-artifactId-b:jar:1:compile -- missing from actual result -- As you can see from the listing above, other-groupId:other-artifactId-b:jar:1:compile is missing from the dependency list. I have attached the zipped repo which was used when generating the dependency:tree listings shown above. I also attached a crude temporary patch which my team is currently using to resolve this issue. After ignoring whitespace changes, it is about 10 lines different. Thanks, Luke -- This message is automatically generated by JIRA. - If you think it was sent incorrectly 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-131) Attach source and javadoc to dependencies in pde projects
[ http://jira.codehaus.org/browse/MECLIPSE-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_119102 ] luke w patterson commented on MECLIPSE-131: --- Hi, When I set the pde parameter to 'true' in my pom, I only get source attachments (.classpath entries) for non-bundle artifacts. Does the fix attach source code for bundle artifacts as well? Is there a way to manually attach source code besides creating a bundle which contains an extension point of type org.eclipse.pde.core.source? I use version 2.5-SNAPSHOT. Thanks, Luke Attach source and javadoc to dependencies in pde projects - Key: MECLIPSE-131 URL: http://jira.codehaus.org/browse/MECLIPSE-131 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: PDE support Affects Versions: 2.3 Environment: windows xp, eclipse3.2.0, jdk 1.5, maven 2.0.4 Reporter: stephane bouchet Assignee: fabrizio giustina Fix For: 2.3 when using plugin for pde projects, source and javadoc are not attached for dependencies even if they are available in repo. this feature exists already for java project, it could be nice to have the same for pde projects. Thanks, Stéphane . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
