[jira] (WAGON-380) webdav wagon 1.6 requires
[ https://jira.codehaus.org/browse/WAGON-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-380. -- Resolution: Fixed Fix Version/s: 2.3 Assignee: Olivier Lamy > webdav wagon 1.6 requires > - > > Key: WAGON-380 > URL: https://jira.codehaus.org/browse/WAGON-380 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-webdav >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.3 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (WAGON-380) webdav wagon 1.6 requires
Olivier Lamy created WAGON-380: -- Summary: webdav wagon 1.6 requires Key: WAGON-380 URL: https://jira.codehaus.org/browse/WAGON-380 Project: Maven Wagon Issue Type: Improvement Components: wagon-webdav Reporter: Olivier Lamy -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
Christian Schlichtherle created MSITE-662: - Summary: jetty listens on port 0 Key: MSITE-662 URL: https://jira.codehaus.org/browse/MSITE-662 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: site:run Affects Versions: 3.2 Reporter: Christian Schlichtherle site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty reports to listen on socket 0 (!). This doesn't work, although Jetty silently accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312475#comment-312475 ] Anders Hammar commented on MSITE-662: - What environment? Maven version, os, and Java version. Java 7 by any chance? > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312476#comment-312476 ] Christian Schlichtherle commented on MSITE-662: --- I use Mac OS X, Oracle JDK 7u9, Maven 3.0.4 (with maven-site-plugin 3.2 obviously). I have a large multi-module project and when switching from 3.1 to 3.2 then mvm site:run makes Jetty listen on port 0. I wonder that it accepts it anyhow. > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312477#comment-312477 ] Anders Hammar commented on MSITE-662: - OK, not sure it's the case here but Java 7 uses IPv6 by default instead of v4. Could you try the workaround on https://cwiki.apache.org/MAVEN/connectexception.html to have it use IPv4 instead and see if that fixes your issue? > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312479#comment-312479 ] Christian Schlichtherle commented on MSITE-662: --- As said, the goal consistently works with version 3.1 of the maven-site-plugin and it consistently fails with version 3.2, so there's no point to mess with the configuration. > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312480#comment-312480 ] Anders Hammar commented on MSITE-662: - No point? I'm providing you with information that might help you with a workaround and you think there's no idea trying it out? > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-662) jetty listens on port 0
[ https://jira.codehaus.org/browse/MSITE-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312481#comment-312481 ] Christian Schlichtherle commented on MSITE-662: --- Thanks for the tip, but at this point I'm not interested in a workaround. I reported this issue so a maintainer can fix it. > jetty listens on port 0 > --- > > Key: MSITE-662 > URL: https://jira.codehaus.org/browse/MSITE-662 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:run >Affects Versions: 3.2 >Reporter: Christian Schlichtherle > > site:run doesn't work since version 3.2 of the plugin. When I use it, Jetty > reports to listen on socket 0 (!). This doesn't work, although Jetty silently > accepts it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-98) dependency:unpack: The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy reassigned MDEP-98:
-
Assignee: (was: Brian Fox)
> dependency:unpack: The source must not be a directory
> -
>
> Key: MDEP-98
> URL: https://jira.codehaus.org/browse/MDEP-98
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 2.0-alpha-4
> Environment: Windows XP Professional SP2
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
>Reporter: Pablo Muñiz
> Attachments: MDEP-98-ITs.patch,
> mdep98-testcase-parent-with-surefire.zip, mdep98-testcase-parent.zip
>
>
> Using maven-dependency-plugin in a multimodule project inside a module wich
> has a dependency with another module in the same project the next error
> ocurrs :
> {noformat}org.codehaus.plexus.archiver.ArchiverException: The source must not
> be a directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.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)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error unpacking file:
> c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to:
> c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.{noformat}
> Project structure is as follows:
> plataforma
> - platform-core
> - platform-bundle
> - platform-bundle-jar
> - platform-bundle-src
> and the error happens on executing any goal from parent pom.
> maven-dependency-plugin seems to receive a reference to target/classes
> directory for platform-core dependency instead of the URL to my local
> repository where platform-core is located.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-187) dependency:copy fails when invoked from m2e with workspace resolution enabled
[ https://jira.codehaus.org/browse/MDEP-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy reassigned MDEP-187: -- Assignee: (was: Brian Fox) > dependency:copy fails when invoked from m2e with workspace resolution enabled > - > > Key: MDEP-187 > URL: https://jira.codehaus.org/browse/MDEP-187 > Project: Maven 2.x Dependency Plugin > Issue Type: Bug > Components: copy, copy-dependencies >Affects Versions: 2.1 >Reporter: Igor Fedorenko > Attachments: MDEP-187b.diff, MDEP-187c.diff, MDEP-187.diff > > > m2e resolves workspace artifacts to their output folders but dependency:copy > expects all artifacts to be files. I will provide trivial patch shortly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-98) dependency:unpack: The source must not be a directory
[
https://jira.codehaus.org/browse/MDEP-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy updated MDEP-98:
--
Summary: dependency:unpack: The source must not be a directory (was: The
source must not be a directory)
> dependency:unpack: The source must not be a directory
> -
>
> Key: MDEP-98
> URL: https://jira.codehaus.org/browse/MDEP-98
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack, unpack-dependencies
>Affects Versions: 2.0-alpha-4
> Environment: Windows XP Professional SP2
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode, sharing)
>Reporter: Pablo Muñiz
>Assignee: Brian Fox
> Attachments: MDEP-98-ITs.patch,
> mdep98-testcase-parent-with-surefire.zip, mdep98-testcase-parent.zip
>
>
> Using maven-dependency-plugin in a multimodule project inside a module wich
> has a dependency with another module in the same project the next error
> ocurrs :
> {noformat}org.codehaus.plexus.archiver.ArchiverException: The source must not
> be a directory.
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.validate(AbstractUnArchiver.java:98)
> at
> org.codehaus.plexus.archiver.AbstractUnArchiver.extract(AbstractUnArchiver.java:84)
> at
> org.apache.maven.plugin.dependency.AbstractDependencyMojo.unpack(AbstractDependencyMojo.java:232)
> at
> org.apache.maven.plugin.dependency.UnpackDependenciesMojo.execute(UnpackDependenciesMojo.java:72)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.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)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error unpacking file:
> c:\D\desarrollo\proyectos\plataforma\platform-core\target\classes to:
> c:\D\desarrollo\proyectos\plataforma\platform-bundle\platform-bundle-jar\target\classes
> org.codehaus.plexus.archiver.ArchiverException: The source must not be a
> directory.{noformat}
> Project structure is as follows:
> plataforma
> - platform-core
> - platform-bundle
> - platform-bundle-jar
> - platform-bundle-src
> and the error happens on executing any goal from parent pom.
> maven-dependency-plugin seems to receive a reference to target/classes
> directory for platform-core dependency instead of the URL to my local
> repository where platform-core is located.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MDEP-303) [REGRESSION] dependency:list output not sorted
[
https://jira.codehaus.org/browse/MDEP-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MDEP-303.
--
Resolution: Not A Bug
Assignee: Herve Boutemy
yes, it's by design: dependency order is important for classpath
sorting it is generally a bad idea
if you really want such feature, you can ask for a new parameter that will sort
before printing: please open a Jira issue (patch welcome: this shouldn't be
hard to code)
> [REGRESSION] dependency:list output not sorted
> --
>
> Key: MDEP-303
> URL: https://jira.codehaus.org/browse/MDEP-303
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Vista x64 / Maven 3.0.2 / Java6u24
>Reporter: André Fügenschuh
>Assignee: Herve Boutemy
>Priority: Minor
>
> {{dependency:list}} output is no longer sorted (alphabetical order) - by
> design or a bug?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-38) Enable RAT to help us get maven releases to be license-header compliant
[ https://issues.apache.org/jira/browse/MPOM-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MPOM-38: -- Issue Type: New Feature (was: Bug) > Enable RAT to help us get maven releases to be license-header compliant > --- > > Key: MPOM-38 > URL: https://issues.apache.org/jira/browse/MPOM-38 > Project: Maven POMs > Issue Type: New Feature > Components: maven >Affects Versions: MAVEN-21 >Reporter: Benson Margulies >Assignee: Benson Margulies > Fix For: MAVEN-23 > > Attachments: MPOM-38.diff > > > We should run rat, at least in report mode, to help us get releases into > compliance. > While I am here, I propose to 'useReleaseProfiles' when running the > maven-release-plugin. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-371) Converting line endings corrupts ISO-8859-1 files when platform encoding is UTF-8
[ https://jira.codehaus.org/browse/MASSEMBLY-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-371. - Resolution: Fixed Fix Version/s: 2.4 Assignee: Dennis Lundberg Fixed in [r1402965|http://svn.apache.org/viewvc?view=revision&revision=1402965]. > Converting line endings corrupts ISO-8859-1 files when platform encoding is > UTF-8 > - > > Key: MASSEMBLY-371 > URL: https://jira.codehaus.org/browse/MASSEMBLY-371 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-2, 2.2 > Environment: Linux with platform encoding set to UTF-8 >Reporter: Håvard Wigtil >Assignee: Dennis Lundberg > Fix For: 2.4 > > Attachments: assembly-encoding.zip > > > Converting line endings for a text file encoded in ISO-8859-1 replaces any > character in the set above ASCII with the three characters ï¿. > What happens is that the file to be converted is read as text in the platform > encoding (seems to be method readFile in class FileFormatter), and when the > platform encoding is UTF-8, any non-ASCII character from ISO-8859-1 is > converted to the UTF-8 character "�" (i.e. the placeholder for unknown > / broken character). > I've attached a small sample project that shows this problem on Linux with > platform encoding set to UTF-8. > I see two possible fixes for this, one is to read the file as bytes and do a > search /replace for line endings, and the other is to be able to specify > encoding for a fileset or file. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-126) mavenHome in relationship with invoker.maven.version rule
[ https://jira.codehaus.org/browse/MINVOKER-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312486#comment-312486 ] Robert Scholte commented on MINVOKER-126: - Added the ability to get the version based on the MavenHome in [r1402983|http://svn.apache.org/viewvc?rev=1402983&view=rev]. I've seen it working on my Win7 machine with M2.2.1 and M3.0.1, so this looks promising. Next step requires some refactoring of the original code, since it calculates this value for every buildjob, which is way too expensive in my opinion. > mavenHome in relationship with invoker.maven.version rule > - > > Key: MINVOKER-126 > URL: https://jira.codehaus.org/browse/MINVOKER-126 > Project: Maven 2.x Invoker Plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Karl Heinz Marbaise > > I've set up mavenHome in my POM to use Maven 2.2.1 but i have set a rule > (invoker.maven.version = 2.2.0+, !3.0.0+) but the integration test is skipped > anyway. > An assumtion of Rober Scholte was that invoker.maven.version works only for > the executing Maven version which looks like. This results in two choices: > either this is a bug or it should be clearly documented for the > invoker.maven.version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-126) mavenHome in relationship with invoker.maven.version rule
[ https://jira.codehaus.org/browse/MINVOKER-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MINVOKER-126. --- Resolution: Fixed Fix Version/s: 1.8 Assignee: Robert Scholte Fixed in [r1402995|http://svn.apache.org/viewvc?rev=1402995&view=rev] > mavenHome in relationship with invoker.maven.version rule > - > > Key: MINVOKER-126 > URL: https://jira.codehaus.org/browse/MINVOKER-126 > Project: Maven 2.x Invoker Plugin > Issue Type: Bug >Affects Versions: 1.5 >Reporter: Karl Heinz Marbaise >Assignee: Robert Scholte > Fix For: 1.8 > > > I've set up mavenHome in my POM to use Maven 2.2.1 but i have set a rule > (invoker.maven.version = 2.2.0+, !3.0.0+) but the integration test is skipped > anyway. > An assumtion of Rober Scholte was that invoker.maven.version works only for > the executing Maven version which looks like. This results in two choices: > either this is a bug or it should be clearly documented for the > invoker.maven.version -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-106) invoker.java.version is always evaluated against current JVM instead of JVM running the builds
[
https://jira.codehaus.org/browse/MINVOKER-106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312488#comment-312488
]
Robert Scholte commented on MINVOKER-106:
-
One way to figure it out is by calling {java.home}/bin/java -version and parse
the output, but I'm not sure if this is vendor specific.
> invoker.java.version is always evaluated against current JVM instead of JVM
> running the builds
> --
>
> Key: MINVOKER-106
> URL: https://jira.codehaus.org/browse/MINVOKER-106
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Benjamin Bentmann
>Priority: Minor
>
> The selector condition for the JVM version always looks at the current JVM,
> not the JVM that will be used to run the forked builds. This gets only
> obvious when using invoker.javaHome to point at a different JVM than the one
> running the Invoker Plugin.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-590) Upgrade plexus dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MASSEMBLY-590.
-
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Kristian Rosenvold
Fixed in [r1235501|http://svn.apache.org/viewvc?view=revision&revision=1235501].
> Upgrade plexus dependencies
> ---
>
> Key: MASSEMBLY-590
> URL: https://jira.codehaus.org/browse/MASSEMBLY-590
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Reporter: Odd Vinje
>Assignee: Kristian Rosenvold
> Fix For: 2.3
>
> Attachments: MASSEMBLY-590.diff
>
>
> The plexus dependencies used internally are outdated. There are major issues
> with plexus-io version 1.x (one example:
> http://jira.codehaus.org/browse/PLXCOMP-149)
> The assembly plugin uses plexus-io 1.0.1, but the latest is 2.0.1.
> {code}
> [INFO] --- maven-assembly-plugin:2.2.1:single (attach-artifacts) ---
> [DEBUG]org.codehaus.plexus:plexus-io:jar:1.0.1:compile
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-564) [PATCH] Migration from obsolete plexus-maven-plugin to plexus-containers-component-metadata
[ https://jira.codehaus.org/browse/MASSEMBLY-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MASSEMBLY-564. - Resolution: Fixed Fix Version/s: 2.2.2 Assignee: John Casey This was fixed in [r1163853|https://svn.apache.org/viewvc?view=revision&revision=1163853] > [PATCH] Migration from obsolete plexus-maven-plugin to > plexus-containers-component-metadata > --- > > Key: MASSEMBLY-564 > URL: https://jira.codehaus.org/browse/MASSEMBLY-564 > Project: Maven 2.x Assembly Plugin > Issue Type: Improvement >Affects Versions: 2.2.1 > Environment: Fedora Rawhide >Reporter: Jaromír Cápík >Assignee: John Casey > Fix For: 2.2.2 > > Attachments: > maven-assembly-plugin-migration-to-component-metadata.patch > > > The attached patch retires the obsolete plexus-maven-plugin and generates the > metadata with plexus-containers-component-metadata instead. > NOTE : The result XML file has a different order of elements, but all of them > are present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-771) release:prepare tries to push tag with invalid Git URL
[
https://jira.codehaus.org/browse/MRELEASE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312491#comment-312491
]
Andreas Lüdeke commented on MRELEASE-771:
-
i was able to reproduce this issue in our setup. I was able to workaround it by
moving the aggregator pom into the root of my project structure. Before that
the aggregator pom was placed in a sub folder of our project structure.
> release:prepare tries to push tag with invalid Git URL
> --
>
> Key: MRELEASE-771
> URL: https://jira.codehaus.org/browse/MRELEASE-771
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare, scm
>Affects Versions: 2.3.1
> Environment: Debian 6, run form shell
>Reporter: Tuukka Mustonen
>
> Suddenly, after no version change of maven-release-plugin, our
> {{release:prepare}} started to fail into:
> {noformat}
> [INFO] Unable to tag SCM
> Provider message:
> The git-push command failed.
> Command output:
> ssh: Could not resolve hostname : Name or service not known
> fatal: The remote end hung up unexpectedly
> {noformat}
> The reason appears to be that pushing of the tag uses invalid syntax for git
> command:
> {noformat}
> [INFO] Executing: /bin/sh -c cd "/jenkins/job1" && git push
> ssh://g...@github.mydomain.com myproduct-1.0.0
> {noformat}
> The problem here is that the target URL ({{ssh://g...@github.mydomain.com}})
> is lacking the actual repository identifier
> ({{/MyOrganization/myproduct.git}}) - the plugin is using just
> {{ssh://g...@github.mydomain.com}} while it should be using something like
> {{ssh://g...@github.mydomain.com/MyOrganization/myproduct.git}}.
> I cannot come up with a reason why it started to do this so I cannot give
> instructions on to how to reproduce it either. For us, it occurs in one
> repository, while in another one using the same plugin version and
> configuration the problem doesn't occur.
> Apparently the behavior of using ssh-URL instead of {{origin}} as remote
> repository has been there for ages, added in SCM-498.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-613) assembly.xml in final build
[
https://jira.codehaus.org/browse/MASSEMBLY-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-613:
--
Description:
See
http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
It says:Your assembly descriptors MUST be in the directory
/src/main/resources/assemblies to be available to the Assembly Plugin.
I did.
I run "mvn clean package assembly:single"
And now I have a assemblies.xml in my jar.
here my assemblies file (pretty much default):
{code:xml}
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
final
true
zip
${project.build.outputDirectory}
/
runtime
true
/lib
{code}
was:
See
http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
It says:Your assembly descriptors MUST be in the directory
/src/main/resources/assemblies to be available to the Assembly Plugin.
I did.
I run "mvn clean package assembly:single"
And now I have a assemblies.xml in my jar.
here my assemblies file (pretty much default):
http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
final
true
zip
${project.build.outputDirectory}
/
runtime
true
/lib
> assembly.xml in final build
> ---
>
> Key: MASSEMBLY-613
> URL: https://jira.codehaus.org/browse/MASSEMBLY-613
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Reporter: jacques
>
> See
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
> It says:Your assembly descriptors MUST be in the directory
> /src/main/resources/assemblies to be available to the Assembly Plugin.
> I did.
> I run "mvn clean package assembly:single"
> And now I have a assemblies.xml in my jar.
> here my assemblies file (pretty much default):
> {code:xml}
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> final
> true
>
> zip
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
>
> runtime
> true
> /lib
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-613) assembly.xml in final build
[
https://jira.codehaus.org/browse/MASSEMBLY-613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312492#comment-312492
]
Dennis Lundberg commented on MASSEMBLY-613:
---
What are you trying to do?
What went wrong?
What did you expect to happen?
The page about shared descriptors talks about having a separate project for
your shared descriptors. It is not a recipe you can follow if you have your
assembly descriptor in the same project that is going to use the descriptor.
> assembly.xml in final build
> ---
>
> Key: MASSEMBLY-613
> URL: https://jira.codehaus.org/browse/MASSEMBLY-613
> Project: Maven 2.x Assembly Plugin
> Issue Type: Improvement
>Reporter: jacques
>
> See
> http://maven.apache.org/plugins/maven-assembly-plugin/examples/sharing-descriptors.html
> It says:Your assembly descriptors MUST be in the directory
> /src/main/resources/assemblies to be available to the Assembly Plugin.
> I did.
> I run "mvn clean package assembly:single"
> And now I have a assemblies.xml in my jar.
> here my assemblies file (pretty much default):
> {code:xml}
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.2
> http://maven.apache.org/xsd/assembly-1.1.2.xsd";>
> final
> true
>
> zip
>
>
>
> ${project.build.outputDirectory}
> /
>
>
>
>
> runtime
> true
> /lib
>
>
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-607) Wildcard in dependencySet/includes doesn't match artifact with empty classifier
[
https://jira.codehaus.org/browse/MASSEMBLY-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312493#comment-312493
]
Dennis Lundberg commented on MASSEMBLY-607:
---
I can confirm this.
As a work-around you might be able to use this pattern, which seems to include
artifacts with or without a classifier.
{code:xml}
com.mycompany.*:*:jar:*
{code}
> Wildcard in dependencySet/includes doesn't match artifact with empty
> classifier
> ---
>
> Key: MASSEMBLY-607
> URL: https://jira.codehaus.org/browse/MASSEMBLY-607
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.3
> Environment: Windows 7/Maven 3.0.03
>Reporter: Alexander Kormushin
>
> Following dependency set will match only my jar artifacts with any non-empty
> classifier:
> {code}
>
>
> com.mycompany.*:*:jar:*:*
>
>
> {code}
> But it seems wildcard should include empty ones.
> Here is the related code fragment:
> {code:title=.m2\repository\org\apache\maven\shared\maven-common-artifact-filters\1.4\maven-common-artifact-filters-1.4.jar!\org\apache\maven\shared\artifact\filter\PatternIncludesArtifactFilter.class}
> 172private boolean matchAgainst( final String value, final List patterns,
> final boolean regionMatch )
> 181// fail immediately if pattern tokens outnumber tokens to match
> 182boolean matched = ( patternTokens.length <= tokens.length );
> {code}
> I have following values achieving 182 line:
> pattern=[com.mycompany.*, *, jar, *, *]
> tokens=[com.mycompany, myproject, jar, 1.0.0-SNAPSHOT]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-916) surefire.junit4.upgradecheck fails with ClassCastException: java.lang.Class cannot be cast to java.lang.String
Peter Lynch created SUREFIRE-916:
Summary: surefire.junit4.upgradecheck fails with
ClassCastException: java.lang.Class cannot be cast to java.lang.String
Key: SUREFIRE-916
URL: https://jira.codehaus.org/browse/SUREFIRE-916
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.12.4
Reporter: Peter Lynch
Attachments:
fix_surefire_junit4_upgradecheck_to_not_fail_with_ClassCastException1.patch
I specified {{-Dsurefire.junit4.upgradecheck}} on a project which had at least
one class found to be affected by the check.
Instead of reporting the affected classes, the check fails with
{noformat}
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to
java.lang.String
at
org.apache.maven.surefire.junit4.JUnit4Provider.upgradeCheck(JUnit4Provider.java:211)
at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:95)
... 9 more
{noformat}
Attached patch fixes the problem.
Method was private and was 'unsupported' feature meant to eventually go away so
didn't file a test, but I think the code is pretty obvious.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MASSEMBLY-96) using fileSet -> lineEnding will always put the selected lineEnding at the end of the file, even if the original file does not end in one
[
https://jira.codehaus.org/browse/MASSEMBLY-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MASSEMBLY-96.
Resolution: Fixed
Fix Version/s: 2.4
Assignee: Dennis Lundberg
Fixed in [r1403107|http://svn.apache.org/viewvc?view=revision&revision=1403107].
> using fileSet -> lineEnding will always put the selected lineEnding at the
> end of the file, even if the original file does not end in one
> -
>
> Key: MASSEMBLY-96
> URL: https://jira.codehaus.org/browse/MASSEMBLY-96
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Edwin Punzalan
>Assignee: Dennis Lundberg
> Fix For: 2.4
>
>
> example
> Original File:
> {code}
> first line\r\n
> second line
> {code}
> New File:
> {code}
> first line\n
> second line\n
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-118) Specifying an unset property in causes a NullPointerException
[
https://jira.codehaus.org/browse/MINVOKER-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MINVOKER-118.
---
Resolution: Fixed
Fix Version/s: 1.8
Assignee: Robert Scholte
Fixed in [r1403115|http://svn.apache.org/viewvc?rev=1403115&view=rev]
> Specifying an unset property in causes a NullPointerException
> --
>
> Key: MINVOKER-118
> URL: https://jira.codehaus.org/browse/MINVOKER-118
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: Maven 3.0.2
>Reporter: Derek Lewis
>Assignee: Robert Scholte
> Fix For: 1.8
>
> Attachments: maven-invoker-plugin-bug.zip
>
>
> When the invoker plugin is configured with a property as follows:
> {code:xml}
>
> ${example.property}
>
> {code}
> If {{example.property}} is not set, the plugin throws a
> {{NullPointerException}}:
> {noformat}
> Caused by: java.lang.NullPointerException
> at java.util.Hashtable.put(Hashtable.java:394)
> at java.util.Hashtable.putAll(Hashtable.java:466)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.getSystemProperties(AbstractInvokerMojo.java:1413)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1307)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuild(AbstractInvokerMojo.java:1048)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.runBuilds(AbstractInvokerMojo.java:974)
> at
> org.apache.maven.plugin.invoker.AbstractInvokerMojo.execute(AbstractInvokerMojo.java:626)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> {noformat}
> I would expect it to either set {{some.property}} to "${example.property}" or
> an empty string.
> The attached testcase has two profiles, profile-with-value and
> profile-with-empty-value. With profile-with-value activated, mvn package
> passes. With profile-with-empty-value, or no profile activated, {{mvn
> package}} will fail with the {{NullPointerException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4099) Password encryption CLI switches should prompt for password if missing
[ https://jira.codehaus.org/browse/MNG-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=312502#comment-312502 ] Knut Vidar Siem commented on MNG-4099: -- As far as I can tell, the password collection is implemented in [org.apache.maven.cli.MavenCli#encryption(CliRequest)|http://maven.apache.org/ref/3.0.4/maven-embedder/xref/org/apache/maven/cli/MavenCli.html#483] using [commons-cli|http://commons.apache.org/cli/]. A straight-forward implementation prompting for the password while not echoing it would be to use [java.io.Console#readPassword()|http://docs.oracle.com/javase/6/docs/api/java/io/Console.html#readPassword()] from JDK6 if possible. Suggested pre-JDK6 solutions seem surprisingly complex, such as [concurrently sending backspace characters|http://web.archive.org/web/20110604072946/http://java.sun.com/developer/technicalArticles/Security/pwordmask/], or non-portable (JNI). There is a comment in the code suggesting that this functionality should be moved to a separate tool. Why is that and what kind of tool would that be, a plugin or a completely separate utility? > Password encryption CLI switches should prompt for password if missing > -- > > Key: MNG-4099 > URL: https://jira.codehaus.org/browse/MNG-4099 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.1.0 >Reporter: Mark Hobson >Priority: Trivial > Fix For: 3.x / Backlog > > > The -emp and -ep CLI switches should prompt for a password if the user omits > it. This would help to avoid having to escape shell characters in strong > passwords. > Note that the docs mention that these switches prompt for a password when > they do not: > http://maven.apache.org/guides/mini/guide-encryption.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINVOKER-138) Add groovy-all dependency instead of groovy by default
[ https://jira.codehaus.org/browse/MINVOKER-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MINVOKER-138: --- Assignee: Robert Scholte > Add groovy-all dependency instead of groovy by default > -- > > Key: MINVOKER-138 > URL: https://jira.codehaus.org/browse/MINVOKER-138 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Affects Versions: 1.7 >Reporter: Robert Scholte >Assignee: Robert Scholte >Priority: Minor > Fix For: 1.8 > > > With the upgrade to groovy-2+ we've lost the XmlSlurper and other xml related > classes. By adding the groovy-all dependency by default we also get the > classes of groovy-xml so we shouldn't notice the difference between > maven-invoker-plugin 1.6 and 1.8 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-917) [junit] category simple name matching fails throwing ClassNotFoundException
Peter Lynch created SUREFIRE-917:
Summary: [junit] category simple name matching fails throwing
ClassNotFoundException
Key: SUREFIRE-917
URL: https://jira.codehaus.org/browse/SUREFIRE-917
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.x support
Affects Versions: 2.12.4
Reporter: Peter Lynch
Attachments: fix_support_for_junit_simple_group_name_matching.patch
According to a [unit test I
found|https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-grouper/src/test/java/org/apache/maven/surefire/group/parse/GroupMatcherParserTest.java;h=e92595a09de1eb706f54c70b8efe8df592e40ec5;hb=HEAD#l134]
JUnit categories/group support should allow matching groups by the category
interface simple name along with the fully qualified name.
Example , given category interfaces:
{noformat}
category.Fast
category.Slow
{noformat}
The following commands should be equivalent:
{noformat}
mvn test -Dgroups="Slow,Fast"
mvn test -Dgroups="category.Slow,category.Fast"
mvn test -Dgroups="category.Slow.class,category.Fast.class"
{noformat}
In my testing, the first command does not work. Instead I get the following
exception:
{noformat}
org.apache.maven.surefire.util.SurefireReflectionException:
java.lang.reflect.InvocationTargetException; nested exception is
java.lang.reflect.InvocationTargetException: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.RuntimeException: Unable to load category: Fast
at
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:134)
at
org.apache.maven.surefire.group.match.JoinGroupMatcher.loadGroupClasses(JoinGroupMatcher.java:44)
at
org.apache.maven.surefire.common.junit48.FilterFactory.createGroupFilter(FilterFactory.java:92)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.createJUnit48Filter(JUnitCoreProvider.java:183)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:115)
... 9 more
Caused by: java.lang.ClassNotFoundException: Fast
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.apache.maven.surefire.group.match.SingleGroupMatcher.loadGroupClasses(SingleGroupMatcher.java:130)
... 13 more
{noformat}
It seems like if a category name cannot be loaded, it should just be ignored.
I added an integration test that proves the failure and supplied a patch which
avoids the problem to allow specifying the simple class name for matching.
It would be great to have this working to allow a developer to easily run
specific groups of tests in a concise manner.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
