[jira] Commented: (MASSEMBLY-150) Clarify or fix relative scoping in assembly descriptor to be module centric or location of mvn execution
[ http://jira.codehaus.org/browse/MASSEMBLY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192368#action_192368 ] Andreas Johansson commented on MASSEMBLY-150: - I guess fixing this issue will also allow use of relative paths to filter resources when invoking maven from outside the module. i.e. [pom.xml] ... src/main/resources/filterA.properties ... [dist.xml] ... ... true ... Breaks when running from parent/top module (mvn -am -pl dist ...) - Error loading property file 'src/main/resources/filterA.properties' > Clarify or fix relative scoping in assembly descriptor to be module > centric or location of mvn execution > --- > > Key: MASSEMBLY-150 > URL: http://jira.codehaus.org/browse/MASSEMBLY-150 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: windows xp >Reporter: Harold Shinsato > Fix For: 2.2-beta-5 > > > According to > http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html, the > assembly descriptor's source is supposed to be absolute or relative > from the module's directory. This works when I execute mvn in the module > directory. But when I run it from a top level super project, it seems to run > from that higher level project. This isn't how the works, which we > were using before, but we needed to set filtering to true, which caused this > to break. > So this is how we have to write this to make this work from the top level, > but it breaks when running the assembly from this directory. > > > fileutil/src/main/scripts/FileUploadUtility.bat > file-utility > true > > > This is how it used to be specified, where it worked both from the top level > and from the subdirectory: > > > ../fileutil > file-utility > > FileUploadUtility.bat > > > > Hopefully this won't make a difference, but we've plugged our assembly into > the execution of the package phase. This is copied from the pom.xml of the > module. > > > > maven-assembly-plugin > > > src/main/assembly/dist.xml > > > > > > attached > > package > > > > > -- 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-492) Maven Eclipse Plugin does not take dependencyManagement excludes into account when building eclipse CP configuration.
[
http://jira.codehaus.org/browse/MECLIPSE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192373#action_192373
]
Stephane Landelle commented on MECLIPSE-492:
Duplicate of MECLIPSE-603. Can be closed.
> Maven Eclipse Plugin does not take dependencyManagement excludes into account
> when building eclipse CP configuration.
> -
>
> Key: MECLIPSE-492
> URL: http://jira.codehaus.org/browse/MECLIPSE-492
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5.1
>Reporter: Maarten Billemont
>
> I have a parent pom that excludes xml-apis:xml-apis from dom4j:dom4j in the
> dependencyManagement section. To make certain that as the project
> development progresses no artifacts depend on xml-apis:xml-apis (it is
> superseded by org.apache.xerces:xml-apis) I've forced the version of
> xml-apis:xml-apis in the same dependencyManagement section to be -1. No
> artifact should depend on it since I'm excluding all dependencies on it
> manually and adding org.apache.xerces:xml-apis as a manual dependency. In
> Maven this works fine. When I run maven-eclipse-plugin in a child module of
> this pom artifact which depends on dom4j:dom4j however, it tries to download
> xml-apis:xml-apis:jar:-1 and after failing it adds it to the project's
> classpath configuration (which obviously causes eclipse to throw errors not
> being able to find xml-apis:xml-apis:jar:-1 in my local repository.
>
>
>
> dom4j
> dom4j
> ${dom4j.version}
>
>
> xml-apis
> xml-apis
>
>
>
>
> xml-apis
> xml-apis
> -1
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-265) Generate a combined javadoc using all dependency source jars.
[ http://jira.codehaus.org/browse/MJAVADOC-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192375#action_192375 ] Vincent Siveton commented on MJAVADOC-265: -- Using ? Could you detail? > Generate a combined javadoc using all dependency source jars. > - > > Key: MJAVADOC-265 > URL: http://jira.codehaus.org/browse/MJAVADOC-265 > Project: Maven 2.x Javadoc Plugin > Issue Type: New Feature >Reporter: Paul Gier > > I would like to be able to create a javadoc API that combines not only the > sources from my project modules, but also downloads available dependency > source files and includes these when generating the javadocs. -- 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: (MPH-70) Maven Help Plugin prints an Exception Stack Trace: NoSuchMethodError on execution
Maven Help Plugin prints an Exception Stack Trace: NoSuchMethodError on
execution
-
Key: MPH-70
URL: http://jira.codehaus.org/browse/MPH-70
Project: Maven 2.x Help Plugin
Issue Type: Bug
Reporter: Tim O'Brien
I just tried to run the Help plugin
Here is my Maven version info:
Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
Java version: 1.6.0_15
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.1" arch: "x86_64" Family: "mac"
Here is the error output:
~/book$ mvn help:describe -Dplugin=scm -e
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Maven: The Definitive Guide Example Code
[INFO] Maven: The Definitive Guide (Parent Project)
[INFO] Maven: The Definitive Guide (XML, HTML, PDF, and Site)
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Maven: The Definitive Guide (Parent Project)
[INFO]task-segment: [help:describe] (aggregator-style)
[INFO]
[INFO] [help:describe {execution: default-cli}]
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] NoSuchMethodException:
org.apache.maven.plugins.help.HelpMojo.toLines(java.lang.String, int, int, int)
[INFO]
[INFO] Trace
org.apache.maven.BuildFailureException: NoSuchMethodException:
org.apache.maven.plugins.help.HelpMojo.toLines(java.lang.String, int, int, int)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
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:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoFailureException: NoSuchMethodException:
org.apache.maven.plugins.help.HelpMojo.toLines(java.lang.String, int, int, int)
at
org.apache.maven.plugins.help.DescribeMojo.toLines(DescribeMojo.java:930)
at
org.apache.maven.plugins.help.DescribeMojo.append(DescribeMojo.java:969)
at
org.apache.maven.plugins.help.DescribeMojo.describePlugin(DescribeMojo.java:515)
at
org.apache.maven.plugins.help.DescribeMojo.execute(DescribeMojo.java:268)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2615) rsync_ssh request for svenson and jcouchdb
rsync_ssh request for svenson and jcouchdb -- Key: MAVENUPLOAD-2615 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2615 Project: Maven Upload Requests Issue Type: Wish Reporter: Sven Helmberger "com.google.code.svenson","mvnrs...@fforw.de:/home/mvnrsync/m2repo/releases","rsync_ssh","Sven Helmberger","i...@fforw.de" "com.google.code.jcouchdb","mvnrs...@fforw.de:/home/mvnrsync/m2repo/releases","rsync_ssh","Sven Helmberger","i...@fforw.de" -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-252) javadoc link : nonproxyhosts not used
[ http://jira.codehaus.org/browse/MJAVADOC-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-252. Resolution: Fixed Maxime confirmed me the resolution in private > javadoc link : nonproxyhosts not used > - > > Key: MJAVADOC-252 > URL: http://jira.codehaus.org/browse/MJAVADOC-252 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: maven-2.0.10 > jdk 1.6_014 >Reporter: Maxime Gréau >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.6.1 > > Attachments: link_nonproxy_2.0.10.patch, link_nonproxy_2.2.0.patch > > > - Prerequisite : > > - web access via http proxy > - javadoc-plugin configuration with true > - $MVN_HOME/conf/settings.xml with configuration above ( internal-host is > host to access the internal javadoc web sites ) > > > true > http > myproxyhost > myproxyport > internal-host > > > Launch the mvn site-deploy command. > If you have a dependency with an internal javadoc web site, the plugin tried > to link this javadoc with the http proxy and logged: > "Error fetching link: http://internal-host//apidocs/package-list. Ignored > it." > This is a bug because this javadoc isn't accessible via http proxy. > So I attached 2 patches : > - the first one (link_nonproxy_2.0.10.patch) is compatible (and tested) with > mvn 2.0.9 and 2.0.10 but included a method directly copied from > ProxyUtils.java (wagon-provider-api-1.0-beta-6.jar) > - the second (link_nonproxy_2.2.0.patch) used 2 classes from > wagon-provider-api-1.0-beta-6.jar dependency so it requires mvn 2.2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MASSEMBLY-150) Clarify or fix relative scoping in assembly descriptor to be module centric or location of mvn execution
[
http://jira.codehaus.org/browse/MASSEMBLY-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192368#action_192368
]
Andreas Johansson edited comment on MASSEMBLY-150 at 9/26/09 6:34 AM:
--
I guess fixing this issue will also allow use of relative paths to filter
resources when invoking maven from outside the module.
i.e.
[pom.xml]
...
src/main/resources/filterA.properties
...
[dist.xml]
...
...
true
...
Breaks when running from parent/top module (mvn -am -pl dist ...) - Error
loading property file 'src/main/resources/filterA.properties'
[EDIT]
As John states above you can fix the issue by prefixing the paths with
${project.basedir} until it is being done automatically by the plugin.
was (Author: icucode):
I guess fixing this issue will also allow use of relative paths to filter
resources when invoking maven from outside the module.
i.e.
[pom.xml]
...
src/main/resources/filterA.properties
...
[dist.xml]
...
...
true
...
Breaks when running from parent/top module (mvn -am -pl dist ...) - Error
loading property file 'src/main/resources/filterA.properties'
> Clarify or fix relative scoping in assembly descriptor to be module
> centric or location of mvn execution
> ---
>
> Key: MASSEMBLY-150
> URL: http://jira.codehaus.org/browse/MASSEMBLY-150
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: windows xp
>Reporter: Harold Shinsato
> Fix For: 2.2-beta-5
>
>
> According to
> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html, the
> assembly descriptor's source is supposed to be absolute or relative
> from the module's directory. This works when I execute mvn in the module
> directory. But when I run it from a top level super project, it seems to run
> from that higher level project. This isn't how the works, which we
> were using before, but we needed to set filtering to true, which caused this
> to break.
> So this is how we have to write this to make this work from the top level,
> but it breaks when running the assembly from this directory.
>
>
> fileutil/src/main/scripts/FileUploadUtility.bat
> file-utility
> true
>
>
> This is how it used to be specified, where it worked both from the top level
> and from the subdirectory:
>
>
> ../fileutil
> file-utility
>
> FileUploadUtility.bat
>
>
>
> Hopefully this won't make a difference, but we've plugged our assembly into
> the execution of the package phase. This is copied from the pom.xml of the
> module.
>
>
>
> maven-assembly-plugin
>
>
> src/main/assembly/dist.xml
>
>
>
>
>
> attached
>
> package
>
>
>
>
>
--
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-368) Dependency configuration in DependencyManagement with exclusions is ignored
[ http://jira.codehaus.org/browse/MECLIPSE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192374#action_192374 ] Stephane Landelle commented on MECLIPSE-368: Duplicate of MECLIPSE-603. Can be closed. > Dependency configuration in DependencyManagement with exclusions is ignored > --- > > Key: MECLIPSE-368 > URL: http://jira.codehaus.org/browse/MECLIPSE-368 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.4 > Environment: Ubuntu Linux 7.10 >Reporter: jh > Attachments: exclusion-example-20080116.zip, MECLIPSE-368.patch > > > A transitive dependency which is defined in the DependencyManagement section > with exclusions does not take these exclusions into account when generating > an eclipse classpath. > Example: > - childProject has a dependency 'acegi-security-tiger' > - parentProject has a dependencyManagement section that defines the version > and the exclusions > - acegi-security-tiger has a transitive dependency to acegi-security > - parentProject has defined acegi-security and a number of exclusions one of > which is spring-remoting 1.2.7 > - childProject's classpath ends up with spring-remoting 1.2.7 as dependency > - we are using spring 2.5.1 which does not have spring-remoting > If I check dependencies with dependency:tree -Dscope=null the dependency > resolving of acegi-security-tiger stops with acegi-security and no other > transitive dependencies are added (all are excluded) > Workaround is to add acegi-security in childProject's pom. > Main concern here is that dependency resolution in the eclipse plugin seems > to be different from the dependency plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-603) Exclusions are not applied on transitive dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=192429#action_192429 ] Arnaud Heritier commented on MECLIPSE-603: -- I forgot to say I deployed a SNAPSHOT with the following timestamp 2.8-20090926.232444-2 > Exclusions are not applied on transitive dependencies > - > > Key: MECLIPSE-603 > URL: http://jira.codehaus.org/browse/MECLIPSE-603 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.7 > Environment: Mac OS X >Reporter: Stephane Landelle >Assignee: Arnaud Heritier > Fix For: 2.8 > > Attachments: MECLIPSE-603-maven-eclipse-plugin.patch > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > Exclusions are only applied on direct dependencies, not on transitive ones, > to the classpath is inconsistent. > MECLIPSE-472 is probably related to this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-368) Dependency configuration in DependencyManagement with exclusions is ignored
[ http://jira.codehaus.org/browse/MECLIPSE-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-368. Assignee: Arnaud Heritier Resolution: Duplicate Fix Version/s: 2.8 > Dependency configuration in DependencyManagement with exclusions is ignored > --- > > Key: MECLIPSE-368 > URL: http://jira.codehaus.org/browse/MECLIPSE-368 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: Core : Dependencies resolution and build path > (.classpath) >Affects Versions: 2.4 > Environment: Ubuntu Linux 7.10 >Reporter: jh >Assignee: Arnaud Heritier > Fix For: 2.8 > > Attachments: exclusion-example-20080116.zip, MECLIPSE-368.patch > > > A transitive dependency which is defined in the DependencyManagement section > with exclusions does not take these exclusions into account when generating > an eclipse classpath. > Example: > - childProject has a dependency 'acegi-security-tiger' > - parentProject has a dependencyManagement section that defines the version > and the exclusions > - acegi-security-tiger has a transitive dependency to acegi-security > - parentProject has defined acegi-security and a number of exclusions one of > which is spring-remoting 1.2.7 > - childProject's classpath ends up with spring-remoting 1.2.7 as dependency > - we are using spring 2.5.1 which does not have spring-remoting > If I check dependencies with dependency:tree -Dscope=null the dependency > resolving of acegi-security-tiger stops with acegi-security and no other > transitive dependencies are added (all are excluded) > Workaround is to add acegi-security in childProject's pom. > Main concern here is that dependency resolution in the eclipse plugin seems > to be different from the dependency plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-492) Maven Eclipse Plugin does not take dependencyManagement excludes into account when building eclipse CP configuration.
[
http://jira.codehaus.org/browse/MECLIPSE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier closed MECLIPSE-492.
Assignee: Arnaud Heritier
Resolution: Duplicate
Fix Version/s: 2.8
> Maven Eclipse Plugin does not take dependencyManagement excludes into account
> when building eclipse CP configuration.
> -
>
> Key: MECLIPSE-492
> URL: http://jira.codehaus.org/browse/MECLIPSE-492
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5.1
>Reporter: Maarten Billemont
>Assignee: Arnaud Heritier
> Fix For: 2.8
>
>
> I have a parent pom that excludes xml-apis:xml-apis from dom4j:dom4j in the
> dependencyManagement section. To make certain that as the project
> development progresses no artifacts depend on xml-apis:xml-apis (it is
> superseded by org.apache.xerces:xml-apis) I've forced the version of
> xml-apis:xml-apis in the same dependencyManagement section to be -1. No
> artifact should depend on it since I'm excluding all dependencies on it
> manually and adding org.apache.xerces:xml-apis as a manual dependency. In
> Maven this works fine. When I run maven-eclipse-plugin in a child module of
> this pom artifact which depends on dom4j:dom4j however, it tries to download
> xml-apis:xml-apis:jar:-1 and after failing it adds it to the project's
> classpath configuration (which obviously causes eclipse to throw errors not
> being able to find xml-apis:xml-apis:jar:-1 in my local repository.
>
>
>
> dom4j
> dom4j
> ${dom4j.version}
>
>
> xml-apis
> xml-apis
>
>
>
>
> xml-apis
> xml-apis
> -1
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
