[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: updateWorkingCopyVersionsfalse/updateWorkingCopyVersions updateDependenciesfalse/updateDependencies 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 {{section}} element, if {{class}} attribute is
specified, it is replicated to the nested {{h2}} element.
For example, for
{code}
section name=Apache DirectMemory class=hero-unit
pApache 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./p
/section
{code}
Has been rendered as
{code}
div class=hero-unit
h2 class=hero-unitApache DirectMemorya
name=Apache_DirectMemory/a/h2
pApache 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./p
/div
{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=revisionrevision=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 {{section}} element, if {{class}} attribute is
specified, it is replicated to the nested {{h2}} element.
For example, for
{code}
section name=Apache DirectMemory class=hero-unit
pApache 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./p
/section
{code}
Has been rendered as
{code}
div class=hero-unit
h2 class=hero-unitApache DirectMemorya
name=Apache_DirectMemory/a/h2
pApache 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./p
/div
{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-tabpanelfocusedCommentId=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 {{section}} element, if {{class}} attribute is
specified, it is replicated to the nested {{h2}} element.
For example, for
{code}
section name=Apache DirectMemory class=hero-unit
pApache 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./p
/section
{code}
Has been rendered as
{code}
div class=hero-unit
h2 class=hero-unitApache DirectMemorya
name=Apache_DirectMemory/a/h2
pApache 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./p
/div
{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=revisionrevision=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 div class=source/ 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-tabpanelfocusedCommentId=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[pluginorg.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-tabpanelfocusedCommentId=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[pluginorg.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
[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[pluginorg.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
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 exclusions 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-tabpanelfocusedCommentId=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 scopeexclude/scope. 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 exclusions 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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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 exclusions 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-tabpanelfocusedCommentId=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 exclusions 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-tabpanelfocusedCommentId=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 exclusions 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-tabpanelfocusedCommentId=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 !-- Using version range here ok -- and !-- Can't use version range here! --. 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
