[jira] Commented: (MDEP-121) UnsupportedOperationException on depdendency:analyze
[
http://jira.codehaus.org/browse/MDEP-121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=178966#action_178966
]
Havard Bjastad commented on MDEP-121:
-
A year and a half has gone by...what is the status of this?
> UnsupportedOperationException on depdendency:analyze
>
>
> Key: MDEP-121
> URL: http://jira.codehaus.org/browse/MDEP-121
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: analyze
>Affects Versions: 2.0
> Environment: maven-2.0.7
> JDK 1.5.0_06
> Windows XP
>Reporter: William Ferguson
>Assignee: Brian Fox
>
> Executing:
> {code}
> mvn
> org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:analyze
> {code}
> on 3-DEC-2007 (ie 2.0-alpha-5-20070703.005757) produced:
> {code}
> [INFO] snapshot org.codehaus.plexus:plexus-archiver:1.0-alpha-9-SNAPSHOT:
> checking for updates from snapshot
> [INFO] snapshot
> org.apache.maven.shared:maven-dependency-analyzer:1.0-alpha-3-SNAPSHOT:
> checking for updates from snapshot
> [INFO] [dependency:analyze]
> [INFO] Used undeclared dependencies:
> [WARNING]commons-logging:commons-logging:jar:1.0:compile
> [INFO] Unused declared dependencies:
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.UnsupportedOperationException
> at
> java.util.Collections$UnmodifiableCollection$1.remove(Collections.java:1012)
> at
> org.apache.maven.plugin.dependency.AnalyzeMojo.checkDependencies(AnalyzeMojo.java:213)
> at
> org.apache.maven.plugin.dependency.AnalyzeMojo.execute(AnalyzeMojo.java:162)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> [INFO]
>
> [INFO] Total time: 58 seconds
> [INFO] Finished at: Mon Dec 03 12:33:25 EST 2007
> [INFO] Final Memory: 14M/28M
> [INFO]
>
> {code}
> NB I was using the snapshot because I had just run dependency:tree
> Executing
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:analyze
> {code}
> does not cause the UnsupportedOperationException to occur.
> But the error doesn't occur in the trunk, so maybe time to release a new
> snapshot or even a new release?
--
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: (MPDF-13) Copy resources from skin artifact
[
http://jira.codehaus.org/browse/MPDF-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed MPDF-13.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.0
fixed in [r780233|http://svn.apache.org/viewvc?rev=780233&view=rev]
> Copy resources from skin artifact
> -
>
> Key: MPDF-13
> URL: http://jira.codehaus.org/browse/MPDF-13
> Project: Maven 2.x PDF Plugin
> Issue Type: Bug
>Affects Versions: 1.0
>Reporter: Vincent Siveton
>Assignee: Vincent Siveton
> Fix For: 1.0
>
>
> Running the pdf plugin on the Doxia site, we got fo error:
> {noformat}
> ERROR [org.apache.fop.fo.FONode:83] XXX - Image not found:
> ./images/icon_success_sml.gif
> {noformat}
> We need to copy the file from a given skin defined in the site.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] Created: (MDEP-213) resolve dependencyManagement section with option to fail the build
resolve dependencyManagement section with option to fail the build
--
Key: MDEP-213
URL: http://jira.codehaus.org/browse/MDEP-213
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: resolve
Affects Versions: 2.0
Reporter: Jim Sellers
Assignee: Brian Fox
When using the dependencyManagement section of a pom of type "pom" to create a
bill of materials, it's currently possible to specify an invalid version. eg:
{code:xml}
commons-logging
commons-logging
9.9
{code}
It would be really useful for these types of pom's to be able to force all the
dependencies to be resolved when running something like "install" and have that
fail the build.
--
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-450) release:perform shoult not call test:test as release:prepare already did
release:perform shoult not call test:test as release:prepare already did Key: MRELEASE-450 URL: http://jira.codehaus.org/browse/MRELEASE-450 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: perform Environment: linux Reporter: Christian Hammers Priority: Minor Hello When doing a "mvn release:prepare" and then "mvn release:perform" the complete test suite is run twice. As it takes a couple of minutes it feels annoying. Also I don't really see the necessarity of running the test:test goal in release:perform as release:prepare already does so and afterwards tag the source code so that the perform cannot be made on a non-tested code, or? bye, -christian- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-450) release:perform shoult not call test:test as release:prepare already did
[
http://jira.codehaus.org/browse/MRELEASE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179007#action_179007
]
Olivier Lamy commented on MRELEASE-450:
---
configure your pom with
{code:xml}
-DskipTests
{code}
> release:perform shoult not call test:test as release:prepare already did
>
>
> Key: MRELEASE-450
> URL: http://jira.codehaus.org/browse/MRELEASE-450
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: perform
> Environment: linux
>Reporter: Christian Hammers
>Priority: Minor
>
> Hello
> When doing a "mvn release:prepare" and then "mvn release:perform" the
> complete test suite is run twice. As it takes a couple of minutes it feels
> annoying. Also I don't really see the necessarity of running the test:test
> goal in release:perform as release:prepare already does so and afterwards tag
> the source code so that the perform cannot be made on a non-tested code, or?
> bye,
> -christian-
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-450) release:perform shoult not call test:test as release:prepare already did
[ http://jira.codehaus.org/browse/MRELEASE-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179036#action_179036 ] Christian Hammers commented on MRELEASE-450: When using -DskipTests the release:prepare does not call test:test either :( To clarify, I definetly want "release:prepare" to call "test:test" but I don't want "release:perform" to run them *again*. > release:perform shoult not call test:test as release:prepare already did > > > Key: MRELEASE-450 > URL: http://jira.codehaus.org/browse/MRELEASE-450 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform > Environment: linux >Reporter: Christian Hammers >Priority: Minor > > Hello > When doing a "mvn release:prepare" and then "mvn release:perform" the > complete test suite is run twice. As it takes a couple of minutes it feels > annoying. Also I don't really see the necessarity of running the test:test > goal in release:perform as release:prepare already does so and afterwards tag > the source code so that the perform cannot be made on a non-tested code, or? > bye, > -christian- -- 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: (MJAVADOC-233) mvn javadoc:javadoc fails if project pom name contains multiple lines
mvn javadoc:javadoc fails if project pom name contains multiple lines - Key: MJAVADOC-233 URL: http://jira.codehaus.org/browse/MJAVADOC-233 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.5 Environment: ubuntu 8.10, jdk 6. Reporter: Pablo Graña If the project name in the pom contains a new line (at least a CR LF pair), mvn javadoc:javadoc fails with this error: [INFO] An error has occurred in JavaDocs report generation:Exit code: 1 - javadoc: error - Illegal package name: "2.1.1-SNAPSHOT" javadoc: error - Illegal package name: "" javadoc: error - Illegal package name: "2.1.1-SNAPSHOT" javadoc: error - Illegal package name: "" javadoc: warning - No source files for package b javadoc: warning - No source files for package API javadoc: warning - No source files for package b javadoc: warning - No source files for package API Command line was:/usr/lib/jvm/java-6-sun-1.6.0.10/jre/../bin/javadoc @options @packages This is the relevant pom fragment: 4.0.0 a.b aa ejb a b This is the relevant fragment of the target/site/apidocs/options file: -doctitle 'a b 2.1.1-SNAPSHOT API' -use -version -windowtitle 'a b 2.1.1-SNAPSHOT API'gpablo If I remove de line from the project name, it works fine. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-551) On Linux (Ubuntu) it fails to escape all special characters when forking commands.
[
http://jira.codehaus.org/browse/SUREFIRE-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179089#action_179089
]
Joakim Erdfelt commented on SUREFIRE-551:
-
How to reproduce (short way)
# Create a maven 2 project in a path with "(" character. eg:
/home/user/code/project-foo(trunk)/pom.xml
# Create intentional test failure in the codebase
# Build: mvn clean install
# Notice, no test failures are reported (and no tests are run!)
How to reproduce (the long way)
# Load a maven 2 project into a Hudson instance.
# Set your project name in Hudson to "Project (foo)"
# Add an intentional test failure to the codebase, one that will generate a
test failures.
# Build the project in hudson
# No test failures are reported, as the /bin/sh: Syntax Error: "(" unexpected
occurs
> On Linux (Ubuntu) it fails to escape all special characters when forking
> commands.
> --
>
> Key: SUREFIRE-551
> URL: http://jira.codehaus.org/browse/SUREFIRE-551
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.4.2
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_13
> OS name: "linux" version: "2.6.28-11-server" arch: "amd64" Family: "unix"
>Reporter: Sean Montgomery
>Priority: Blocker
>
> Our project folder name has ()'s in it and this seems to be causing a problem
> for surefire as it is not escaping them when forking off.
> [INFO] Surefire report directory: /opt/paml/hudson/jobs/Site - XXX
> (1234)/workspace/trunk/target/surefire-reports
> Forking command line: /bin/sh -c "cd /opt/paml/hudson/jobs/Site\ -\ XXX\
> (1234)/workspace/trunk && /usr/lib/jvm/java-6-sun-1.6.0.13/jre/bin/java -jar
> /tmp/surefirebooter7806691896360428397.jar
> /tmp/surefire3396974786525533977tmp /tmp/surefire4621871739825375135tmp"
> /bin/sh: Syntax error: "(" unexpected
> [ERROR] There are test failures.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4166) Problem parsing command-line options in release:perform
[
http://jira.codehaus.org/browse/MNG-4166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MNG-4166.
---
Resolution: Fixed
commons-cli version 1.2 is more strict about extraneous cli options. the maven
artifact filter manager was forcing plugins to use the core version of
commons-cli, so this was messing up the release plugin. We're still using
version 1.2 in the core, but I've removed the commons-cli line from the
artifact filter manager to allow plugins to use their own versions of the
library.
> Problem parsing command-line options in release:perform
> ---
>
> Key: MNG-4166
> URL: http://jira.codehaus.org/browse/MNG-4166
> Project: Maven 2
> Issue Type: Bug
> Components: Command Line
>Affects Versions: 2.2.0
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.2.0
>
>
> From Paul Merlin on us...@maven.apache.org
> (http://www.nabble.com/Re%3A--PLEASE-TEST--Maven-2.2.0-RC2-p23391250.html)
> {noformat}
> [INFO] [release:perform]
>
> [INFO] Change the default 'svn' provider implementation to 'javasvn'.
>
> [INFO] Checking out the project to perform the release ...
>
> [INFO] SVN checkout directory: /home/paul/tmp/ekPom/target/checkout
>
> [INFO] Executing goals 'deploy'...
>
> [INFO]
>
>
> [ERROR] BUILD ERROR
>
> [INFO]
>
>
> [INFO] Failed to re-parse additional arguments for Maven invocation.
>
> Unrecognized option: -f
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to re-parse
> additional arguments for Maven invocation.
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:703)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
>
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
>
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
>
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
>
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
>
> 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.MojoExecutionExcept
[jira] Reopened: (MNG-4167) version-expression transformation interferes with plugins like GPG
[ http://jira.codehaus.org/browse/MNG-4167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey reopened MNG-4167: - transforming the POM coordinates from the get-go causes problems with the release plugin, since the .pom-transformed.xml file doesn't exist in the SCM, and the release plugin needs to rewrite AND THEN COMMIT the POM...if it only has access to the coordinate-transformed version of the POM, then it will commit overwriting the coordinate expressions. At the same time, the GPG plugin uses project.getFile() as the source for signing the POM file, instead of using the ProjectArtifactMetadata from project.getArtifact().getMetadata()...so the release plugin and the GPG plugin are directly in conflict here. Add to this the clean plugin, which deleted the target directory and won't allow the .pom-transformed.xml file to live there if it's created ahead of the clean plugin execution. Finally, the shade plugin uses project.getOriginalModel() when generating the dependency-reduced POM, so any coordinate transformation has to manipulate this object as well. > version-expression transformation interferes with plugins like GPG > -- > > Key: MNG-4167 > URL: http://jira.codehaus.org/browse/MNG-4167 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.2.0 >Reporter: John Casey >Assignee: John Casey > Fix For: 2.2.0 > > > See MGPG-14. -- 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-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179092#action_179092 ] Nick Pellow commented on MNG-3595: -- Bump - has there been any decision as to the best way to move forward? This issue is rather limiting to Clover and any other plugins which create classified artifacts. What about applying Jerome's patch to Maven, and seeing what breaks? I am guessing not a lot would, since it is an extra plugin point, and is backward compatible with previous functionality. > Changes made to project resolved artifacts are overriden when a plugin uses > @requiresDependencyResolution > - > > Key: MNG-3595 > URL: http://jira.codehaus.org/browse/MNG-3595 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Jerome Lacoste > Fix For: 3.x > > Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff, > MNG-3595.diff > > > clover:instrument mojo creates instrumented artifacts and attaches them with > a 'clover' classifier. > It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which > tries to change the project direct and transitive dependencies after > 'swizzling' them [3] (replacing normal artifacts with their clovered ones). > This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR > containing all available clovered dependencies. > Unfortunately maven handles direct and transitive dependencies differently > [4]. While direct dependencies are somewhat preserved (the code comments > references clover), transitive dependencies are re-resolved, and thus the > results of the swizzling operation are lost as soon as a plugin > requiresDependencyResolution in a further part of the lifecycle. > I've managed to hack maven and clover:instrument to work together by allowing > a plugin to attach some sort of "dependency resolution post processing" > operation [5]. > In the case of clover:instrument, the swizzling is then registered in the > maven project and re-performed each time the artifacts are re-resolved. > I am not very fond of this solution, but it seems to work for us on the > attached example. I will further test the patch this week on a large scale > project. > I would like to discuss ways to solve this interaction, whether the clover > plugin should be implemented differently or if maven should have some sort of > support for this use case. > [1] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java > [2] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml > [3] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java > [4] > http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406 > [5] http://www.mail-archive.com/d...@maven.apache.org/msg74636.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3377) Build reactor from toplevel pom
[ http://jira.codehaus.org/browse/MNG-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179100#action_179100 ] Jörg Hohwiller commented on MNG-3377: - After getting deeper into maven, I now understand that there is a problem: In case of an @aggregator Mojo, maven gives away the control which project to process and delegates it to the Mojo. This finally means that an @aggregator Mojo would NOT work as expected when using this feature. I do NOT want to start the discussion whether this was a misleading design decision or not. However this initial issue does NOT make sense and the intention might be addressed by MNG-2675. > Build reactor from toplevel pom > --- > > Key: MNG-3377 > URL: http://jira.codehaus.org/browse/MNG-3377 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jörg Hohwiller > > The following is all about multi-project environments. > For many maven calls the result differs if you perform you mvn command on the > toplevel project > or in a specific module. In the latter case the related modules of the > projects are not included in the reactor > causing the result to be invalid or the build to fail. > There should be a way that I can call maven within a particular module > causing the reactor > to be build from the toplevel pom while walking the relativePath (defaults to > ../pom.xml) upwards > until a pom is reached, that has no parent. From that pom the reactor should > be build, > while the actual build should work on the module where maven was invoked. > A typical example use-case would be the command "mvn eclipse:eclipse". > Right now it does not create project-internal dependencies if it is called > within the module. This is especially nasty when you have a local sandbox > module that should not (yet) be committed. Then you always need to add it > as extra module to your parent pom, call eclipse:eclipse and then revert the > changed pom. > Additional use-cases are that you want to build a specific module rather than > the entire project. Right now you need to enter the module, give "mvn > install" a try. > If it fails, you will see which dependency is missing. Then you go there > before > and try "mvn install" there. This process is iterated until the first "mvn > install" completes. > This is very inconvenient. However fixing such problems as well would > cause that not only the modules are added to the reactor but that the actual > mvn call > is also applied to the dependend modules that are in the reactor. > This specific issue might need some extra discussion... > For reasons of compatibility the suggested improvement could/should be > activated by a specific commandline option (somehow the opposite of "-N"). > A suggestion would be "-R" for reactor and recursive. -- 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-2675) add getModules() method which return a MavenProject List instead of module name String list
[ http://jira.codehaus.org/browse/MNG-2675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179101#action_179101 ] Jörg Hohwiller commented on MNG-2675: - I'd rather suggest to return a List where Module still has public String getPath() but also public MavenProject getProject() Now there should be a way to do getProject() even if the module is NOT part of the reactor. This should be done via lazy evaluation. Therefore an additional method should be added to either test if the MavenProject is NOT yet available (boolean isProjectAvailable()) or a method that ensures to load it (boolean loadProject()) while getProject() will return null before loadProject() was executed in case the MavenProject is not yet available. I personally prefer the first suggestion. > add getModules() method which return a MavenProject List instead of module > name String list > --- > > Key: MNG-2675 > URL: http://jira.codehaus.org/browse/MNG-2675 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0.4 > Environment: Maven 2.0.4, Windows 2000 >Reporter: David Vicente > Fix For: 3.x > > > Hi, > i try to develop a dashboard report plugin. > But i have a problem with a multi-project pom which i used to test my plugin. > I have a master project with modules which have some modules or project. > Until now, i get the modules list with project.getModules() method and i > compare each module name with the project name that i get with > project.getCollectedProjects() method. > And for each MavenProject object i retreive, i repeat the last algorithm > (getModules() .) > all module names are the same as ArtifactId and my plugin work well. > But with this new project, the module names and ArtifactId are different. > and i can't retreive MavenProjects which are direct module of my pom. > can you add a method to MavenProject object which return the list of modules > as MavenProject object instead of String object ? -- 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-558) Ignoring listed AspectJ dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=179105#action_179105 ] Dale Peakall commented on MECLIPSE-558: --- Brilliant tip Aziz - worked a treat! > Ignoring listed AspectJ dependencies > > > Key: MECLIPSE-558 > URL: http://jira.codehaus.org/browse/MECLIPSE-558 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: AJDT support >Affects Versions: 2.6, 2.7 >Reporter: Dale Peakall > > When AJDT support is enabled, the plugin ignores any dependencies that > include the term "aspectj" in the artifactId: these include aspectjrt.jar, > aspectjweaver.jar and aspectjtools.jar. Instead the project gets created > with a link to the AspectJ Runtime Library "Folder" which just contains > aspectjrt.jar. However, if the project depends on the other AspectJ > artifacts, e.g. aspectjweaver.jar (because it uses load-time-weaving) it is > broken and no amount of POM tweaking will get it back in there. > Using the none is fine if the project doesn't > include any aspects - but if it does it needs AJDT to compile the aspect - > but also needs the other AspectJ artifacts (that were specified in the POM) > to run Unit Tests etc. > At a minimum the plugin should be modified to only replace aspectjrt. > However, I am generally uncomfortable with the whole replacement concept. As > long as projects specify the appropriate dependencies then AJDT will be able > to compile and run the project (i.e. the special "AspectJ Runtime Library" > folder is not required). This will also ensure that a consistent version of > AspectJ is used (the version provided by Eclipse need not be the same as > specified in the POM). -- 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
