[jira] Commented: (CONTINUUM-620) Changes section in Continuum build result and build e-mail only show blank columns and file names
[ http://jira.codehaus.org/browse/CONTINUUM-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91005 ] Wendy Smoak commented on CONTINUUM-620: --- What do the scm urls look like when the author/date/comment information is blank? I can reproduce this when the scm urls for Subversion have a trailing slash, so that the url constructed by adding the artifactId has two slashes, for example: scm:svn:http://svn.apache.org/repos/asf/maven/plugins/trunk//maven-dependency-plugin > Changes section in Continuum build result and build e-mail only show blank > columns and file names > - > > Key: CONTINUUM-620 > URL: http://jira.codehaus.org/browse/CONTINUUM-620 > Project: Continuum > Issue Type: Bug > Components: Core system, SCM, Web interface >Affects Versions: 1.0.3 > Environment: Using the version from continuum-20060306.143000.tar.gz > Windows XP SP2 >Reporter: Mang Lau > Assigned To: Emmanuel Venisse > Fix For: 1.1-alpha-# > > > The Changes section in the build results screen show 3 blank columns and the > name of the changed file in the 4th column. This is also true in the build > e-mail Continuum sends out after the build. I believe that the columns are > supposed to show the author and any check-in comments from the SCM. -- 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-2898) Look at allowing all org.codehaus.plexus.util.xml to show through
[ http://jira.codehaus.org/browse/MNG-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2898: --- Fix Version/s: 2.0.6 Doing a clean install in surefire yields: java.lang.NoSuchMethodError: org.codehaus.plexus.util.xml.Xpp3Dom.writeToSerializer(Ljava/lang/String;Lorg/codehaus/plexus/util/xml/pull/XmlSerializer;)V at org.apache.maven.doxia.site.decoration.io.xpp3.DecorationXpp3Writer.writeBody(DecorationXpp3Writer.java:119) at org.apache.maven.doxia.site.decoration.io.xpp3.DecorationXpp3Writer.writeDecorationModel(DecorationXpp3Writer.java:202) at org.apache.maven.doxia.site.decoration.io.xpp3.DecorationXpp3Writer.write(DecorationXpp3Writer.java:67) at org.apache.maven.plugins.site.SiteDescriptorArtifactMetadata.storeInLocalRepository(SiteDescriptorArtifactMetadata.java:81) at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.install(DefaultRepositoryMetadataManager.java:450) at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:79) at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:94) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Look at allowing all org.codehaus.plexus.util.xml to show through > - > > Key: MNG-2898 > URL: http://jira.codehaus.org/browse/MNG-2898 > Project: Maven 2 > Issue Type: Task >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > We have things like merging code in the DOM and it access StringUtils and the > Serializer. Why and how this happened I have no idea as the DOM is a piece of > data. But it leaks all over the place causing problems with doxia because > Xpp3Dom is open while the rest of p-u is hidden in the core causing > NoSuchMethod exceptions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2898) Look at allowing all org.codehaus.plexus.util.xml to show through
Look at allowing all org.codehaus.plexus.util.xml to show through - Key: MNG-2898 URL: http://jira.codehaus.org/browse/MNG-2898 Project: Maven 2 Issue Type: Task Reporter: Jason van Zyl We have things like merging code in the DOM and it access StringUtils and the Serializer. Why and how this happened I have no idea as the DOM is a piece of data. But it leaks all over the place causing problems with doxia because Xpp3Dom is open while the rest of p-u is hidden in the core causing NoSuchMethod exceptions. -- 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-2897) Make sure that Xpp3Dom is shared from the core to plugins
[ http://jira.codehaus.org/browse/MNG-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2897. -- Resolution: Fixed We use a realm import to prevent the plugin loaded plexus-utils from being accessed. > Make sure that Xpp3Dom is shared from the core to plugins > - > > Key: MNG-2897 > URL: http://jira.codehaus.org/browse/MNG-2897 > Project: Maven 2 > Issue Type: Bug >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > This is the only class that is used across classloader boundaries. I have > made a note but any DOM objects used for plugin configuration should be part > of the plugin-api. -- 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-2894) Make sure that if a plugin does not specify the use of plexus-utils that once is fed in to protect against plugins that use plexus-utils but don't declare it.
[ http://jira.codehaus.org/browse/MNG-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2894. -- Resolution: Fixed Little magic in the plugin manager now takes care of this. > Make sure that if a plugin does not specify the use of plexus-utils that once > is fed in to protect against plugins that use plexus-utils but don't declare > it. > -- > > Key: MNG-2894 > URL: http://jira.codehaus.org/browse/MNG-2894 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.0.4 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2892) Use shade to hide the use of plexus-utils internally so that plugins can use their own version
[ http://jira.codehaus.org/browse/MNG-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2892. -- Resolution: Fixed Shade is deployed and now working. > Use shade to hide the use of plexus-utils internally so that plugins can use > their own version > -- > > Key: MNG-2892 > URL: http://jira.codehaus.org/browse/MNG-2892 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2897) Make sure that Xpp3Dom is shared from the core to plugins
[ http://jira.codehaus.org/browse/MNG-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2897: --- Fix Version/s: 2.0.6 > Make sure that Xpp3Dom is shared from the core to plugins > - > > Key: MNG-2897 > URL: http://jira.codehaus.org/browse/MNG-2897 > Project: Maven 2 > Issue Type: Bug >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > > This is the only class that is used across classloader boundaries. I have > made a note but any DOM objects used for plugin configuration should be part > of the plugin-api. -- 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: (MDEP-47) Ability to have an includes/excludes feature on the dependency:unpack goal.
[ http://jira.codehaus.org/browse/MDEP-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-47: -- Fix Version/s: (was: 2.0-alpha-4) 2.0-alpha-5 > Ability to have an includes/excludes feature on the dependency:unpack goal. > --- > > Key: MDEP-47 > URL: http://jira.codehaus.org/browse/MDEP-47 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: unpack >Reporter: Paul Shemansky > Assigned To: Brian Fox >Priority: Minor > Fix For: 2.0-alpha-5 > > > Perhaps there is another solution that I'm overlooking, and if so... I > apologize, but in the dependency-maven-plugin's dependency:unpack goal, it > would be quite convenient to have an option to have an includes/excludes > capability which did pattern matched unpack resolutions. I.E. : > > > *.class > > > *.html > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MDEP-50) dependency:unpack doesn't seem to handle version ranges
[
http://jira.codehaus.org/browse/MDEP-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-50:
--
Fix Version/s: (was: 2.0-alpha-4)
2.0-alpha-5
> dependency:unpack doesn't seem to handle version ranges
> ---
>
> Key: MDEP-50
> URL: http://jira.codehaus.org/browse/MDEP-50
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: copy, unpack
>Affects Versions: 1.0
> Environment: Java 1.5
>Reporter: Martin Goldhahn
> Assigned To: Brian Fox
> Fix For: 2.0-alpha-5
>
>
> When I use the dependency unpack goal and a version range as shown below,
> Maven cannot download the artifact from the repository. There is a version
> 1.4.1 in the repository. If I use the specific version number 1.4.1. It works.
>
>
> org.codehaus.mojo
> dependency-maven-plugin
>
>
> unpack
> compile
>
> unpack
>
>
>
>
> my.package
> concept
> [1.4,1.5)
> res
>
> ${project.build.sourceDirectory}/../webapp/res
>
>
>
>
>
>
--
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: (MDEP-70) add new mojo to perform analysis of dependencies and fail the build if certain conditions aren't met
[ http://jira.codehaus.org/browse/MDEP-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MDEP-70: -- Fix Version/s: (was: 2.0-alpha-4) 2.0-alpha-5 > add new mojo to perform analysis of dependencies and fail the build if > certain conditions aren't met > > > Key: MDEP-70 > URL: http://jira.codehaus.org/browse/MDEP-70 > Project: Maven 2.x Dependency Plugin > Issue Type: New Feature > Components: analyze >Affects Versions: 2.0-alpha-3 >Reporter: Brian Fox > Assigned To: Brian Fox > Fix For: 2.0-alpha-5 > > > Add the ability to fail the build on: > 1. if there are undeclared direct dependencies > 2. if there are unused dependencies > 3. if snapshots are included anywhere (won't need to run the analyzer for > this) > this mojo should have a skip function similar to surefire,pmd and checkstyle > to easily skip embeded checks. -- 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: (MDEP-62) Ability to disallow groups of deps
[
http://jira.codehaus.org/browse/MDEP-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox updated MDEP-62:
--
Fix Version/s: (was: 2.0-alpha-4)
2.0-alpha-5
> Ability to disallow groups of deps
> --
>
> Key: MDEP-62
> URL: http://jira.codehaus.org/browse/MDEP-62
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: analyze
>Reporter: David Blevins
> Assigned To: Brian Fox
> Fix For: 2.0-alpha-5
>
>
> There's a related issue MNG-2796 (http://jira.codehaus.org/browse/MNG-2796)
> involving some issue with using one pom ("server" parent pom) to depend on
> another pom ("container" parent pom). The desired effect is that any
> children modules of the container parent pom cannot depend on any children
> modules of the server parent pom. Having the server parent pom depend on the
> container parent pom is one way to ensure this cannot happen, but maybe
> considered a hack -- and I suppose it is when you consider that this only
> works if you control the poms of the deps that are "off limits".
> Brett has suggested adding explicit support for this so that groups of deps
> or individual deps could be marked as disallowed. That feature would
> definitely work as an alternate ensuring that nothing in the container group
> depends on anything in the server group.
--
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: (MDEP-74) dependencies in test scope are not handled properly by analyze
[ http://jira.codehaus.org/browse/MDEP-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-74. - Resolution: Fixed Fix Version/s: 2.0-alpha-4 added param to control if it shows all scopes. default is compile only. > dependencies in test scope are not handled properly by analyze > -- > > Key: MDEP-74 > URL: http://jira.codehaus.org/browse/MDEP-74 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0-alpha-3 > Environment: os x 10.4.9, java 1.5.0_07-87, maven 2.0.5 >Reporter: Gregory Kick > Assigned To: Brian Fox > Fix For: 2.0-alpha-4 > > > dependency:analyze doesn't recognize test sources for dependencies with test > scope because despite having numerous unit tests, it lists junit as an unused > dependency. -- 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: (MDEP-76) It would be nice to analyze dependencyManagement exclusions as well as versions
[ http://jira.codehaus.org/browse/MDEP-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-76. - Resolution: Fixed Fix Version/s: 2.0-alpha-4 > It would be nice to analyze dependencyManagement exclusions as well as > versions > --- > > Key: MDEP-76 > URL: http://jira.codehaus.org/browse/MDEP-76 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: analyze >Affects Versions: 2.0-alpha-3 >Reporter: Daniel Kulp > Assigned To: Brian Fox > Fix For: 2.0-alpha-4 > > > In my depManagment section, I do: > > commons-logging > commons-logging > 1.1 > > > log4j > log4j > > > > to hopefully remove log4j from the build.However, if I depend on > something else that depends on commons-logging (like spring or neethi), they > suck in log4j.It would be nice if the analyzer would check if the > exclusions are really occuring. -- 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: (MDEP-77) dependency:analyze is reporting impossible results
[ http://jira.codehaus.org/browse/MDEP-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MDEP-77. - Resolution: Fixed Fix Version/s: 2.0-alpha-4 > dependency:analyze is reporting impossible results > -- > > Key: MDEP-77 > URL: http://jira.codehaus.org/browse/MDEP-77 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: analyze >Affects Versions: 2.0-alpha-3 >Reporter: Matthew Beermann > Assigned To: Brian Fox >Priority: Critical > Fix For: 2.0-alpha-4 > > > When I run dependency:analyze, I'm getting back results that appear to be > absolutely impossible: > [INFO] [dependency:analyze] > [INFO] Used declared dependencies: > [INFO] > com.cerner.system.instrument:system-instrument:jar:2.0-20070320.193427-34:compile > [INFO]com.cerner.system:system-core:jar:2.0-20070320.191012-42:compile > [INFO] Used undeclared dependencies: > [INFO] > com.cerner.system.instrument:system-instrument:jar:2.0-20070320.193427-34:compile > [INFO]com.cerner.system:system-core:jar:2.0-20070320.191012-42:compile > The exact same dependency is both declared and undeclared? I don't think so. > My only guess (but this is purely a guess) is that it gets confused by the > fact that the version is declared on the POM as 2.0-SNAPSHOT, but comes back > with a build number after resolution. -- 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-1442) Uploading proguard 3.8 to The Central Repository
Uploading proguard 3.8 to The Central Repository Key: MAVENUPLOAD-1442 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1442 Project: maven-upload-requests Issue Type: Task Reporter: Vlad Skarzhevskyy Please Upload the latest version to Repository. The last version (posted by me) in repository is 3.7 http://pyx4j.com/downloads/proguard-3.8-bundle.jar http://proguard.sourceforge.net/ ProGuard is a free Java class file shrinker, optimizer, and obfuscator. It removes unused classes, fields, methods, and attributes. It then optimizes the bytecode. It then renames the remaining classes, fields, and methods using short meaningless names. Version 3.8 # Fixed optimization of parameters used as local variables. # Fixed obfuscation with conflicting class member names. # Fixed incremental obfuscation with incomplete mapping file for library jars. -- 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-1441) jMimeMagic 0.1.2
jMimeMagic 0.1.2 Key: MAVENUPLOAD-1441 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1441 Project: maven-upload-requests Issue Type: Task Reporter: David Castro New version of jMimeMagic with a fix to exclude log4j.properties from the jar file...oops. -- 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: (WAGON-78) Support ftp for website deployment
Support ftp for website deployment -- Key: WAGON-78 URL: http://jira.codehaus.org/browse/WAGON-78 Project: wagon Issue Type: New Feature Components: wagon-ftp Affects Versions: 1.0-beta-2 Reporter: Wendy Smoak FTP should be supported for website deployment $ mvn site-deploy ... [INFO] [site:deploy] [INFO] -- [ERROR] BUILD ERROR [INFO] -- [INFO] Wagon protocol 'ftp' doesn't support directory copying [INFO] -- -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2897) Make sure that Xpp3Dom is shared from the core to plugins
Make sure that Xpp3Dom is shared from the core to plugins - Key: MNG-2897 URL: http://jira.codehaus.org/browse/MNG-2897 Project: Maven 2 Issue Type: Bug Reporter: Jason van Zyl This is the only class that is used across classloader boundaries. I have made a note but any DOM objects used for plugin configuration should be part of the plugin-api. -- 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: (MGROOVY-1) Support mojo plugin.xml generation for Groovy mojos
[
http://jira.codehaus.org/browse/MGROOVY-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon updated MGROOVY-1:
---
Fix Version/s: 1.0-alpha-3
> Support mojo plugin.xml generation for Groovy mojos
> ---
>
> Key: MGROOVY-1
> URL: http://jira.codehaus.org/browse/MGROOVY-1
> Project: Maven 2.x Groovy Plugin
> Issue Type: New Feature
>Reporter: Jason Dillon
> Assigned To: Jason Dillon
> Fix For: 1.0-alpha-3
>
>
> Right now there isn't really a good way to generate a plugin.xml for a Mojo
> implemented in Groovy.
> There is the {{javalike-maven-plugin-tools}} module which kinda works, though
> requires some icky ";" tokens to get qDox to properly parse out javadocs for
> parameters. I'm not sure that this module handles annotations on
> super-classes either.
> I've hacked up an extractor.groovy a while ago (MNG-1664) which uses regex,
> but that doesn't handle super-classes either.
> Really need a nice way to parse regular groovy (w/o needing ";') to generate
> a plugin.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] Moved: (MGROOVY-1) Support mojo plugin.xml generation for Groovy mojos
[
http://jira.codehaus.org/browse/MGROOVY-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon moved MOJO-705 to MGROOVY-1:
-
Assignee: (was: Jason Dillon)
Component/s: (was: groovy)
Complexity: (was: Intermediate)
Workflow: jira (was: Maven New)
Key: MGROOVY-1 (was: MOJO-705)
Project: Maven 2.x Groovy Plugin (was: Mojo)
> Support mojo plugin.xml generation for Groovy mojos
> ---
>
> Key: MGROOVY-1
> URL: http://jira.codehaus.org/browse/MGROOVY-1
> Project: Maven 2.x Groovy Plugin
> Issue Type: New Feature
>Reporter: Jason Dillon
>
> Right now there isn't really a good way to generate a plugin.xml for a Mojo
> implemented in Groovy.
> There is the {{javalike-maven-plugin-tools}} module which kinda works, though
> requires some icky ";" tokens to get qDox to properly parse out javadocs for
> parameters. I'm not sure that this module handles annotations on
> super-classes either.
> I've hacked up an extractor.groovy a while ago (MNG-1664) which uses regex,
> but that doesn't handle super-classes either.
> Really need a nice way to parse regular groovy (w/o needing ";') to generate
> a plugin.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] Closed: (MCLOVER-68) XDoclet plugin executes before the Clover plugin in the lifecycle forked by the latter
[ http://jira.codehaus.org/browse/MCLOVER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol closed MCLOVER-68. - Resolution: Fixed Fixed > XDoclet plugin executes before the Clover plugin in the lifecycle forked by > the latter > -- > > Key: MCLOVER-68 > URL: http://jira.codehaus.org/browse/MCLOVER-68 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Vincent Massol > Assigned To: Vincent Massol > Fix For: 2.4 > > > This happens for example for maven plugins bound to the generates-sources > phase. This causes issues as any other plugin expecting the output of the > plugin executing in the generate-sources phase will fail, not finding the > expected data. This is especially true for the XDoclet plugin which is > usually bound to that phase. -- 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: (MCLOVER-68) XDoclet plugin executes before the Clover plugin in the lifecycle forked by the latter
XDoclet plugin executes before the Clover plugin in the lifecycle forked by the latter -- Key: MCLOVER-68 URL: http://jira.codehaus.org/browse/MCLOVER-68 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Vincent Massol Assigned To: Vincent Massol Fix For: 2.4 This happens for example for maven plugins bound to the generates-sources phase. This causes issues as any other plugin expecting the output of the plugin executing in the generate-sources phase will fail, not finding the expected data. This is especially true for the XDoclet plugin which is usually bound to that phase. -- 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-1440) Please upload StubOut
Please upload StubOut - Key: MAVENUPLOAD-1440 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1440 Project: maven-upload-requests Issue Type: Task Reporter: Luke Blanshard The project website is http://stubout.sourceforge.net. I'm the whole development team, see http://stubout.sourceforge.net/team-list.html. The groupId is us.blanshard.stubout. I own the blanshard.us domain, see http://whois.us/whois.cgi?TLD=us&dn=blanshard.us&TYPE=DOMAIN&Search=Submit+Query. StubOut is a JUnit extension that makes it simple to stub out concrete classes during your unit tests, thereby filling a void currently left by the various mock object frameworks. -- 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-1958) we need a var that always points to the root direcotry in multi module builds
[
http://jira.codehaus.org/browse/MNG-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90975
]
Stefano Bagnara commented on MNG-1958:
--
This is somehow related to MNG-2896
Both are needed to make full use of a project-local repository-like folder.
> we need a var that always points to the root direcotry in multi module builds
> -
>
> Key: MNG-1958
> URL: http://jira.codehaus.org/browse/MNG-1958
> Project: Maven 2
> Issue Type: Improvement
>Reporter: Mark Proctor
> Fix For: 2.1.x
>
>
> ${basedir} always points to the local module. There are cases, when having a
> local relative repository, when it would be usefull to have a var that always
> pointed to the root project, ${rootdir}.
> In such a case you may want to think of having the names ${rootdir}
> ${moduledir}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2896) ${basedir} used in a repository url does not work for parent pom lookup
${basedir} used in a repository url does not work for parent pom lookup
---
Key: MNG-2896
URL: http://jira.codehaus.org/browse/MNG-2896
Project: Maven 2
Issue Type: Wish
Components: POM
Affects Versions: 2.0.5
Reporter: Stefano Bagnara
I use something like this to store locally the dependencies.
-
parent-james-stage-m1
James stage repository
file://${basedir}/stage
legacy
true
ignore
true
ignore
Everything works fine but the parent resolution: my main pom.xml has a parent
and it is not looked up in this repository.
Well, it is lookedup, but ${basedir} is not expanded and this way the lookup
does not work.
If I replace the ${basedir} with my full path everything works fine, but I
cannot obviously do that as the local repository is part of the svn tree (by
our choice to not use remote repositories).
Furthermore: is there a variable to be used instead of ${basedir} that always
reference to its own pom.xml folder? I ask this because I have multiple modules
inside this project and I had to add another repository to this pom using
file://${basedir}/../stage (notice the ..) so that submodules will use the same
repository for the lookups, but this sound like an hack.
--
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-1439) eva-properties-0.3
eva-properties-0.3 -- Key: MAVENUPLOAD-1439 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1439 Project: maven-upload-requests Issue Type: Task Reporter: Maximilian Antoni Thank you for uploading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-313) build fails with ClassNotFoundException, BUT the class IS there!
build fails with ClassNotFoundException, BUT the class IS there!
Key: SUREFIRE-313
URL: http://jira.codehaus.org/browse/SUREFIRE-313
Project: Maven Surefire
Issue Type: Bug
Components: classloading
Affects Versions: 2.3
Environment: Windows XP SP2, Java SE 6, Maven 2.0.5
Reporter: Ivan Mikushin
Attachments: mvn-junit4.log, mvn-pojo-test.log, pom.xml
JUnit 4 and POJO tests give ClassNotFoundException exceptions in *test* phase
of the build (pom.xml is attached).
The console output gives a hint: JUnit 3.8.1 is appended to the surefire-booter
forked JVM classpath instead of JUnit 4 (I tried it with junit-4.0, 4.1 and
4.2). When I try a POJO test case I get the same error.
Also attached are the outputs from the command lines for JUnit4 and POJO test
cases
{{mvn -X clean test > mvn.log}}
--
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-2664) Add native support for webdav
[ http://jira.codehaus.org/browse/MNG-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90972 ] Wendy Smoak commented on MNG-2664: -- To use deploy:deploy-file with webdav, you can use a simple pom file containing the wagon-webdav build extension. Either save it as pom.xml in the current directory, or use -f on the command line to point Maven at an alternate file. See: http://maven.apache.org/archiva/guides/getting-started/maven-configuration.html at the bottom. > Add native support for webdav > - > > Key: MNG-2664 > URL: http://jira.codehaus.org/browse/MNG-2664 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Arnaud Heritier > Fix For: 2.1.x > > Attachments: MNG-2664.patch > > > Actually with maven 2.0.4 we can't use the deploy:deploy-file goal to add an > artifact on a remote repository with webdav. > This is really annoying for archiva which supports webdav for uploads. -- 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: (MEAR-50) Add the loader-repository node for jboss configuration
[
http://jira.codehaus.org/browse/MEAR-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90970
]
Stephane Nicoll commented on MEAR-50:
-
Greg,
Already discussed previously, the patch does not cover all cases, see the
jboss4 DTD:
{noformat}
{noformat}
The patch misses test cases as well. If you like, you can fully implement it
with a test and I'll be glad to review and apply it.
> Add the loader-repository node for jboss configuration
> --
>
> Key: MEAR-50
> URL: http://jira.codehaus.org/browse/MEAR-50
> Project: Maven 2.x Ear Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
>Reporter: Maurice Zeijen
> Assigned To: Stephane Nicoll
> Fix For: 2.4
>
> Attachments: MEAR-50.patch
>
>
> In the jboss-app.xml file it is possible to add a loader-repository node. To
> complement the jboss configuration in the ear plugin, it should be possible
> to add this node.
--
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: (MEAR-59) Unable to customize the main artifact when it is used together with an attached artifact
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-59. --- Resolution: Fixed I didn''t apply your patch, we need to have an explicit config for the main artifact. By default none refers to the main artifact. This can be changed using the mainArtifactId parameter of the EAR plugin. > Unable to customize the main artifact when it is used together with an > attached artifact > > > Key: MEAR-59 > URL: http://jira.codehaus.org/browse/MEAR-59 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Chris Tucker > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > Attachments: MPEAR-48-maven-ear-plugin.patch > > > When resolving ear modules the AbstractEarModule.java class requests a unique > artifact from the artifact repository using getUniqueArtifact(groupId, > artifactId, type, classifier). In the case where the classifier is null > getUniqueArtifact will attempt to find an artifact without considering the > classifier -- it will match *any* artifact with the same groupId, artifactId, > and type, regardless of whether the classifier matches (is null). Currently > the logic in AbstractEarModule does not handle the case where the classifier > is null: if there is one artifact without a classifier (the one we're looking > for) and another with a classifier (e.g. a clover jar) the ear module will > throw an exception at line 104 stating that a classifier is required. This > means that any build that builds, for example, an instrumented jar, will fail > to construct an ear. > This is fixed in the attached patch by explicitly iterating the set of > artifacts that matches a call to getArtifacts() on the artifact repository > with just the group, artifact, and type. Ideally this patch would instead be > made to ArtifactRepository itself to include a search that explicitly matches > null classifiers. -- 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: (MEAR-59) Unable to customize the main artifact when it is used together with an attached artifact
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-59: Summary: Unable to customize the main artifact when it is used together with an attached artifact (was: Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists) > Unable to customize the main artifact when it is used together with an > attached artifact > > > Key: MEAR-59 > URL: http://jira.codehaus.org/browse/MEAR-59 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Chris Tucker > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > Attachments: MPEAR-48-maven-ear-plugin.patch > > > When resolving ear modules the AbstractEarModule.java class requests a unique > artifact from the artifact repository using getUniqueArtifact(groupId, > artifactId, type, classifier). In the case where the classifier is null > getUniqueArtifact will attempt to find an artifact without considering the > classifier -- it will match *any* artifact with the same groupId, artifactId, > and type, regardless of whether the classifier matches (is null). Currently > the logic in AbstractEarModule does not handle the case where the classifier > is null: if there is one artifact without a classifier (the one we're looking > for) and another with a classifier (e.g. a clover jar) the ear module will > throw an exception at line 104 stating that a classifier is required. This > means that any build that builds, for example, an instrumented jar, will fail > to construct an ear. > This is fixed in the attached patch by explicitly iterating the set of > artifacts that matches a call to getArtifacts() on the artifact repository > with just the group, artifact, and type. Ideally this patch would instead be > made to ArtifactRepository itself to include a search that explicitly matches > null classifiers. -- 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: (MEAR-59) Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90966 ] Stephane Nicoll commented on MEAR-59: - mmm specifying an empty classifier like this won't work since plexus with inject a 'null' classifier. We need to specify we want the main artifact... > Ear plugin fails to resolve artifact with null classifier when equivalent, > classified artifact exists > - > > Key: MEAR-59 > URL: http://jira.codehaus.org/browse/MEAR-59 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Chris Tucker > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > Attachments: MPEAR-48-maven-ear-plugin.patch > > > When resolving ear modules the AbstractEarModule.java class requests a unique > artifact from the artifact repository using getUniqueArtifact(groupId, > artifactId, type, classifier). In the case where the classifier is null > getUniqueArtifact will attempt to find an artifact without considering the > classifier -- it will match *any* artifact with the same groupId, artifactId, > and type, regardless of whether the classifier matches (is null). Currently > the logic in AbstractEarModule does not handle the case where the classifier > is null: if there is one artifact without a classifier (the one we're looking > for) and another with a classifier (e.g. a clover jar) the ear module will > throw an exception at line 104 stating that a classifier is required. This > means that any build that builds, for example, an instrumented jar, will fail > to construct an ear. > This is fixed in the attached patch by explicitly iterating the set of > artifacts that matches a call to getArtifacts() on the artifact repository > with just the group, artifact, and type. Ideally this patch would instead be > made to ArtifactRepository itself to include a search that explicitly matches > null classifiers. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-312) Surefire report includes other testcases in TEST-XXX.xml files
Surefire report includes other testcases in TEST-XXX.xml files -- Key: SUREFIRE-312 URL: http://jira.codehaus.org/browse/SUREFIRE-312 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.3 Environment: Windows XP, JUnit Reporter: Claus Ibsen Priority: Minor Attachments: surefire-bug.JPG I am a comitter on WebWork/XWork and we have changed to maven. I have some strange behaviour using maven and running the unit tests using surefire. I have discovered that surefire reports more testcases in it's TEST-XXX.xml files than there actually are testXXX methods for within the JUnit testcase. As an example is this JUnit test file that has 13 methods for testing. But in the bottom of the TEST-com.opensymphony.xwork2.interceptor.TimerInterceptorTest.xml file there are much more testcases listed (the 13 from the bottom is the correct tests): So when you generate the surefire report using: mvn surefire-report:report The HTML report is wrong as it would list to many testcases when you browse each junit test class. It can be tested by checking out the source code from XWork and run: mvn test. URL: https://svn.opensymphony.com/svn/xwork/trunk Se the attached image. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2895) XDoclet plugin doesn't work anymore (Class 'org.codehaus.classworlds.ClassRealm' cannot be instantiated" error message)
XDoclet plugin doesn't work anymore (Class
'org.codehaus.classworlds.ClassRealm' cannot be instantiated" error message)
---
Key: MNG-2895
URL: http://jira.codehaus.org/browse/MNG-2895
Project: Maven 2
Issue Type: Bug
Components: Errors
Affects Versions: 2.1.x
Reporter: Vincent Massol
* It works fine in 2.0.5, fails in Maven 2.1.x (built from trunk on 24/3/2007):
{noformat}
INFO] Error for project: Maven Clover Plugin XDoclet Sample (during
org.codehaus.mojo:xdoclet-maven-plugin:1.0-alpha-2:xdoclet)
[INFO]
[INFO] Failed to configure plugin parameters for:
org.codehaus.mojo:xdoclet-maven-plugin:1.0-alpha-2
on the command line, specify: '-DdummyExpression=VALUE'
Cause: Class 'org.codehaus.classworlds.ClassRealm' cannot be instantiated
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error configuring:
org.codehaus.mojo:xdoclet-maven-plugin. Reason: Unable to parse the created DOM
for plugin configuration
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:388)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:260)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:146)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:124)
at
org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:906)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:369)
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.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351)
Caused by: org.apache.maven.plugin.PluginConfigurationException: Error
configuring: org.codehaus.mojo:xdoclet-maven-plugin. Reason: Unable to parse
the created DOM for plugin configuration
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1180)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:822)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:590)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:359)
... 14 more
Caused by:
org.codehaus.plexus.component.configurator.ComponentConfigurationException:
Class 'org.codehaus.classworlds.ClassRealm' cannot be instantiated
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:133)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:86)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:135)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1174)
... 17 more
Caused by: java.lang.InstantiationException: org.codehaus.classworlds.ClassRealm
at java.lang.Class.newInstance0(Class.java:335)
at java.lang.Class.newInstance(Class.java:303)
at
org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:123)
... 22 more
[INFO]
[INFO] BUILD ERRORS
[INFO]
{noformat}
POM:
{code}
4.0.0
org.apache.maven.plugins
maven-clover-plugin-sample-xdoclet
jar
Maven Clover Plugin XDoclet Sample
[jira] Closed: (MNG-1214) Build Maven2 on free java SDK
[ http://jira.codehaus.org/browse/MNG-1214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1214. -- Resolution: Won't Fix We will build and test against released and certified JDKs, trying to support all variants of GJC is untentable. > Build Maven2 on free java SDK > - > > Key: MNG-1214 > URL: http://jira.codehaus.org/browse/MNG-1214 > Project: Maven 2 > Issue Type: New Feature > Environment: Ubuntu breezy with GCJ 4.0.1 >Reporter: Damien Raude-Morvan >Priority: Minor > Fix For: 2.2.x > > > It would make maven2 more "GNU Classpath" friendly if there is less > flexibility in maven 2 bootstraping ode. > For example in maven-mboot2/src/main/java/compile/JavacCompiler.java, the > class "com.sun.tools.javac.Main" is hardcoded. This result in a > NullPointerException when trying to build maven2 with GCJ. -- 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-233) ability to clean up local repository
[ http://jira.codehaus.org/browse/MNG-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-233. - Resolution: Fixed Mojo has been created. > ability to clean up local repository > > > Key: MNG-233 > URL: http://jira.codehaus.org/browse/MNG-233 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Reporter: Brett Porter >Priority: Trivial > Fix For: 2.2.x > > > it's probably not too heavy to touch some metadata (or update a single file > in the repository) for each dependency that is used (not downloaded, but > actually used). It would only be needed once per dep per session. > With that information, a tool could easily remove files from the local > repository not used in X days so they can be downloaded again 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] Closed: (MNG-1297) Continuum build throws LifecycleExecutionException while building Maven PLUGIN Plugin
[ http://jira.codehaus.org/browse/MNG-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1297. -- Resolution: Won't Fix wrong project. > Continuum build throws LifecycleExecutionException while building Maven > PLUGIN Plugin > -- > > Key: MNG-1297 > URL: http://jira.codehaus.org/browse/MNG-1297 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.0.1 > Environment: Maven 2.0.1-SNAPSHOT >Reporter: Grzegorz Slowikowski >Priority: Minor > Fix For: 2.2.x > > > In your continuum logs there is an exception. Build finishes with success. > What does this exception mean? > Why is it not critical? > - > [INFO] Error for project: Maven PLUGIN Plugin (during install) > [INFO] > > [INFO] Internal error in the plugin manager executing goal > 'org.apache.maven.plugins:maven-plugin-plugin:2.0.1-SNAPSHOT:updateRegistry': > Unable to find the mojo > 'org.apache.maven.plugins:maven-plugin-plugin:2.0.1-SNAPSHOT:updateRegistry' > in the plugin 'org.apache.maven.plugins:maven-plugin-plugin' > org.apache.maven.plugin.plugin.UpdatePluginRegistryMojo > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the > plugin manager executing goal > 'org.apache.maven.plugins:maven-plugin-plugin:2.0.1-SNAPSHOT:updateRegistry': > Unable to find the mojo > 'org.apache.maven.plugins:maven-plugin-plugin:2.0.1-SNAPSHOT:updateRegistry' > in the plugin 'org.apache.maven.plugins:maven-plugin-plugin' > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:523) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the > mojo > 'org.apache.maven.plugins:maven-plugin-plugin:2.0.1-SNAPSHOT:updateRegistry' > in the plugin 'org.apache.maven.plugins:maven-plugin-plugin' > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:520) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:377) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) > ... 16 more > Caused by: > org.codehaus.plexus.component.repository.exception.ComponentLookupException: > Unable to lookup component > 'org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-plugin-plugin:2.0.1-SNAPSHOT:updateRegistry', > it could not be created > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:331) > at > org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:436) > at > org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:511) > ... 18 more > Caused by: > org.codehaus.plexus.component.factory.ComponentInstantiationException: Could > not instanciate component: role: 'null', implementation: > 'org.apache.maven.plugin.plugin.UpdatePluginRegistryMojo' > at > org.codehaus.plexus.component.factory.java.JavaComponentFactory.makeException(JavaComponentFactor
[jira] Closed: (MNG-1664) Write mojos w/Groovy
[ http://jira.codehaus.org/browse/MNG-1664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1664. -- Resolution: Fixed jason has finished this. > Write mojos w/Groovy > > > Key: MNG-1664 > URL: http://jira.codehaus.org/browse/MNG-1664 > Project: Maven 2 > Issue Type: New Feature > Components: Plugin Creation Tools >Affects Versions: 2.0 >Reporter: Jason Dillon > Fix For: 2.2.x > > Attachments: maven2-groovy-mojo-support.tar.gz > > > Attached is an archive containing 3 modules: > * plexus-groovy-factory > * maven-plugin-tools-groovy > * groovytest-maven-plugin > plexus-groovy-factory is a plexus component factory, which allows Groovy > objects to be used as components inside of Plexus. I started with the > existing module of the same name in the plexus project, but most of it > changed, so I just included the entire module instead of providing a patch. > Tests included. > maven-plugin-tools-groovy provides the ability to extract MojoDescriptors > from one or more .groovy sources. This is based off of the beanshell > extractor.sh... its kinda hacky, but functions _well enough_ for now. > groovytest-maven-plugin is used to test. > groovytest-maven-plugin is just a simple maven plugin that uses the new > groovy script support. It shows that a .groovy can use other .groovy sources > inside of the plugin, and shows that the descriptor extractor functions. Its > basically useful for integration testing. > * * * > Someone should check & update the version details for the parent pom of these > modules. I just used whatever I had on my local system to get it working. > This plugin depends on Groovy 1.0 JSR 05, but 04 will sorta work, but will > not function with included classes in the same jar. Since 04 was just > releases yesterday, these modules depend on 05 SNAPSHOT, which should be > available on the codehaus ci repo. When 1.0 is released this dep should be > updated to that version. -- 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-1912) Support for ivy repositories
[ http://jira.codehaus.org/browse/MNG-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-1912. -- Resolution: Won't Fix > Support for ivy repositories > > > Key: MNG-1912 > URL: http://jira.codehaus.org/browse/MNG-1912 > Project: Maven 2 > Issue Type: Wish > Components: Artifacts and Repositories >Affects Versions: 2.0.1 >Reporter: Grégory Joseph > Fix For: 2.2.x > > > Hi, > It'd be nice if maven would support ivy-style repositories. They're similar > to maven's, but not truly the same. It seems pretty straightforward to write > a new implementation of ArtifactRepositoryLayout, but the lack of javadoc > left me dubious re: the semantics of each method to implement ;) > It might of course be better, but more complex, to also support ivy > dependencies... but I'd be happy with being able to just get artifacts from > http://ivyrep.opensymphony.com/ without having to manually install them, for > instance. -- 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: (CONTINUUM-1223) Ability to choose JVM (export JAVA_HOME) for different projects
Ability to choose JVM (export JAVA_HOME) for different projects --- Key: CONTINUUM-1223 URL: http://jira.codehaus.org/browse/CONTINUUM-1223 Project: Continuum Issue Type: Test Components: Integration - Maven 2 Affects Versions: 1.0.3 Environment: N/A Reporter: David J. M. Karlsen Although it's possible to configure compile-plugin, surefire etc to use specific JVM's - there should be an option to specify the JVM (e.g. export JAVA_HOME before executing mvn) as different plugins and so on migth require a specific JVM. -- 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-2859) Maven 2.0.5 needs Maven 2.0.5 Tasks for Ant and Maven 2.0.5 Embedder for everything to remain sane
[ http://jira.codehaus.org/browse/MNG-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90957 ] Jason van Zyl commented on MNG-2859: These don't live in maven-artifact-ant anymore. I would love some help cleaning them up. But they are here now: http://svn.apache.org/repos/asf/maven/ant-tasks/trunk/ > Maven 2.0.5 needs Maven 2.0.5 Tasks for Ant and Maven 2.0.5 Embedder for > everything to remain sane > -- > > Key: MNG-2859 > URL: http://jira.codehaus.org/browse/MNG-2859 > Project: Maven 2 > Issue Type: Bug > Components: Ant tasks, Embedding >Affects Versions: 2.0.5 >Reporter: Greg Luck > Assigned To: Jason van Zyl > Attachments: maven-artifact-ant-2.0.5-SNAPSHOT-dep.jar > > > I am moving my project from Maven plus Antlib to pure Maven, maybe. > Right now I have a super pom with a dependencyManagement element. When I > copied it and pasted that tag to the child pom used by Antlib it did not > work. Now, because I am using Maven 2.0.5 and Antlib 2.0.4 I don't know > whether the model format has changed or whether dependencyManagement never > worked for Antlib. > Similarly we are using TeamCity 2.0EAP. Because of problems in 2.04 they > upgraded to the prerelease 2.1, skipping 2.05 which of course does not exist. > Now we have a problem that occurs in 2.1 which does not happen in 2.0.5. This > has forced us back to TeamCity 1.2. > But the issue is that the Maven family should remain compatible. The only way > to do that is to release all together. Instead we are using three versions of > Maven, each with their idiosyncratic bugs and features. > I think it is an error to release a new version of core Maven without the > others, which is why this is a bug and not a feature request. > The following email exchange mentions Jason will create a JIRA. I went > looking for it but could not find it, so created this one. > Re: Ant Maven Tasks > Jason van Zyl > Wed, 21 Feb 2007 06:40:26 -0800 > On 21 Feb 07, at 2:54 AM 21 Feb 07, Paul King wrote: > Hi, > I couldn't find any info regarding the status of the ant maven tasks > wrt to the 2.0.5 release. Are the ant tasks still at 2.0.4? > As already pointed out they will be released separately from Maven itself. > They need some love, the Ant code itself has not changed at all so we simply > could do a release with the new 2.0.5 code. If there is a lot of demand I'll > look into it. I'll JIRA for it later this week and people can vote. We're > making lots of headway doing plugin releases and I would still like to get > 2.0.6 and 2.1-alpha-1 out relatively shortly so I probably won't have a ton > of time to prepare a release. Someone else might though. > Jason. > Cheers, Paul. -- 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: (MWAR-53) WAR plugin does not allow for ignoring the web.xml file
[ http://jira.codehaus.org/browse/MWAR-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90955 ] Piotr Tabor commented on MWAR-53: - The issue depends on org.codehaus.plexus.archiver.war.WarArchiver class (initZipOutputStream method), which doesn't allow to create war file without "web.xml" descriptor. The Ant WAR task doesn't allow this neither (org.apache.tools.ant.taskdefs.War) When I changed the maven-war-plugin to ignore lack of the file (warn only), I got the result: [INFO] Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) [INFO] [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling WAR: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:146) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: webxml attribute is required (or pre-existing WEB-INF/web.xml if executing in update mode) at org.codehaus.plexus.archiver.war.WarArchiver.initZipOutputStream(WarArchiver.java:148) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:348) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchive(AbstractZipArchiver.java:250) at org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:402) at org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:188) at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:130) ... 18 more So I think, the issue shouldn't be fixed. The possibility to cope with overlay's problem will be provided in other way. > WAR plugin does not allow for ignoring the web.xml file > --- > > Key: MWAR-53 > URL: http://jira.codehaus.org/browse/MWAR-53 > Project: Maven 2.x War Plugin > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Andreas Schildbach > > The WAR plugin does not allow for ignoring the web.xml file. I know that a > WAR without web.xml does not make any sense in the normal use case, but if > I'd like to overlay/join WARs with the WAR plugin (by defining dependencies > to other WARs), there can be only one web.xml in the candidates (the WAR > plugin does not join web.xml like cargo uberwar does). > If I do not have a web.xml in my src/main/webapp folder, the WAR plugin > complains. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2894) Make sure that if a plugin does not specify the use of plexus-utils that once is fed in to protect against plugins that use plexus-utils but don't declare it.
Make sure that if a plugin does not specify the use of plexus-utils that once is fed in to protect against plugins that use plexus-utils but don't declare it. -- Key: MNG-2894 URL: http://jira.codehaus.org/browse/MNG-2894 Project: Maven 2 Issue Type: Task Reporter: Jason van Zyl Fix For: 2.0.6 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2894) Make sure that if a plugin does not specify the use of plexus-utils that once is fed in to protect against plugins that use plexus-utils but don't declare it.
[ http://jira.codehaus.org/browse/MNG-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2894: --- Affects Version/s: 2.0.4 Fix Version/s: 2.0.6 > Make sure that if a plugin does not specify the use of plexus-utils that once > is fed in to protect against plugins that use plexus-utils but don't declare > it. > -- > > Key: MNG-2894 > URL: http://jira.codehaus.org/browse/MNG-2894 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.0.4 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
[ http://jira.codehaus.org/browse/MNG-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2893: --- Assignee: Jason van Zyl Affects Version/s: 2.0.5 > Update the DefaultPluginManager to not use a project depMan for controlling > it's transitive dependencies > > > Key: MNG-2893 > URL: http://jira.codehaus.org/browse/MNG-2893 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > > An adjustment to MNG-1577. The classpath for plugins should not be affected > by a projects depMan. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2893) Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies
Update the DefaultPluginManager to not use a project depMan for controlling it's transitive dependencies Key: MNG-2893 URL: http://jira.codehaus.org/browse/MNG-2893 Project: Maven 2 Issue Type: Task Reporter: Jason van Zyl An adjustment to MNG-1577. The classpath for plugins should not be affected by a projects depMan. -- 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: (MANTLR-16) dependency:analyze shows errors
dependency:analyze shows errors --- Key: MANTLR-16 URL: http://jira.codehaus.org/browse/MANTLR-16 Project: Maven 2.x Antlr Plugin Issue Type: Bug Affects Versions: 2.0-beta-2 Reporter: Brian Fox Assigned To: Brian Fox Fix For: 2.0-beta-2 [INFO] Used undeclared dependencies: [INFO]org.apache.maven:maven-artifact:jar:2.0.2:compile [INFO]junit:junit:jar:3.8.1:compile [INFO]org.apache.maven:maven-model:jar:2.0.2:compile [INFO]org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]plexus:plexus-utils:jar:1.0.2:compile [INFO]org.apache.maven.reporting:maven-reporting-api:jar:2.0.2:compile [INFO]org.codehaus.plexus:plexus-i18n:jar:1.0-beta-6:compile [INFO]org.apache.maven.doxia:doxia-site-renderer:jar:1.0-alpha-7:compile [INFO]org.apache.maven.doxia:doxia-sink-api:jar:1.0-alpha-7:compile [INFO] Unused declared dependencies: [INFO]org.codehaus.plexus:plexus-utils:jar:1.1:compile [WARNING] Potential problems discovered. -- 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-2892) Use shade to hide the use of plexus-utils internally so that plugins can use their own version
[ http://jira.codehaus.org/browse/MNG-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2892: --- Summary: Use shade to hide the use of plexus-utils internally so that plugins can use their own version (was: Use minijar to hide the use of plexus-utils internally so that plugins can use their own version) > Use shade to hide the use of plexus-utils internally so that plugins can use > their own version > -- > > Key: MNG-2892 > URL: http://jira.codehaus.org/browse/MNG-2892 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.5 >Reporter: Jason van Zyl > Assigned To: Jason van Zyl > Fix For: 2.0.6 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MANT-27) dependency:analyze shows errors
[ http://jira.codehaus.org/browse/MANT-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MANT-27. - Resolution: Fixed > dependency:analyze shows errors > --- > > Key: MANT-27 > URL: http://jira.codehaus.org/browse/MANT-27 > Project: Maven 2.x Ant Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-2 >Reporter: Brian Fox > Assigned To: Brian Fox > Fix For: 2.0-beta-2 > > > [INFO] Used undeclared dependencies: > [INFO]junit:junit:jar:3.8.1:compile > [INFO]org.apache.maven:maven-artifact:jar:2.0.4:compile > [INFO]org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile > [INFO]org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile > [INFO]xml-apis:xml-apis:jar:1.0.b2:compile > [INFO]org.apache.maven:maven-model:jar:2.0.4:compile > [INFO] Unused declared dependencies: > [INFO]org.apache.maven:maven-core:jar:2.0.4:test > [INFO]ant:ant-junit:jar:1.6.5:test > [WARNING] Potential problems discovered. -- 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: (MANT-27) dependency:analyze shows errors
dependency:analyze shows errors --- Key: MANT-27 URL: http://jira.codehaus.org/browse/MANT-27 Project: Maven 2.x Ant Plugin Issue Type: Bug Affects Versions: 2.0-beta-2 Reporter: Brian Fox Assigned To: Brian Fox Fix For: 2.0-beta-2 [INFO] Used undeclared dependencies: [INFO]junit:junit:jar:3.8.1:compile [INFO]org.apache.maven:maven-artifact:jar:2.0.4:compile [INFO]org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9:compile [INFO]org.apache.maven.wagon:wagon-provider-api:jar:1.0-alpha-6:compile [INFO]xml-apis:xml-apis:jar:1.0.b2:compile [INFO]org.apache.maven:maven-model:jar:2.0.4:compile [INFO] Unused declared dependencies: [INFO]org.apache.maven:maven-core:jar:2.0.4:test [INFO]ant:ant-junit:jar:1.6.5:test [WARNING] Potential problems discovered. -- 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: (MPLUGIN-30) dependency:analyze shows errors
[ http://jira.codehaus.org/browse/MPLUGIN-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MPLUGIN-30. Assignee: Brian Fox Resolution: Fixed Fix Version/s: 2.4 > dependency:analyze shows errors > --- > > Key: MPLUGIN-30 > URL: http://jira.codehaus.org/browse/MPLUGIN-30 > Project: Maven 2.x Plugin Plugin > Issue Type: Bug >Reporter: Brian Fox > Assigned To: Brian Fox > Fix For: 2.4 > > > [INFO] Used undeclared dependencies: > [INFO]org.codehaus.plexus:plexus-utils:jar:1.0.4:compile > [INFO]org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:compile > [INFO]doxia:doxia-core:jar:1.0-alpha-4:compile > [INFO]org.apache.maven:maven-plugin-descriptor:jar:2.0.5:compile > [INFO]org.apache.maven.reporting:maven-reporting-api:jar:2.0:compile > [INFO]org.apache.maven:maven-artifact:jar:2.0:compile > [INFO]doxia:doxia-sink-api:jar:1.0-alpha-4:compile > [INFO] Unused declared dependencies: > [INFO]org.apache.maven:maven-plugin-tools-beanshell:jar:2.1:runtime > [INFO]org.apache.maven:maven-plugin-tools-java:jar:2.1:runtime -- 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: (MPLUGIN-30) dependency:analyze shows errors
dependency:analyze shows errors --- Key: MPLUGIN-30 URL: http://jira.codehaus.org/browse/MPLUGIN-30 Project: Maven 2.x Plugin Plugin Issue Type: Bug Reporter: Brian Fox [INFO] Used undeclared dependencies: [INFO]org.codehaus.plexus:plexus-utils:jar:1.0.4:compile [INFO]org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-8:compile [INFO]doxia:doxia-core:jar:1.0-alpha-4:compile [INFO]org.apache.maven:maven-plugin-descriptor:jar:2.0.5:compile [INFO]org.apache.maven.reporting:maven-reporting-api:jar:2.0:compile [INFO]org.apache.maven:maven-artifact:jar:2.0:compile [INFO]doxia:doxia-sink-api:jar:1.0-alpha-4:compile [INFO] Unused declared dependencies: [INFO]org.apache.maven:maven-plugin-tools-beanshell:jar:2.1:runtime [INFO]org.apache.maven:maven-plugin-tools-java:jar:2.1:runtime -- 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: (MVERIFIER-5) mvn not found when invoking the verifier from IDEA
[
http://jira.codehaus.org/browse/MVERIFIER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MVERIFIER-5:
Priority: Minor (was: Major)
Creating a simlink in /usr/bin fixes the issue.
> mvn not found when invoking the verifier from IDEA
> --
>
> Key: MVERIFIER-5
> URL: http://jira.codehaus.org/browse/MVERIFIER-5
> Project: Maven 2.x Verifier Plugin
> Issue Type: Bug
> Environment: MacOsX
>Reporter: Stephane Nicoll
>Priority: Minor
>
> When i use the verifier in Intellij IDEA, the verifier is unable to find mvn
> in the path. I don't have the problem on Linux/Windows XP.
> The path is set properly
> {noformat}
> org.apache.maven.it.VerificationException:
> org.apache.maven.it.util.cli.CommandLineException: Error while executing
> process.
> at org.apache.maven.it.Verifier.executeGoals(Verifier.java:907)
> at org.apache.maven.it.Verifier.executeGoal(Verifier.java:780)
> at org.apache.maven.it.Verifier.executeGoal(Verifier.java:774)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:84)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:114)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:132)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:161)
> at
> org.apache.maven.plugin.ear.EarMojoTest.testProject038(EarMojoTest.java:411)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
> Caused by: org.apache.maven.it.util.cli.CommandLineException: Error while
> executing process.
> at
> org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:737)
> at
> org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:101)
> at
> org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:87)
> at org.apache.maven.it.Verifier.executeGoals(Verifier.java:901)
> ... 23 more
> Caused by: java.io.IOException: mvn: not found
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:52)
> at java.lang.ProcessImpl.start(ProcessImpl.java:91)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
> at java.lang.Runtime.exec(Runtime.java:591)
> at
> org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:732)
> ... 26 more
> {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: (MVERIFIER-5) mvn not found when invoking the verifier from IDEA
[
http://jira.codehaus.org/browse/MVERIFIER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90952
]
Stephane Nicoll commented on MVERIFIER-5:
-
The environment passe to Runtime.getRuntime does not contain the actual PATH
variable.
{noformat}
PATH=/usr/bin:/bin:/usr/sbin:/sbin
{noformat}
My bash shell gives the following:
{noformat}
cobra:~/projects/maven-shared/maven-verifier snicoll$ echo $PATH
/bin:/sbin:/usr/bin:/usr/sbin:/opt/local/bin:/opt/tools/maven/bin:/opt/tools/ant/bin
{noformat}
> mvn not found when invoking the verifier from IDEA
> --
>
> Key: MVERIFIER-5
> URL: http://jira.codehaus.org/browse/MVERIFIER-5
> Project: Maven 2.x Verifier Plugin
> Issue Type: Bug
> Environment: MacOsX
>Reporter: Stephane Nicoll
>
> When i use the verifier in Intellij IDEA, the verifier is unable to find mvn
> in the path. I don't have the problem on Linux/Windows XP.
> The path is set properly
> {noformat}
> org.apache.maven.it.VerificationException:
> org.apache.maven.it.util.cli.CommandLineException: Error while executing
> process.
> at org.apache.maven.it.Verifier.executeGoals(Verifier.java:907)
> at org.apache.maven.it.Verifier.executeGoal(Verifier.java:780)
> at org.apache.maven.it.Verifier.executeGoal(Verifier.java:774)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:84)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:114)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:132)
> at
> org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:161)
> at
> org.apache.maven.plugin.ear.EarMojoTest.testProject038(EarMojoTest.java:411)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
> Caused by: org.apache.maven.it.util.cli.CommandLineException: Error while
> executing process.
> at
> org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:737)
> at
> org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:101)
> at
> org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:87)
> at org.apache.maven.it.Verifier.executeGoals(Verifier.java:901)
> ... 23 more
> Caused by: java.io.IOException: mvn: not found
> at java.lang.UNIXProcess.forkAndExec(Native Method)
> at java.lang.UNIXProcess.(UNIXProcess.java:52)
> at java.lang.ProcessImpl.start(ProcessImpl.java:91)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
> at java.lang.Runtime.exec(Runtime.java:591)
> at
> org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:732)
> ... 26 more
> {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] Created: (MVERIFIER-5) mvn not found when invoking the verifier from IDEA
mvn not found when invoking the verifier from IDEA
--
Key: MVERIFIER-5
URL: http://jira.codehaus.org/browse/MVERIFIER-5
Project: Maven 2.x Verifier Plugin
Issue Type: Bug
Environment: MacOsX
Reporter: Stephane Nicoll
When i use the verifier in Intellij IDEA, the verifier is unable to find mvn in
the path. I don't have the problem on Linux/Windows XP.
The path is set properly
{noformat}
org.apache.maven.it.VerificationException:
org.apache.maven.it.util.cli.CommandLineException: Error while executing
process.
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:907)
at org.apache.maven.it.Verifier.executeGoal(Verifier.java:780)
at org.apache.maven.it.Verifier.executeGoal(Verifier.java:774)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:84)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.executeMojo(AbstractEarPluginTestCase.java:114)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:132)
at
org.apache.maven.plugin.ear.AbstractEarPluginTestCase.doTestProject(AbstractEarPluginTestCase.java:161)
at
org.apache.maven.plugin.ear.EarMojoTest.testProject038(EarMojoTest.java:411)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40)
Caused by: org.apache.maven.it.util.cli.CommandLineException: Error while
executing process.
at
org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:737)
at
org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:101)
at
org.apache.maven.it.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:87)
at org.apache.maven.it.Verifier.executeGoals(Verifier.java:901)
... 23 more
Caused by: java.io.IOException: mvn: not found
at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:52)
at java.lang.ProcessImpl.start(ProcessImpl.java:91)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:451)
at java.lang.Runtime.exec(Runtime.java:591)
at
org.apache.maven.it.util.cli.Commandline.execute(Commandline.java:732)
... 26 more
{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: (MEAR-59) Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_90948 ] Stephane Nicoll commented on MEAR-59: - However, you will have to specify explicitely. If they are two candidates, you have to explicitly state that you want the main artifact (still need to be validated though) > Ear plugin fails to resolve artifact with null classifier when equivalent, > classified artifact exists > - > > Key: MEAR-59 > URL: http://jira.codehaus.org/browse/MEAR-59 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Chris Tucker > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > Attachments: MPEAR-48-maven-ear-plugin.patch > > > When resolving ear modules the AbstractEarModule.java class requests a unique > artifact from the artifact repository using getUniqueArtifact(groupId, > artifactId, type, classifier). In the case where the classifier is null > getUniqueArtifact will attempt to find an artifact without considering the > classifier -- it will match *any* artifact with the same groupId, artifactId, > and type, regardless of whether the classifier matches (is null). Currently > the logic in AbstractEarModule does not handle the case where the classifier > is null: if there is one artifact without a classifier (the one we're looking > for) and another with a classifier (e.g. a clover jar) the ear module will > throw an exception at line 104 stating that a classifier is required. This > means that any build that builds, for example, an instrumented jar, will fail > to construct an ear. > This is fixed in the attached patch by explicitly iterating the set of > artifacts that matches a call to getArtifacts() on the artifact repository > with just the group, artifact, and type. Ideally this patch would instead be > made to ArtifactRepository itself to include a search that explicitly matches > null classifiers. -- 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: (MEAR-59) Ear plugin fails to resolve artifact with null classifier when equivalent, classified artifact exists
[ http://jira.codehaus.org/browse/MEAR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-59: Fix Version/s: 2.3.1 OK. I have reproduced the issue. > Ear plugin fails to resolve artifact with null classifier when equivalent, > classified artifact exists > - > > Key: MEAR-59 > URL: http://jira.codehaus.org/browse/MEAR-59 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Reporter: Chris Tucker > Assigned To: Stephane Nicoll > Fix For: 2.3.1 > > Attachments: MPEAR-48-maven-ear-plugin.patch > > > When resolving ear modules the AbstractEarModule.java class requests a unique > artifact from the artifact repository using getUniqueArtifact(groupId, > artifactId, type, classifier). In the case where the classifier is null > getUniqueArtifact will attempt to find an artifact without considering the > classifier -- it will match *any* artifact with the same groupId, artifactId, > and type, regardless of whether the classifier matches (is null). Currently > the logic in AbstractEarModule does not handle the case where the classifier > is null: if there is one artifact without a classifier (the one we're looking > for) and another with a classifier (e.g. a clover jar) the ear module will > throw an exception at line 104 stating that a classifier is required. This > means that any build that builds, for example, an instrumented jar, will fail > to construct an ear. > This is fixed in the attached patch by explicitly iterating the set of > artifacts that matches a call to getArtifacts() on the artifact repository > with just the group, artifact, and type. Ideally this patch would instead be > made to ArtifactRepository itself to include a search that explicitly matches > null classifiers. -- 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: (MCLOVER-67) Remove deprecated licenseFile configuration parameter
[ http://jira.codehaus.org/browse/MCLOVER-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol closed MCLOVER-67. - Resolution: Fixed Done > Remove deprecated licenseFile configuration parameter > - > > Key: MCLOVER-67 > URL: http://jira.codehaus.org/browse/MCLOVER-67 > Project: Maven 2.x Clover Plugin > Issue Type: Task >Affects Versions: 2.3 >Reporter: Vincent Massol > Assigned To: Vincent Massol > Fix For: 2.4 > > > It's been deprecated since 2.1. Time to remove it and reduce our code > clutter... -- 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: (MCLOVER-66) The report goal doesn't support a user-provided Clover license
[ http://jira.codehaus.org/browse/MCLOVER-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Massol closed MCLOVER-66. - Resolution: Fixed Fixed > The report goal doesn't support a user-provided Clover license > -- > > Key: MCLOVER-66 > URL: http://jira.codehaus.org/browse/MCLOVER-66 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Vincent Massol > Assigned To: Vincent Massol > Fix For: 2.4 > > > See http://www.cenqua.com/forums/thread.jspa?threadID=2796&tstart=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] Created: (MCLOVER-67) Remove deprecated licenseFile configuration parameter
Remove deprecated licenseFile configuration parameter - Key: MCLOVER-67 URL: http://jira.codehaus.org/browse/MCLOVER-67 Project: Maven 2.x Clover Plugin Issue Type: Task Affects Versions: 2.3 Reporter: Vincent Massol Assigned To: Vincent Massol Fix For: 2.4 It's been deprecated since 2.1. Time to remove it and reduce our code clutter... -- 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: (MCLOVER-66) The report goal doesn't support a user-provided Clover license
The report goal doesn't support a user-provided Clover license -- Key: MCLOVER-66 URL: http://jira.codehaus.org/browse/MCLOVER-66 Project: Maven 2.x Clover Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Vincent Massol Assigned To: Vincent Massol Fix For: 2.4 See http://www.cenqua.com/forums/thread.jspa?threadID=2796&tstart=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
