[jira] Created: (MRELEASE-714) Prevent snapshot version bumping does not seem to work
Prevent snapshot version bumping does not seem to work -- Key: MRELEASE-714 URL: https://jira.codehaus.org/browse/MRELEASE-714 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.2.1 Reporter: Paul S I want to use the release plugin within our company, and I want to create a tags for multi-module projects, such as the following example: tags/parent-1.0.0 - child1 (1.0.0) - child2 (1.0.0) When I do "release: prepare", snapshots with an increased version are created and committed for every parent/child module, so: parent-1.0.0-SNAPSHOT, child1-1.0.0-SNAPSHOT, child2-1.0.0-SNAPSHOT becomes: parent-1.0.1-SNAPSHOT, child1-1.0.1-SNAPSHOT, child2-1.0.1-SNAPSHOT However, when I create a release I don't want to automatically create snapshot versions for every child module, so I'd like to bump the version number to 1.0.1-SNAPSHOT manually. Sometimes we create a new release in which for instance 3 of the 10 child modules have actually been updated, so we want to just set those 3 version numbers to an increased SNAPSHOT version. I tried accomplishing this by setting the following properties to false: false false However, whatever I try, it doesn't work. The 1.0.0-SNAPSHOT versions keep getting bumped to 1.0.1-SNAPSHOT. Furthermore, a little off topic, but is it possible to have version numbers created for sub modules? E.g.: tags/parent-1.0.0 - child1-1.0.0 - child2-1.0.0) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-331) Add to purge-local-repository goal ability to clean only snapshots
Add to purge-local-repository goal ability to clean only snapshots -- Key: MDEP-331 URL: https://jira.codehaus.org/browse/MDEP-331 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Components: purge-local-repository Affects Versions: 2.3 Environment: win32,unix Reporter: Hrabur Trndafilov Assignee: Brian Fox Attachments: snapshots-only.patch Hi, In order to build a pipelined build where the downstream builds use the upstream artifacts we need to clean the SNAPSHOT versions (the downstream depends on) from the local repository and always download them from the internal Maven repository. To achieve this it would be very useful to have possibility to tell purge-local-repositiry goal to clean only the SNAPSHOT dependencies, something like snapshotsOnly parameter. A patch with the fix we use locally is attached. Thanks, Hrabur -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DOXIA-448) Div class attribute replicated to nested h2 element
[
https://jira.codehaus.org/browse/DOXIA-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl updated DOXIA-448:
Component/s: Core
Assignee: Lukas Theussl
> Div class attribute replicated to nested h2 element
> ---
>
> Key: DOXIA-448
> URL: https://jira.codehaus.org/browse/DOXIA-448
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Xdoc
>Reporter: Simone Tripodi
>Assignee: Lukas Theussl
>
> while generating the [Apache DirectMemory
> site|http://incubator.apache.org/directmemory/] using the xdoc format, I
> noticed that for every {{}} element, if {{class}} attribute is
> specified, it is replicated to the nested {{}} element.
> For example, for
> {code}
>
> Apache DirectMemory is a multi layered cache implementation
> featuring off-heap memory management (a-la BigMemory)
>to enable efficient handling of a large number of java objects
> without affecting jvm garbage collection
>performance.
>
> {code}
> Has been rendered as
> {code}
>
> Apache DirectMemory name="Apache_DirectMemory">
> Apache DirectMemory is a multi layered cache implementation
> featuring off-heap memory management (a-la BigMemory)
>to enable efficient handling of a large number of java objects
> without affecting jvm garbage collection
>performance.
>
> {code}
> Of course, depending on the skin, it could cause undesired effects.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-448) Div class attribute replicated to nested h2 element
[
https://jira.codehaus.org/browse/DOXIA-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-448.
---
Resolution: Fixed
Fix Version/s: 1.3
Fixed in [r1185529|http://svn.apache.org/viewvc?view=revision&revision=1185529]
> Div class attribute replicated to nested h2 element
> ---
>
> Key: DOXIA-448
> URL: https://jira.codehaus.org/browse/DOXIA-448
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Xdoc
>Reporter: Simone Tripodi
>Assignee: Lukas Theussl
> Fix For: 1.3
>
>
> while generating the [Apache DirectMemory
> site|http://incubator.apache.org/directmemory/] using the xdoc format, I
> noticed that for every {{}} element, if {{class}} attribute is
> specified, it is replicated to the nested {{}} element.
> For example, for
> {code}
>
> Apache DirectMemory is a multi layered cache implementation
> featuring off-heap memory management (a-la BigMemory)
>to enable efficient handling of a large number of java objects
> without affecting jvm garbage collection
>performance.
>
> {code}
> Has been rendered as
> {code}
>
> Apache DirectMemory name="Apache_DirectMemory">
> Apache DirectMemory is a multi layered cache implementation
> featuring off-heap memory management (a-la BigMemory)
>to enable efficient handling of a large number of java objects
> without affecting jvm garbage collection
>performance.
>
> {code}
> Of course, depending on the skin, it could cause undesired effects.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIA-448) Div class attribute replicated to nested h2 element
[
https://jira.codehaus.org/browse/DOXIA-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281507#comment-281507
]
Simone Tripodi commented on DOXIA-448:
--
Great, thank you Lukas!
> Div class attribute replicated to nested h2 element
> ---
>
> Key: DOXIA-448
> URL: https://jira.codehaus.org/browse/DOXIA-448
> Project: Maven Doxia
> Issue Type: Bug
> Components: Core, Module - Xdoc
>Reporter: Simone Tripodi
>Assignee: Lukas Theussl
> Fix For: 1.3
>
>
> while generating the [Apache DirectMemory
> site|http://incubator.apache.org/directmemory/] using the xdoc format, I
> noticed that for every {{}} element, if {{class}} attribute is
> specified, it is replicated to the nested {{}} element.
> For example, for
> {code}
>
> Apache DirectMemory is a multi layered cache implementation
> featuring off-heap memory management (a-la BigMemory)
>to enable efficient handling of a large number of java objects
> without affecting jvm garbage collection
>performance.
>
> {code}
> Has been rendered as
> {code}
>
> Apache DirectMemory name="Apache_DirectMemory">
> Apache DirectMemory is a multi layered cache implementation
> featuring off-heap memory management (a-la BigMemory)
>to enable efficient handling of a large number of java objects
> without affecting jvm garbage collection
>performance.
>
> {code}
> Of course, depending on the skin, it could cause undesired effects.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-451) Tweak Doxia Markdown module HTML to better match
[ https://jira.codehaus.org/browse/DOXIA-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-451. --- Resolution: Fixed Fix Version/s: 1.3 Assignee: Lukas Theussl Patch applied in [r1185539|http://svn.apache.org/viewvc?view=revision&revision=1185539]. Thanks! > Tweak Doxia Markdown module HTML to better match > > > Key: DOXIA-451 > URL: https://jira.codehaus.org/browse/DOXIA-451 > Project: Maven Doxia > Issue Type: Improvement > Components: Module - Markdown >Affects Versions: 1.3 >Reporter: Brian Ferris >Assignee: Lukas Theussl > Fix For: 1.3 > > Attachments: doxia-module-markdown-HtmlSerializationStrategy.patch > > > The Doxia Markdown module currently uses the Pegdown module to generate HTML > and then relies on the Doxia xhtml module to parse that. The Pegdown HTML > generation currently produces HTML that doesn't exactly match what other > modules produce, which causes some style errors. Specifically, for "code" > blocks, there is no wrapping wrapper, which causes > output to look strange. The attached patch adjusts the output. > Of course, if the markdown module is going to be refactored to produce actual > Doxia AST events, that might make this less of an issue. But I still think > it'd be good to commit this patch in the meantime, especially if 1.3 is > released before the refactoring. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-637) parsing of git urls fails on windows
parsing of git urls fails on windows Key: SCM-637 URL: https://jira.codehaus.org/browse/SCM-637 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.5 Reporter: Felix Simmendinger Priority: Blocker please fix this issue raised in the release plugin http://jira.codehaus.org/browse/MRELEASE-624 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4947) NPE in at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType()
[
https://jira.codehaus.org/browse/MNG-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281510#comment-281510
]
Ernst de Haan commented on MNG-4947:
Still having this issue with Maven 3.0.3. Here's part of the log:{code}[DEBUG]
Configuring mojo org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war
from plugin realm
ClassRealm[plugin>org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725, parent:
sun.misc.Launcher$AppClassLoader@35a16869]
[DEBUG] Configuring mojo
'org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war' with basic
configurator -->
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Pluto . SUCCESS [0.528s]
[INFO] Pluto Types ... SUCCESS [4.730s]
[INFO] Pluto CAPI SUCCESS [4.567s]
[INFO] Pluto Server .. FAILURE [12.077s]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 22.073s
[INFO] Finished at: Tue Oct 18 11:42:41 CEST 2011
[INFO] Final Memory: 41M/411M
[INFO]
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at
org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NullPointerException
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:89)
at
org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromChildren(ArrayConverter.java:129)
at
org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromConfiguration(ArrayConverter.java:91)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:567)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:529)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
[jira] Issue Comment Edited: (MNG-4947) NPE in at org.codehaus.plexus.component.configurator.converters.lookup.DefaultConverterLookup.findConverterForType()
[
https://jira.codehaus.org/browse/MNG-4947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281510#comment-281510
]
Ernst de Haan edited comment on MNG-4947 at 10/18/11 4:54 AM:
--
(sorry, forget my comment, it was a different NPE)
was (Author: znerd):
Still having this issue with Maven 3.0.3. Here's part of the
log:{code}[DEBUG] Configuring mojo
org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war from plugin realm
ClassRealm[plugin>org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725, parent:
sun.misc.Launcher$AppClassLoader@35a16869]
[DEBUG] Configuring mojo
'org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war' with basic
configurator -->
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Pluto . SUCCESS [0.528s]
[INFO] Pluto Types ... SUCCESS [4.730s]
[INFO] Pluto CAPI SUCCESS [4.567s]
[INFO] Pluto Server .. FAILURE [12.077s]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 22.073s
[INFO] Finished at: Tue Oct 18 11:42:41 CEST 2011
[INFO] Final Memory: 41M/411M
[INFO]
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at
org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NullPointerException
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:89)
at
org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromChildren(ArrayConverter.java:129)
at
org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromConfiguration(ArrayConverter.java:91)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:567)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:529)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at
org.apache.maven.lifecycle.internal.MojoExecutor.
[jira] Created: (MNG-5183) NPE in ComponentValueSetter
NPE in ComponentValueSetter
---
Key: MNG-5183
URL: https://jira.codehaus.org/browse/MNG-5183
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0.3
Environment: $ uname -a
Linux kslv221 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64
x86_64 GNU/Linux
Environment settings:{code}MAVEN_HOME=/opt/apache-maven-3.0.3
PATH=/bin:/usr/bin:/opt/apache-maven-3.0.3/bin{code}
Reporter: Ernst de Haan
Here's part of the log tail:{code}[DEBUG] Configuring mojo
org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war from plugin realm
ClassRealm[plugin>org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725, parent:
sun.misc.Launcher$AppClassLoader@35a16869]
[DEBUG] Configuring mojo
'org.mortbay.jetty:jetty-maven-plugin:7.4.5.v20110725:run-war' with basic
configurator -->
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Pluto . SUCCESS [0.528s]
[INFO] Pluto Types ... SUCCESS [4.730s]
[INFO] Pluto CAPI SUCCESS [4.567s]
[INFO] Pluto Server .. FAILURE [12.077s]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 22.073s
[INFO] Finished at: Tue Oct 18 11:42:41 CEST 2011
[INFO] Final Memory: 41M/411M
[INFO]
[ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
org.apache.maven.InternalErrorException: Internal error:
java.lang.NullPointerException
at
org.apache.maven.lifecycle.internal.BuilderCommon.handleBuildError(BuilderCommon.java:128)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:95)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NullPointerException
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:89)
at
org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromChildren(ArrayConverter.java:129)
at
org.codehaus.plexus.component.configurator.converters.composite.ArrayConverter.fromConfiguration(ArrayConverter.java:91)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:331)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:151)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.populatePluginFields(DefaultMavenPluginManager.java:567)
at
org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:529)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92)
at
org.apache.maven.lifecycle.i
[jira] Updated: (MSANDBOX-51) Rewrite Plexus Utils classes at the ASF from scratch
[ https://jira.codehaus.org/browse/MSANDBOX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Nitschke updated MSANDBOX-51: - Attachment: plexus-utils-tck.patch I agree (/) > Rewrite Plexus Utils classes at the ASF from scratch > > > Key: MSANDBOX-51 > URL: https://jira.codehaus.org/browse/MSANDBOX-51 > Project: Maven 2.x Sandbox > Issue Type: New Feature >Reporter: Mark Struberg > Attachments: diff.txt, plexus-utils-tck.patch, plexus-utils-tck.patch > > > plexus-utils are 85% written by ASF committers, but we still don't have a IP > cleared history. > For cleaning this up we aim to rewrite those classes from scratch in ASF > maven sandbox. > The strategy is the following: > 1. create unit tests for the existing plexus classes > 2. create a new implementation from scratch > 3. the new implementation must be a binary API compatible drop-in replacement -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MSANDBOX-51) Rewrite Plexus Utils classes at the ASF from scratch
[ https://jira.codehaus.org/browse/MSANDBOX-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281536#comment-281536 ] Michael Nitschke edited comment on MSANDBOX-51 at 10/18/11 9:22 AM: I agree (/) with the submitted patch. Mike/Michael was (Author: minirich): I agree (/) > Rewrite Plexus Utils classes at the ASF from scratch > > > Key: MSANDBOX-51 > URL: https://jira.codehaus.org/browse/MSANDBOX-51 > Project: Maven 2.x Sandbox > Issue Type: New Feature >Reporter: Mark Struberg > Attachments: diff.txt, plexus-utils-tck.patch, plexus-utils-tck.patch > > > plexus-utils are 85% written by ASF committers, but we still don't have a IP > cleared history. > For cleaning this up we aim to rewrite those classes from scratch in ASF > maven sandbox. > The strategy is the following: > 1. create unit tests for the existing plexus classes > 2. create a new implementation from scratch > 3. the new implementation must be a binary API compatible drop-in replacement -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281538#comment-281538 ] Morten Kristiansen commented on MNG-1977: - Might be that this is already commented, but here's what we need: * Possibility to exclude transitive dependencies using groupId only (meaning all artifacts/versions within that groupId) * Another nice feature would be, a global pom setting that says: "Use transitive dependencies during compile, but not during packaging". Meaning: You can quickly get up developing code (getting all dependencies needed), but when bundling ex a war file, exclude trans. dep. because you want to control the war content. * Also a nice feature would be to turn off transitive dependencies all together :) > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1 > > Attachments: global_excls_it-test_v2.patch, > global_excls_maven3_v2.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281539#comment-281539 ] Neale commented on MNG-1977: I think there's some allusion to a version 5 of pom.xml, which would be interesting. If nothing else, I certainly support the idea of exclude. It is time that we got a release that solved some of the longest standing issues and gave us an opportunity to move forwards rather than to live with backwards compatibility that kills us. I love the idea of allowing a switch to change compile -> compile = compile to what was originally intended, that compile -> compile = runtime This would make many builds far more robust to changes in child dependencies. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1 > > Attachments: global_excls_it-test_v2.patch, > global_excls_maven3_v2.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-452) Doxia doesn't know about UTF-8 BOMs
Doxia doesn't know about UTF-8 BOMs --- Key: DOXIA-452 URL: https://jira.codehaus.org/browse/DOXIA-452 Project: Maven Doxia Issue Type: Bug Components: Module - Apt Affects Versions: 1.2 Reporter: Benson Margulies If an input apt doc is in UTF-8 with a BOM, the BOM passes through as noise characters inside the HTML result. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5184) java.lang.NoClassDefFoundError: com.sun.mirror.apt.AnnotationProcessorFactory on AIX 5.3
java.lang.NoClassDefFoundError: com.sun.mirror.apt.AnnotationProcessorFactory on AIX 5.3 Key: MNG-5184 URL: https://jira.codehaus.org/browse/MNG-5184 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.3, 2.2.1 Environment: AIX 5.3.0.0 java version "1.6.0" Java(TM) SE Runtime Environment (build pap6460sr9fp1-20110208_03(SR9 FP1)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc64-64 jvmap6460sr9-20110203_74623 (JIT enabled, AOT enabled) J9VM - 20110203_074623 JIT - r9_20101028_17488ifx3 GC - 20101027_AA) JCL - 20110203_01 Reporter: Matt M. Attachments: generate-schema.zip, maven221.log, maven303.log Running "mvn install" with the sample project fails with the fatal error "java.lang.NoClassDefFoundError: com.sun.mirror.apt.AnnotationProcessorFactory". This bug was said to be fixed in http://jira.codehaus.org/browse/MNG-3712 but seems to have reappeared using the latest mvn 2 and 3 on AIX. Thank you for your help with this! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-189) add java 5 annotations support to mark Mojo sources
add java 5 annotations support to mark Mojo sources --- Key: MPLUGIN-189 URL: https://jira.codehaus.org/browse/MPLUGIN-189 Project: Maven 2.x Plugin Tools Issue Type: New Feature Components: Java Plugins Affects Versions: 2.9 Reporter: Herve Boutemy replacing javadoc annotations with Java 5 annotations will improve the build process, like it has been done for [Plexus annotations|http://plexus.codehaus.org/plexus-containers/plexus-component-annotations/] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPLUGIN-189) add java 5 annotations support to mark Mojo sources
[ https://jira.codehaus.org/browse/MPLUGIN-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281576#comment-281576 ] Herve Boutemy commented on MPLUGIN-189: --- see http://wiki.jfrog.org/confluence/display/OSS/Maven+Anno+Mojo cited in MNG-2521 > add java 5 annotations support to mark Mojo sources > --- > > Key: MPLUGIN-189 > URL: https://jira.codehaus.org/browse/MPLUGIN-189 > Project: Maven 2.x Plugin Tools > Issue Type: New Feature > Components: Java Plugins >Affects Versions: 2.9 >Reporter: Herve Boutemy > > replacing javadoc annotations with Java 5 annotations will improve the build > process, like it has been done for [Plexus > annotations|http://plexus.codehaus.org/plexus-containers/plexus-component-annotations/] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-778) failIfNoTests=false should not be required when using -Dtest=MyTestClass in multi-module reactor builds
failIfNoTests=false should not be required when using -Dtest=MyTestClass in multi-module reactor builds --- Key: SUREFIRE-778 URL: https://jira.codehaus.org/browse/SUREFIRE-778 Project: Maven Surefire Issue Type: Bug Affects Versions: 2.10 Reporter: Scott Carey Configure a trivial multi-module build with two tests (TestA, TestB) and two modules, one test in each module. a multi-module aggregate build will succeed with 'mvn test' but fail with 'mvn test -Dtest=TestA' This happens with 2.10, but does not with 2.6 for http://avro.apache.org/ (https://issues.apache.org/jira/browse/AVRO-935) This is related to bug http://jira.codehaus.org/browse/SUREFIRE-464 -Dtest=Foo should not require that every module have a matching Foo, only one needs match. Or to simplify things, don't automatically switch from failIfNoTests=false to failIfNoTests=true when -Dtest= is set at all. Users who are running one test by hand don't need this behavior (they will notice if the test they are trying to run doesn't run) and automated tools/scripts that use this parameter that want it to fail should set -DfailIfNoTests=true. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281577#comment-281577 ] Sergei Ivanov commented on MNG-1977: @Morten: I think that "Include transitive dependencies during packaging" should rather be a feature of war, shade and other packaging plugins. There must already be enough information available to plugins through project meta-data, because maven-assembly-plugin has already got an option to filter out transitive dependencies. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1 > > Attachments: global_excls_it-test_v2.patch, > global_excls_maven3_v2.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281578#comment-281578 ] Sergei Ivanov commented on MNG-1977: @Neale: I agree that it would make a lot of sense to promote transitive compile dependencies into runtime scope, but unfortunately that does not solve the problem of polluting the runtime scope with unwanted transitive dependencies. More flexible exclusion mechanism using patterns or some other configuration is still needed. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1 > > Attachments: global_excls_it-test_v2.patch, > global_excls_maven3_v2.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281586#comment-281586 ] Joerg Schaible commented on MNG-1977: - bq. compile -> compile = runtime bq. This would make many builds far more robust to changes in child dependencies. You can simulate this if you use a global master pom. Then you would not only set the version in the depMgmt, but also the scope of all deps to runtime. That will have the same effect, you would have to set compile scope explicitly everywhere in our project. Been there and reverted it ... you'll see yourself, if you try ;-) > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.1 > > Attachments: global_excls_it-test_v2.patch, > global_excls_maven3_v2.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2742) Using a version range in a plugin dependency causes "failure to resolve artifact" error
[ https://jira.codehaus.org/browse/MNG-2742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281589#comment-281589 ] Arnaud Heritier commented on MNG-2742: -- Same thing here with Maven 3.0.3 :( > Using a version range in a plugin dependency causes "failure to resolve > artifact" error > --- > > Key: MNG-2742 > URL: https://jira.codehaus.org/browse/MNG-2742 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP SP2, java version "1.5.0_08" >Reporter: Matthew Adams > Fix For: Issues to be reviewed for 3.x > > Attachments: mvn.txt, pom.xml > > > If I declare a dependency in a plugin using an exact version, Maven correctly > resolves the artifact. If, however, I change the dependency's version to a > version range, Maven no longer resolves the artifact. I'm using the very > same artifact and version range in my project's dependencies and everything > works ok. See my attached pom.xml file for details, in particular, the > comments "" and "". > I am using the "major.minor.revision-buildNumber" version string syntax as > described on the wiki. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-726) Test list preprocessor support for tests to be run
[ https://jira.codehaus.org/browse/SUREFIRE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281599#comment-281599 ] Parameswaran Raman commented on SUREFIRE-726: - Hi, I am looking to use TLB with Maven for my project. It would be great if you can push in this patch as quickly as possible as there is a significant improvement (in build time) that we are looking forward to. -- Thanks, Params parame...@gmail.com > Test list preprocessor support for tests to be run > -- > > Key: SUREFIRE-726 > URL: https://jira.codehaus.org/browse/SUREFIRE-726 > Project: Maven Surefire > Issue Type: New Feature >Affects Versions: 2.9 >Reporter: Janmejay Singh > Fix For: 3.0 > > Attachments: > 0001-Adds-test-list-preprocessor-support-which-loads-an-o.patch, > 0002-Integration-test-for-preprocessor.-2-modules-one-pro.patch, > 0003-exposed-testPreprocessor-configuration-parameter-as-.patch, > 0004-exposed-testPreprocessor-for-IntegrationTestMojo-as-.patch > > > This exposes an interface(named TestListPreprocessor, which has a method > named preprocessTestClasses) that can be implemented by a user and injected > into surefire plugin configuration to have it used for preprocessing list of > tests to be run. Given the original test list, user's preprocessing algorithm > can choose to prune or reorder the list and return it back from > TestListPreprocessor#preprocessTestClasses, which is then used as the list of > tests to be executed. > The patches attached expose a configuration element named "testPreprocessor" > the default value of which is "none". User can choose to set it to a value > matching the format > "[::]" and have > the class loaded and called with list of tests to be run. The list of tests > returned by the call is then considered for execution. > Patch description: > The feature is done in 2 patches. Description follows: > 0001-Adds-test-list-preprocessor-support-which-loads-an-o.patch > This patch actually adds the feature and unit tests. It adds the interface, > an abstraction that encapsulates aforementioned configuration, booter > serialization/deserialization, directory-scanner changes etc. The changes > have effect in both forked and in-process execution mode. > 0002-Integration-test-for-preprocessor.-2-modules-one-pro.patch > This patch adds an integration test for preprocessor feature. The integration > test uses a 2 module setup, where the first module implements the > TestListPreprocessor interface which selects only even indexed test classes > from the list passed in. The second module(which depends on first) uses the > artifact from first and uses the following configuration: > > > > test.preprocessor.EvenTestOnlyPreprocessor[org.apache.maven.plugins.surefire:preprocessor-impl:1.0-SNAPSHOT] > > > The test then asserts that only 2(0th and 2nd) of the 4 test classes the > second module has are executed. > The patches are created on a git-svn clone using format-patch, please use > 'patch -p1 < 0001-Adds...'(while in the trunk directory) to apply the patches > on svn repository. If using git-svn, git-am can be directly be invoked. > The patches are done over > http://svn.apache.org/repos/asf/maven/surefire/trunk@1091357 (trunk HEAD) so > should apply cleanly on any recent enough revision. > === > Context: > http://stackoverflow.com/questions/5124823/reducing-the-build-time-hudson > http://code.google.com/p/tlb/issues/detail?id=1 > http://test-load-balancer.github.com -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
