[jira] (MSITE-717) The generated xhtml document has the entire content on a single line
[ https://jira.codehaus.org/browse/MSITE-717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MSITE-717. --- Resolution: Fixed Fix Version/s: 3.3 Assignee: Herve Boutemy The generated xhtml document has the entire content on a single line Key: MSITE-717 URL: https://jira.codehaus.org/browse/MSITE-717 Project: Maven Site Plugin Issue Type: Improvement Components: doxia integration Affects Versions: 3.2 Reporter: Herve Boutemy Assignee: Herve Boutemy Fix For: 3.3 fixed in DOXIA-405: need to upgrade to Doxia 1.4 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSITE-717) The generated xhtml document has the entire content on a single line
Herve Boutemy created MSITE-717: --- Summary: The generated xhtml document has the entire content on a single line Key: MSITE-717 URL: https://jira.codehaus.org/browse/MSITE-717 Project: Maven Site Plugin Issue Type: Improvement Components: doxia integration Affects Versions: 3.2 Reporter: Herve Boutemy fixed in DOXIA-405: need to upgrade to Doxia 1.4 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (WAGON-416) Lightweight HTTP Wagon doesn't set Proxy-Authorization header
[
https://jira.codehaus.org/browse/WAGON-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Grzybek updated WAGON-416:
---
Summary: Lightweight HTTP Wagon doesn't set Proxy-Authorization header
(was: Lightweight HTTP Wagon doesn't set Proxy-Authorization headers)
Lightweight HTTP Wagon doesn't set Proxy-Authorization header
-
Key: WAGON-416
URL: https://jira.codehaus.org/browse/WAGON-416
Project: Maven Wagon
Issue Type: Bug
Components: wagon-http-lightweight
Reporter: Grzegorz Grzybek
When using
{code:java}
org.apache.maven.wagon.AbstractWagon#connect(org.apache.maven.wagon.repository.Repository,
org.apache.maven.wagon.authentication.AuthenticationInfo,
org.apache.maven.wagon.proxy.ProxyInfoProvider)
{code}
method (using {{ProxyInfoProvider}}) the {{proxyInfo}} field in Wagon isn't
initialized. Then, when connecting to secure HTTP proxy,
{{Proxy-Authorization}} header is not set.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MJAVADOC-398) Classes from build output directory can cause failure
Michal Srb created MJAVADOC-398: --- Summary: Classes from build output directory can cause failure Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MJAVADOC-398) Classes from build output directory can cause failure
[ https://jira.codehaus.org/browse/MJAVADOC-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348855#comment-348855 ] Michal Srb commented on MJAVADOC-398: - I've opened PR on github: https://github.com/apache/maven-plugins/pull/25 Classes from build output directory can cause failure - Key: MJAVADOC-398 URL: https://jira.codehaus.org/browse/MJAVADOC-398 Project: Maven Javadoc Plugin Issue Type: Bug Affects Versions: 2.9.1 Reporter: Michal Srb maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway. [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5658) Syntax error in bin/mvn on Solaris SPARC
[ https://jira.codehaus.org/browse/MNG-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348874#comment-348874 ] Jason van Zyl commented on MNG-5658: Can you provide a patch please. Syntax error in bin/mvn on Solaris SPARC Key: MNG-5658 URL: https://jira.codehaus.org/browse/MNG-5658 Project: Maven Issue Type: Bug Affects Versions: 3.2.2 Environment: Solaris SPARC 10 with Oracle JDK 1.7.0_60 Reporter: Frank Langelage The latest addition to bin/mvn breaks mvn running on Solaris. Syntax error in line 86. The Bourne shell /bin/sh does not understand this syntax with the brackets. if [[ -z $JAVA_HOME -x /usr/libexec/java_home ]] ; then # # Apple JDKs # export JAVA_HOME=$(/usr/libexec/java_home) fi ;; changing the line with the assignment to export JAVA_HOME=/usr/libexec/java_home like the lines before makes it running again. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-75) Squash indexer-artifact and indexer-core
[
https://jira.codehaus.org/browse/MINDEXER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348877#comment-348877
]
Tamás Cservenák commented on MINDEXER-75:
-
{{indexer-core}} should be it... just move all the atifact into core for now.
Squash indexer-artifact and indexer-core
Key: MINDEXER-75
URL: https://jira.codehaus.org/browse/MINDEXER-75
Project: Maven Indexer
Issue Type: Task
Reporter: Tamás Cservenák
Priority: Minor
This separation is a legacy, while this component was part of Sonatype Nexus.
There is no reason to have the 10 classes separated now.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-32) Make ArtifactInfo extensible
[ https://jira.codehaus.org/browse/MINDEXER-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348880#comment-348880 ] Tamás Cservenák commented on MINDEXER-32: - If we would break compatibility (I tihink must to), then simplty make ArtifactInfo a plain POJO so all fields. currently it has public fields all over the place. But, IMO, ArtifactInfo should basically be a plain map of strings... this way new index creators could easily extend it by some new extracted and indexed fields too Make ArtifactInfo extensible Key: MINDEXER-32 URL: https://jira.codehaus.org/browse/MINDEXER-32 Project: Maven Indexer Issue Type: Improvement Reporter: Tamás Cservenák Make ArtifactInfo extensible. Currently this class bleeds from multiple wounds: no setters and fixed fields. This makes introduction of new fields (by core or by some extension introducing new IndexCreator) nearly impossible, and is laborious. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1083) Prefix user properties with plugin name
Karl-Heinz Marbaise created SUREFIRE-1083:
-
Summary: Prefix user properties with plugin name
Key: SUREFIRE-1083
URL: https://jira.codehaus.org/browse/SUREFIRE-1083
Project: Maven Surefire
Issue Type: Bug
Affects Versions: 2.17
Reporter: Karl-Heinz Marbaise
Priority: Minor
Based on a [question on
SO|http://stackoverflow.com/questions/24441210/maven-3-javadoc-plugin-conflicts-with-testng-groups]
the problem is that some properties of maven-surefire-plugin / maven-failsafe
are not being prefixed consistently by the plugn mame.
This should be changed to prevent such problems on command line:
{noformat}mvn install -Dgroups=somegroup{noformat} which is accidently picked
up by maven-javadoc-plugin.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINVOKER-166) Failing in relationship with Maven 3.2.2
[
https://jira.codehaus.org/browse/MINVOKER-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348904#comment-348904
]
Cody Fyler commented on MINVOKER-166:
-
Looks good.
Failing in relationship with Maven 3.2.2
Key: MINVOKER-166
URL: https://jira.codehaus.org/browse/MINVOKER-166
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 1.8
Environment: Maven 3.2.2
Reporter: Karl-Heinz Marbaise
Assignee: Karl-Heinz Marbaise
Priority: Blocker
Fix For: 1.8.1
Message of Cody Fyler on the users list:
I just update to 3.2.2 from 3.2.1 and am now getting the error below from the
maven-invoker-plugin. Using Java 1.8.20.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-invoker-plugin:1.8:run (integration-test) on
project base-pom: Execution integration-test of goal
org.apache.maven.plugins:maven-invoker-plugin:1.8:run failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-invoker-plugin:1.8:run:
java.lang.NoSuchMethodError:
org.apache.maven.settings.Settings.getRuntimeInfo()Lorg/apache/maven/settings/RuntimeInfo;
{code}
Here is the configuration from my pom.xml:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-invoker-plugin/artifactId
version1.8/version
inheritedfalse/inherited
executions
execution
idpre-integration-test/id
goals
goalinstall/goal
/goals
/execution
execution
idintegration-test/id
goals
goalrun/goal
/goals
configuration
addTestClassPathfalse/addTestClassPath
settingsFile${basedir}/src/test/resources/settings.xml/settingsFile
cloneAllFilestrue/cloneAllFiles
cloneCleantrue/cloneClean
cloneProjectsTo${project.build.directory}/it/projects/cloneProjectsTo
mergeUserSettingstrue/mergeUserSettings
parallelThreads4/parallelThreads
projectsDirectory${basedir}/src/test/resources/parent/projectsDirectory
properties
BUILD_NUMBER${BUILD_NUMBER}/BUILD_NUMBER
dryRuntrue/dryRun
jacocotrue/jacoco
jenkins.build.number${BUILD_NUMBER}/jenkins.build.number
ignoreSnapshotstrue/ignoreSnapshots
/properties
pom${basedir}/src/test/resources/parent/pom.xml/pom
showErrorstrue/showErrors
showVersiontrue/showVersion
streamLogstrue/streamLogs
debugfalse/debug
goals
!--goalclean/goal --
goalinstall/goal
goalsonar:sonar/goal
goalrelease:prepare/goal
goalrelease:perform/goal
/goals
/configuration
/execution
/executions
configuration
filterProperties
artifactory.hostsomething.com/artifactory.host
/filterProperties
localRepositoryPath${localRepositoryPath}/localRepositoryPath
/configuration
/plugin
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MINDEXER-75) Squash indexer-artifact and indexer-core
[ https://jira.codehaus.org/browse/MINDEXER-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348910#comment-348910 ] Martin Todorov commented on MINDEXER-75: Hi, Please check https://github.com/apache/maven-indexer/pull/1. Kind regards, Martin Squash indexer-artifact and indexer-core Key: MINDEXER-75 URL: https://jira.codehaus.org/browse/MINDEXER-75 Project: Maven Indexer Issue Type: Task Reporter: Tamás Cservenák Priority: Minor This separation is a legacy, while this component was part of Sonatype Nexus. There is no reason to have the 10 classes separated now. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINVOKER-166) Failing in relationship with Maven 3.2.2
[
https://jira.codehaus.org/browse/MINVOKER-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348916#comment-348916
]
Karl-Heinz Marbaise commented on MINVOKER-166:
--
Many thanks for your support and help.
So i start the release vote for it.
Failing in relationship with Maven 3.2.2
Key: MINVOKER-166
URL: https://jira.codehaus.org/browse/MINVOKER-166
Project: Maven Invoker Plugin
Issue Type: Bug
Affects Versions: 1.8
Environment: Maven 3.2.2
Reporter: Karl-Heinz Marbaise
Assignee: Karl-Heinz Marbaise
Priority: Blocker
Fix For: 1.8.1
Message of Cody Fyler on the users list:
I just update to 3.2.2 from 3.2.1 and am now getting the error below from the
maven-invoker-plugin. Using Java 1.8.20.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-invoker-plugin:1.8:run (integration-test) on
project base-pom: Execution integration-test of goal
org.apache.maven.plugins:maven-invoker-plugin:1.8:run failed: An API
incompatibility was encountered while executing
org.apache.maven.plugins:maven-invoker-plugin:1.8:run:
java.lang.NoSuchMethodError:
org.apache.maven.settings.Settings.getRuntimeInfo()Lorg/apache/maven/settings/RuntimeInfo;
{code}
Here is the configuration from my pom.xml:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-invoker-plugin/artifactId
version1.8/version
inheritedfalse/inherited
executions
execution
idpre-integration-test/id
goals
goalinstall/goal
/goals
/execution
execution
idintegration-test/id
goals
goalrun/goal
/goals
configuration
addTestClassPathfalse/addTestClassPath
settingsFile${basedir}/src/test/resources/settings.xml/settingsFile
cloneAllFilestrue/cloneAllFiles
cloneCleantrue/cloneClean
cloneProjectsTo${project.build.directory}/it/projects/cloneProjectsTo
mergeUserSettingstrue/mergeUserSettings
parallelThreads4/parallelThreads
projectsDirectory${basedir}/src/test/resources/parent/projectsDirectory
properties
BUILD_NUMBER${BUILD_NUMBER}/BUILD_NUMBER
dryRuntrue/dryRun
jacocotrue/jacoco
jenkins.build.number${BUILD_NUMBER}/jenkins.build.number
ignoreSnapshotstrue/ignoreSnapshots
/properties
pom${basedir}/src/test/resources/parent/pom.xml/pom
showErrorstrue/showErrors
showVersiontrue/showVersion
streamLogstrue/streamLogs
debugfalse/debug
goals
!--goalclean/goal --
goalinstall/goal
goalsonar:sonar/goal
goalrelease:prepare/goal
goalrelease:perform/goal
/goals
/configuration
/execution
/executions
configuration
filterProperties
artifactory.hostsomething.com/artifactory.host
/filterProperties
localRepositoryPath${localRepositoryPath}/localRepositoryPath
/configuration
/plugin
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (SUREFIRE-1084) Surefire-report stack traces appear on a single line.
Josh Eversmann created SUREFIRE-1084: Summary: Surefire-report stack traces appear on a single line. Key: SUREFIRE-1084 URL: https://jira.codehaus.org/browse/SUREFIRE-1084 Project: Maven Surefire Issue Type: Bug Reporter: Josh Eversmann Priority: Minor The pre tags and line breaks used by SurefireReportGenerator .constructFailureDetails do not correctly format the stack trace in the generated page. Related PR: https://github.com/apache/maven-surefire/pull/41 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5658) Syntax error in bin/mvn on Solaris SPARC
[ https://jira.codehaus.org/browse/MNG-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Langelage updated MNG-5658: - Attachment: maven_bin_mvn.patch Patch showing the diff between old and new version. Optional: put around the path/file checked like done in the cases above Mandatory: remove $( ) around the absolute file name. Syntax error in bin/mvn on Solaris SPARC Key: MNG-5658 URL: https://jira.codehaus.org/browse/MNG-5658 Project: Maven Issue Type: Bug Affects Versions: 3.2.2 Environment: Solaris SPARC 10 with Oracle JDK 1.7.0_60 Reporter: Frank Langelage Attachments: maven_bin_mvn.patch The latest addition to bin/mvn breaks mvn running on Solaris. Syntax error in line 86. The Bourne shell /bin/sh does not understand this syntax with the brackets. if [[ -z $JAVA_HOME -x /usr/libexec/java_home ]] ; then # # Apple JDKs # export JAVA_HOME=$(/usr/libexec/java_home) fi ;; changing the line with the assignment to export JAVA_HOME=/usr/libexec/java_home like the lines before makes it running again. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5658) Syntax error in bin/mvn on Solaris SPARC
[ https://jira.codehaus.org/browse/MNG-5658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Langelage updated MNG-5658: - Complexity: Novice (was: Intermediate) Syntax error in bin/mvn on Solaris SPARC Key: MNG-5658 URL: https://jira.codehaus.org/browse/MNG-5658 Project: Maven Issue Type: Bug Affects Versions: 3.2.2 Environment: Solaris SPARC 10 with Oracle JDK 1.7.0_60 Reporter: Frank Langelage Attachments: maven_bin_mvn.patch The latest addition to bin/mvn breaks mvn running on Solaris. Syntax error in line 86. The Bourne shell /bin/sh does not understand this syntax with the brackets. if [[ -z $JAVA_HOME -x /usr/libexec/java_home ]] ; then # # Apple JDKs # export JAVA_HOME=$(/usr/libexec/java_home) fi ;; changing the line with the assignment to export JAVA_HOME=/usr/libexec/java_home like the lines before makes it running again. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-330) centralise and internationalise error messages
[ https://jira.codehaus.org/browse/MNG-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-330: --- Fix Version/s: (was: 3.x / Backlog) centralise and internationalise error messages -- Key: MNG-330 URL: https://jira.codehaus.org/browse/MNG-330 Project: Maven Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Brett Porter Priority: Critical -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-612) implement conflict resolution techniques
[ https://jira.codehaus.org/browse/MNG-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-612: --- Fix Version/s: (was: 3.x / Backlog) implement conflict resolution techniques Key: MNG-612 URL: https://jira.codehaus.org/browse/MNG-612 Project: Maven Issue Type: New Feature Components: Artifacts and Repositories, Design, Patterns Best Practices Reporter: Brett Porter Assignee: Mark Hobson Priority: Critical Attachments: MNG-612-2.patch, MNG-612-3.patch, MNG-612.patch Original Estimate: 8 hours Remaining Estimate: 8 hours currently, the collector only: - selects nearest suggested version in a valid range - latest version from the valid ranges if none suggested - fails if ranges are over-constrained This needs to be configurable: - select newest, even if there is a nearer suggestion - select oldest, even if there is a nearer suggestion - fail if all suggestions don't equate or a range results instead of a single version - ignore over constrained ranges and fallback to some other algorithm - select snapshots even if they weren't explicitly specified -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-4039) Allow plugins the chance to alter the project artifacts/dependencies during 'resolution phase'
[ https://jira.codehaus.org/browse/MNG-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-4039: Fix Version/s: (was: 3.x / Backlog) Allow plugins the chance to alter the project artifacts/dependencies during 'resolution phase' -- Key: MNG-4039 URL: https://jira.codehaus.org/browse/MNG-4039 Project: Maven Issue Type: New Feature Components: Dependencies, IDEs, Plugin API, Plugins and Lifecycle, POM Affects Versions: 3.0-alpha-2 Environment: n/a Reporter: Steve Ebersole Assignee: Jason van Zyl The term 'resolution phase' was taken from an email on this subject : http://www.nabble.com/Re%3A-Programmatically-adding-dependencies-to-a-MavenProject-p21668701.html Basically, there are times when a plugin could add dependencies to the project dependency tree in an effort to alleviate the project pom developer from unnecessary ugliness. My particular use-case is very fitting imo. In trying to write a plugin for antlr's gunit functionality. gUnit is a mechanism for generating JUnit tests for testing antlr grammars; it uses an antlr grammar itself to describe the tests. Typically, a project using antlr3 is going to define a dependency on the org.antlr:antlr-runtime artifact, since that artifact contains all the classes needed to utilize antlr in the runtime as well as all that need to be exposed via transitive dependencies. However, during build-time, a project using antlr is also going to need access to the org.antlr:antlr artifact which defines all the classes needed for grammar - java-class transformations. As an anti-example, currently the antlr3 plugin handles this by defining a hard dependency to a particular version of org.antlr:antlr in its pom even if that version is a mismatch from the one used by the project. Wouldn't it be great if the plugin were allowed to be smart enough to say hey, the project to which I am attached is using org.antlr:antlr-runtime:3.1.0 so i really should be using org.antlr:antlr:3.1.0 for grammar transformation? And in the case of the antlr3 plugin it actually can do this already because it does not need to muck with any of the project classpaths in order to do this. But in the case of this gunit example, that is not the case. As I said, gunit generates JUnit test classes which should then get picked up by the normal surefire mechanism and executed. The issue is that these gunit-generated JUnit classes have dependencies on gunit classes, so gunit must be available on the test compilation classpath. Following along with the discussion above, it would be fantastic if the plugin could handle all these details for the project and prepare the classpath properly. One possibility for implementing this is a new method on org.apache.maven.plugin.Mojo. Another is a new optional mojo interface like org.apache.maven.plugin.DependencyContributingMojo -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-4633) Make weave mode work reliably
[ https://jira.codehaus.org/browse/MNG-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-4633: Fix Version/s: (was: 3.x / Backlog) Make weave mode work reliably - Key: MNG-4633 URL: https://jira.codehaus.org/browse/MNG-4633 Project: Maven Issue Type: Improvement Affects Versions: 3.0-beta-1 Reporter: Kristian Rosenvold Assignee: Kristian Rosenvold m3 trunk currently contains two different concurrent-build implementations; parallel and weave. The main target for m3 is for production quality parallel to be ready; there are numerous plugins that will need to adjust to this functionality. Alongside this activity weave mode will also be fine-tuned and evaluated; due to the generally tighter concurrency in this model, weave mode is more likely to reveal concurrency related issues in both maven, plugins, libraries and the jdk. This task is used to collect all commits related to making weave mode work reliably. The final evaluation of weave mode will be taken at a later stage. In the event that Weave mode is to be abandoned, the class LifecycleWeaveBuilder contains instructions on how/what can be removed from m3 core. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-542) Allow properties to inherit from other properties
[ https://jira.codehaus.org/browse/MNG-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-542: --- Fix Version/s: (was: 3.x / Backlog) Allow properties to inherit from other properties - Key: MNG-542 URL: https://jira.codehaus.org/browse/MNG-542 Project: Maven Issue Type: New Feature Components: Plugins and Lifecycle Affects Versions: 2.0-alpha-3 Reporter: Vincent Massol For example pom.build.outputDirectory (classes directory) should inherit from pom.build.directory. Same for all properties that are used to generate build data. Why? Becasue otherwise it's downright impossible to change the location of the target directory (pom.build.directory) as you don't know beforehand all the plugins that are part of the lifecycle and how many properties they each have and their name. For example in the clover plugin I need to set the target dir to another location so that main build data is not compromised. I can't do it as I can't controll all the properties that could possibly exist. I'd just like to set the pom.build.directory to a new value and be done with it. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1950) Ability to introduce new lifecycles phases
[ https://jira.codehaus.org/browse/MNG-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-1950: Fix Version/s: (was: 3.x / Backlog) Ability to introduce new lifecycles phases -- Key: MNG-1950 URL: https://jira.codehaus.org/browse/MNG-1950 Project: Maven Issue Type: New Feature Components: Design, Patterns Best Practices, Plugins and Lifecycle Affects Versions: 2.0.1 Reporter: Chris Hagmann I have simple use case which I cannot resolve with Maven 2 as it is right now. I have a project (actually many), where I need to do the following: - Create an JAR artifact (standard stuff, easily possible) - Create a source code artifact (standard stuff, easily possible) - Create Javadoc and a JAR archive of it (not possible, I explain why). - Create a distribution package with release notes, customized reports, Javadoc, JAR, dependencies, documentation, filtered files, etc. (not possible, I explain why and will file another JIRA issue for this) The constraint is that I need to create all 4 artifacts and have them installed them in the repository when using mvn install. As there are no other appropriate lifecycle phases in the default lifecycle, I attach the generation of all 4 artifacts to the phase package. That is very messy, and won't provide me with what I need. It should be possible to define a new lifecycle and have new phases attached to it. E.g.: - ... (standard lifecycle phases) - test - jar - javadoc - source-archive - javadoc-archive - package - ... (standard lifecycle phases) The reason why it is mandatory at this point to have new lifecycle phases, is that there is a constraint that a plugin can have only one unique configuration per lifecycle phase. So if I need to use the same plugin, but e.g. using different goals which require different plugin configurations, then that's not possible. The only way this can be achieved is by using new lifecycle phases, which is also not possible at this point. Meaning, I cannot create a solution for my simple use case in Maven 2 and hence it blocks me for moving to Maven 2 (I really hate to file blockers, but I'm at a dead-end). -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3053) Define an Repository Manager API for reaching far RMs for various inquiries
[ https://jira.codehaus.org/browse/MNG-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-3053: Fix Version/s: (was: 3.x / Backlog) Define an Repository Manager API for reaching far RMs for various inquiries --- Key: MNG-3053 URL: https://jira.codehaus.org/browse/MNG-3053 Project: Maven Issue Type: New Feature Components: Artifacts and Repositories Reporter: Tamás Cservenák Maven Community should define a common API for reaching Repository Managers in programmatic way. Repository Manager implementations could implement this API fully or just partially (depending on their capabilities, etc). This API could be used by various Maven related tools (like M2Eclipse plugin) in searches, indexing etc. Possible RM published functionalities: - direct searching by passing some expressions/lucene queries/whatever - preparing and offering Lucene/Compass index downloads - turning reposes online/offine, reachable/unreachable, etc - Basic RM configurations, repo blackouts, repo controlling - Advanced RM configurations (probably RM specific?) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3619) Dependency.equals(Object):boolean is missing for version 4.0.0 POMs
[
https://jira.codehaus.org/browse/MNG-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-3619:
Fix Version/s: (was: 3.x / Backlog)
Dependency.equals(Object):boolean is missing for version 4.0.0 POMs
---
Key: MNG-3619
URL: https://jira.codehaus.org/browse/MNG-3619
Project: Maven
Issue Type: Bug
Components: POM
Reporter: Dennis Lundberg
The modello file for the 2.0.x branch does not have a codeSegment for 4.0.0
POMs that implements equals(Object):boolean. Modello doesn't generate one
automatically either. Perhaps upgrading to a newer version of the modello
plugin will solve this.
http://svn.apache.org/viewvc/maven/components/branches/maven-2.0.x/maven-model/src/main/mdo/maven.mdo?revision=659677view=markup
There is a codeSegment for 3.0.0 POMs only:
{code}
/**
* @see java.lang.Object#equals(java.lang.Object)
*/
public boolean equals( Object o )
{
if ( this == o )
{
return true;
}
if ( !( o instanceof Dependency ) )
{
return false;
}
Dependency d = (Dependency) o;
return getId().equals( d.getId() );
}
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3689) Dependency excludes applies to subsequent dependencies
[ https://jira.codehaus.org/browse/MNG-3689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-3689: Fix Version/s: (was: 3.x / Backlog) Dependency excludes applies to subsequent dependencies -- Key: MNG-3689 URL: https://jira.codehaus.org/browse/MNG-3689 Project: Maven Issue Type: Bug Components: Dependencies Affects Versions: 2.0.7, 2.0.8, 2.0.9 Environment: WinXP - Sun JDK-1.5.0_15 Reporter: Paul Taylor Dependency exclusions seem to be in-correctly scoped and so are applying to subsequent dependencies at the same level. This results in dependencies being 'removed' when new dependencies are 'added'. The issue is apparent in the pom below which use spring-ws-core and spring-core, which both use the commons-logging-1.1. Commons-logging 1.1 erroneously includes servlet-api - a fact which spring-ws-core attempts to resolve with exclusions. a pom which ''only'' has spring-core as a dependency pulls in servlet-api. the addition of spring-ws-core has the effect of 'removing' commons-logging. This behaviour occurs under maven 2.0.8. Under maven 2.0.9 it is 'dependency order dependant' - swapping the pair of spring-core and spring-ws-core highlights or hides the erroneous behaviour. ?xml version=1.0 encoding=UTF-8? project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIda.b.c.d/groupId artifactIdmaven-minimal/artifactId namemaven-minimal/name version1.0-SNAPSHOT/version dependencies dependency groupIdorg.springframework.ws/groupId artifactIdspring-ws-core/artifactId version1.0.3/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-core/artifactId version2.0.7/version /dependency /dependencies /project -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1694) Build execution order control in fine grained projects.
[ https://jira.codehaus.org/browse/MNG-1694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-1694: Fix Version/s: (was: 3.x / Backlog) Build execution order control in fine grained projects. --- Key: MNG-1694 URL: https://jira.codehaus.org/browse/MNG-1694 Project: Maven Issue Type: New Feature Components: Reactor and workspace Reporter: Mark Proctor Currently in multi module projects you can only work in 2 modes. 1) Build everything 2) Build a single module, IF you have built and installed all its dependency modules I would like to be able to work the following way: 1) Build everything 2) Build an individual module, will build all the modules prior to it in the reactor list. 3) Build a module module and all modules after it in the reactor list, will build missing prior modules. Use Case 1) perform checkout and build 2) module fails 3) keep fixing module and running just its unit tests 3) once all its unit tests pass build it and all modules after it in the reactor list. I don't need to build ones prior as they are unnaffected by the changes. In large mutli module projects this will save a LOT of time especially when you are gearing up for deployment and want to check that everything works - currently this is time consuming and repetitive, with much of the repetition uneeded. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3137) IT 0108 (snapshot updates) fail intermittently
[ https://jira.codehaus.org/browse/MNG-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-3137: Fix Version/s: (was: 3.x / Backlog) IT 0108 (snapshot updates) fail intermittently --- Key: MNG-3137 URL: https://jira.codehaus.org/browse/MNG-3137 Project: Maven Issue Type: Bug Components: Integration Tests Reporter: Brett Porter testSnapshotUpdatedWithMetadata(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest) Time elapsed: 4.443 sec FAILURE! junit.framework.ComparisonFailure: expected:updated... but was:original... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.it.Verifier.assertArtifactContents(Verifier.java:1493) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.assertArtifactContents(MavenIT0108SnapshotUpdateTest.java:255) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadata(MavenIT0108SnapshotUpdateTest.java:113) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadata(MavenIT0108SnapshotUpdateTest.java:113) testSnapshotUpdatedWithMetadataUsingFileTimestamp(org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest) Time elapsed: 5.265 sec FAILURE! junit.framework.ComparisonFailure: expected:updated... but was:original... at junit.framework.Assert.assertEquals(Assert.java:81) at junit.framework.Assert.assertEquals(Assert.java:87) at org.apache.maven.it.Verifier.assertArtifactContents(Verifier.java:1493) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.assertArtifactContents(MavenIT0108SnapshotUpdateTest.java:255) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadataUsingFileTimestamp(MavenIT0108SnapshotUpdateTest.java:195) at org.apache.maven.integrationtests.MavenIT0108SnapshotUpdateTest.testSnapshotUpdatedWithMetadataUsingFileTimestamp(MavenIT0108SnapshotUpdateTest.java:195) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-3812) Externalize all strings and make maven fully localizable.
[ https://jira.codehaus.org/browse/MNG-3812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-3812: Fix Version/s: (was: 3.x / Backlog) Externalize all strings and make maven fully localizable. - Key: MNG-3812 URL: https://jira.codehaus.org/browse/MNG-3812 Project: Maven Issue Type: New Feature Reporter: Christian Schulte -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-1755) Improve support for developers in reactor builds
[ https://jira.codehaus.org/browse/MNG-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-1755: Fix Version/s: (was: 3.x / Backlog) Improve support for developers in reactor builds -- Key: MNG-1755 URL: https://jira.codehaus.org/browse/MNG-1755 Project: Maven Issue Type: Improvement Components: POM Reporter: Mike Perham I would like to see something like developerManagement added which acts similarly to the other management elements in the POM. This would allow a top-level project POM to list all the developers, their orgs, timezones, emails, etc and child projects to reference just the ID and the developers role in that module. Something like this: parent's pom.xml: developerManagement developer idmsanchez/id nameMatt Sanchez/name emailmatt.sanc...@webifysolutions.com/email urlhttp://priori.webify.local:9090/display/~msanchez/url timezone-6/timezone /developer developer idmperham/id nameMike Perham/name emailmper...@webifysolutions.com/email urlhttp://priori:9090/display/~mperham/url timezone-6/timezone /developer /developerManagement foo's pom.xml: developers developer idmperham/id roles roleOwner/role /roles /developer /developers Our management wants to have one or two clear-cut owners for each module and we would like to use maven to document those owners but the current impl is terribly redundant since developers are not inherited. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2581) Mojo's with @execute don't get configured with executedProject
[
https://jira.codehaus.org/browse/MNG-2581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-2581:
Fix Version/s: (was: 3.x / Backlog)
Mojo's with @execute don't get configured with executedProject
--
Key: MNG-2581
URL: https://jira.codehaus.org/browse/MNG-2581
Project: Maven
Issue Type: Bug
Components: Plugins and Lifecycle
Reporter: Kenney Westerhof
Not sure if this is a bug or an improvement, but here's a scenario:
A custom plugin defines a MavenProject property with a timestamp. That
timestamp
is used in finalName${project.artifactId}-${timestamp}/finalName.
During the normal plugin execution, this field is evaluated correctly.
When running mvn assembly:assembly, the normal (forked) lifecycle also
functions correctly.
But the assembly Mojo is configured with the original MavenProject, that
doesn't have the ${timestamp} property,
so the finalName parameter on the assembly mojo will be someArtifact-null.
A tough problem, but it goes further: Ideally you never want to use
${project} as a parameter, but
the objects fields directly. Say you want to use the source roots and define
that as a parameter. Then you
never get access the generated-sources unless you manually examine the
executedProject.
Right now, mojo's have to use different logic depending on whether they
specify @execute phase=X,
(and examine fields of the executedProject).
Can we drop the original MavenProject object and replace that with
executedProject instance, so we only have
1 instance of MavenProject?
Or, if there are plugins that MUST use the original MavenProject, or use both
MavenProject instances (we might
want to scan all existing mojo's to see what they do), can we add
a plugin flag that specifies that that mojo must be configured using the
executedProject instead?
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3891) Modify maven-toolchain to look in ${maven.home}/conf/toolchains.xml and in ${user.home}/.m2/toolchains.xml
[
https://jira.codehaus.org/browse/MNG-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-3891:
Fix Version/s: (was: 3.x / Backlog)
Modify maven-toolchain to look in ${maven.home}/conf/toolchains.xml and in
${user.home}/.m2/toolchains.xml
---
Key: MNG-3891
URL: https://jira.codehaus.org/browse/MNG-3891
Project: Maven
Issue Type: Improvement
Affects Versions: 2.0.9
Reporter: Marco Lessard
Actually, we can only specify the toolchains.xml in
${user.home}/.m2/toolchains.xml.
However, like for the settings.xml, it would be very convenient to specify a
default toolchains.xml in ${maven.home}/conf/toolchains.xml
The idea is : If there is NO *${user.home}/.m2/toolchains.xml*,
then uses *${maven.home}/conf/toolchains.xml*,
otherwise NONE defined.
Merging both would also be good but not necessary.
The change is very simple. Edit the file
*maven-toolchain\src\main\java\org\apache\maven\toolchain\DefaultToolchainManager.java*
and replace
{code}
private PersistedToolchains readToolchainSettings() throws
MisconfiguredToolchainException {
File tch = new File(System.getProperty(user.home),
.m2/toolchains.xml);
if (tch.exists()) {
MavenToolchainsXpp3Reader reader = new MavenToolchainsXpp3Reader();
...
{code}
by
{code}
private PersistedToolchains readToolchainSettings() throws
MisconfiguredToolchainException {
File tch = null;
tch = new File(System.getProperty(user.home), .m2/toolchains.xml);
if (tch == null || !tch.exists()) {
tch = new File(System.getProperty(maven.home),
conf/toolchains.xml);
}
if (tch.exists()) {
MavenToolchainsXpp3Reader reader = new MavenToolchainsXpp3Reader();
...
{code}
I did that on my local environment by compiling this 2.0.11-SNAPSHOT class
and integrating it in my maven-2.0.9-uber.jar and it works perfectly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1692) Project scoped Repository
[ https://jira.codehaus.org/browse/MNG-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-1692: Fix Version/s: (was: 3.x / Backlog) Project scoped Repository - Key: MNG-1692 URL: https://jira.codehaus.org/browse/MNG-1692 Project: Maven Issue Type: New Feature Components: Artifacts and Repositories Reporter: Mark Proctor In multi module builds I would like jars to not instally locally until I instruct it and still be able to build individual modules. At the moment if I try and build an invidiual module it insists on looking in the local repo. In Maven 1 we worked around this by using jar override. The use case for this is for when you are messing around with multiple checkouts of the same version and don't want them to interact with each other. With current M2 I either have to create different versions in the pom for each checkout, when all changes are likely to end up in the master checkout for a specific verison. Or I can specify the repo to be in the project, but that means I have to checkout everything each time I want to build something. This could be achieve by using root/target as a project level repo for the produced jars which would use the local repo for anything that it can't find it the project repo. Only when I tell it to install will it copy the jars from the project repo to the local repo. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2933) Declaring the same resource dir in pom and overwriting it in a profile
[ https://jira.codehaus.org/browse/MNG-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-2933: Fix Version/s: (was: 3.x / Backlog) Declaring the same resource dir in pom and overwriting it in a profile -- Key: MNG-2933 URL: https://jira.codehaus.org/browse/MNG-2933 Project: Maven Issue Type: Bug Components: Profiles Affects Versions: 2.0.6 Reporter: Dirk Olmes Priority: Minor I have a pom that declares a resource dir in the main section of the pom and a profile which re-declares the same resource dir in a profile, this time with excludes. Example: project ... build resources resource directorysrc/main/resources/directory /resource /resources /build profiles profile id... build resources resource directorysrc/main/resources/directory excludes/excludes /resource /resources /build /profile /profiles /project Running mvn -X with the profile activated shows that the same resource dir is added twice to the runtime model. I would have expected the profile to overwrite the resource directory as this is the behaviour for re-declaring dependencies in a profile over dependencies in the main section. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-2275) profiles should be merged when inherited
[
https://jira.codehaus.org/browse/MNG-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-2275:
Fix Version/s: (was: 3.x / Backlog)
profiles should be merged when inherited
Key: MNG-2275
URL: https://jira.codehaus.org/browse/MNG-2275
Project: Maven
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: brianfox brianfox
I have some default profiles setup in a super parent pom that all projects
inherit from. In some projects I want to change the active profile, but not
from the CLI because other projects running in the same multi-project build
need to have the normal default. I attempted to work around this by setting
the profile to be active on a property in the child pom. See below for parent
and child. It appears that when I do this, the child profile replaces the
parent. It should be merged so that the properties are pulled from the parent
and uses the activation from the child.
parent:
!-- Setup default profiles. --
profiles
profile
iddev/id
properties
profile-default.valuessrc/main/filters/dev-default.values/profile-default.values
/properties
/profile
profile
idauto-test/id
properties
profile-default.valuessrc/main/filters/auto-test-default.values/profile-default.values
/properties
/profile
profile
idman-test/id
properties
profile-default.valuessrc/main/filters/man-test-default.values/profile-default.values
/properties
/profile
profile
idprod/id
properties
profile-default.valuessrc/main/filters/prod-default.values/profile-default.values
/properties
/profile
/profiles
child pom..
!-- This is the property to override for custom properties in this
project--
properties
client-ct-package.values${user.default.values}/client-ct-package.values
/properties
build
filters
filter${profile-default.values}/filter
filter${user.default.values}/filter
filter${client-ct-package.values}/filter
/filters
resources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/resources
/build
!-- temporary to activate the CT production values until all projects can
have prod values --
profiles
profile
idprod/id
activation
property
namedeploy-ct/name
/property
/activation
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3844) Review inheritance of SCM info
[
https://jira.codehaus.org/browse/MNG-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-3844:
Fix Version/s: (was: 3.x / Backlog)
Review inheritance of SCM info
--
Key: MNG-3844
URL: https://jira.codehaus.org/browse/MNG-3844
Project: Maven
Issue Type: New Feature
Components: Inheritance and Interpolation
Affects Versions: 2.0.9, 2.1.0-M1
Reporter: Benjamin Bentmann
Priority: Trivial
Consider this parent POM snippet:
{code:xml}
scm
urlhttp://parent.url/viewvc/url
connectionhttp://parent.url/scm/connection
developerConnectionhttps://parent.url/scm/developerConnection
tagparent-tag/tag
/scm
{code}
And now this child POM snippet:
{code:xml}
scm
developerConnectionhttps://child.url/scm/developerConnection
/scm
{code}
This delivers the effective child POM:
{code:xml}
scm
urlhttp://parent.url/viewvc/child/url
connectionhttp://parent.url/scm/child/connection
developerConnectionhttps://child.url/scm/developerConnection
/scm
{code}
i.e. {{url}} and {{connection}} are still inherited.
This appears neither sensible nor consistent with other inheritance rules
(e.g. {{ciManagement}} and {{issueManagement}} are only inherited if
completely omitted in the child).
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-3926) Spaces if properties are not preserved if using CDATA
[ https://jira.codehaus.org/browse/MNG-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-3926: Fix Version/s: (was: 3.x / Backlog) Spaces if properties are not preserved if using CDATA - Key: MNG-3926 URL: https://jira.codehaus.org/browse/MNG-3926 Project: Maven Issue Type: Bug Affects Versions: 2.0.9 Reporter: Stefan Franke Priority: Trivial Using a property like this one: properties cdata![CDATA[ ]]/cdata /properties results into an empty property (see effective-pom): properties cdata/ /properties which is wrong. See also the XML spec: Note that a CDATA section containing only white space or a reference to an entity whose replacement text is character references expanding to white space do not match the nonterminal S which also stats that white spaces inside CDATA must not be trimmed away. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5534) Update to Sisu 0.1.0 and Guice 3.1.6
[ https://jira.codehaus.org/browse/MNG-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5534: Affects Version/s: (was: 3.1.2) Update to Sisu 0.1.0 and Guice 3.1.6 Key: MNG-5534 URL: https://jira.codehaus.org/browse/MNG-5534 Project: Maven Issue Type: Improvement Reporter: Mikolaj Izdebski Assignee: Jason van Zyl Attachments: 0001-Update-to-Sisu-0.1.0-and-Guice-3.1.6.patch, upgrade_to_eclipse_sisu_0.1.1.patch Please update to Eclipse Sisu 0.1.0 and Sisu Guice 3.1.6. Sisu depends on Guice, but dependency scope changed from compile to provided in Sisu 0.1.0. As a Sisu user, Maven needs to have runtime dependency on Guice. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5332) Custom version scheme
[ https://jira.codehaus.org/browse/MNG-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5332: Affects Version/s: (was: 3.1.x) 3.2.x Custom version scheme - Key: MNG-5332 URL: https://jira.codehaus.org/browse/MNG-5332 Project: Maven Issue Type: New Feature Components: POM Affects Versions: 3.2.x Reporter: Markus KARG To be able to always find the latest bug fix (and for other use cases) Maven supports version ranges. To be able to correctly detected whether a version is in the range, or what the latest version of the detected version is, Maven has to know the meaning of each part of the version. Maven currently is able to deal with versions in the following syntax: Major.Minor.Build-Qualifier, where Major, Minor and Build must be Integers, and Qualifier can be a String. Major, Minor and Build will identify ascending post-GA versions, a qualifier always will mark a version as pre-GA. So far, so good. Unfortunatley, there are lots of other versioning syntaxes, like the rather propular OSGi variant Major.Minor.Build.Qualifier where the Qualifier also is found in POST-GA variants, and is separated by a dot. As more and more OSGi artefacts are uploaded to Maven Central (like e. g. the rather popular Hibernate suite), and as Maven users want to have such artefacts as dependencies (while still using version ranges), the Maven range resolver has to learn to deal with different version syntax. My proposal is: Adding another POM element that teaches Maven what the patten of a version is made of, and how to treat the qualifier. The idea is not yet perfectly thought to the end, but shall trigger a discussion about a final solution. In the foreign (e. g. OSGi) artefact's POM, the following could be defined to teach Maven (and all Maven related tools like Nexus) how to deal with non-mavenized versions: version4.5.6.Final/version versionSyntax[major(int,asc)].[minor(int,asc)].[build(int,asc)].[qualifier(resolve)]/versionSyntax versionQualifierResolution preGAAlpha*, Beta*/preGA postGASR*/postGA GAFinal/GA /versionQualifierResolution This example defines the OSGi versioning scheme in a structured way so that Maven will learn how to treat it: version/ contains a version number in OSGi syntax, so all artefacts will keep it (otherwise it won't work in OSGi anymore). versionSyntax defines that the version is made up of four dot-separated pieces. To make clear what is a piece and what is a literal, pieces are [bracketed]. As Maven needs to find major, minor, build and qualifier, these names are static and identify the position of that piece in the pattern. int means integer sorting rules. str means string sorting rules. asc and desc mean the sorting direction. resolve means that the qualifier is not to be sorted, but to be resolved using the given table. In that table, pre identifies the qualifiers that will mark the version number as pre GA (= prior to the given version). Other possible values are post GA (= past to the given version) and GA (= the qualifier does not further modify the given version). An alternative approach could be using reg ex instead of this new fancy syntax, but then we have to define sorting and data type in a different way in the POM. Please share your opinion! It is clear that OSGi enforces Maven to react in some way. So here is my proposal. What do you think? -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5337) Maven activation profile feature cannot differ jdk version with build number
[ https://jira.codehaus.org/browse/MNG-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5337: Affects Version/s: (was: 3.1.x) 3.1.1 Maven activation profile feature cannot differ jdk version with build number Key: MNG-5337 URL: https://jira.codehaus.org/browse/MNG-5337 Project: Maven Issue Type: Bug Affects Versions: 3.1.1, 3.2.1 Reporter: Vladimir Kravets Priority: Minor Attachments: fix_jdk_build_version_activator.diff Since Oracle can apply some major changes between builds we need to have ability to detect build number from profile - activation - jdk tag By now using only first three components of jdk version. I propose to use first 4 components of the version to be able to process it further. E.g. from ~1.6.0-30 classpath separator is ; instead of :. In 1.7.x also using ;. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5431) Support include scope
[ https://jira.codehaus.org/browse/MNG-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5431: Affects Version/s: (was: 3.1.x) Support include scope --- Key: MNG-5431 URL: https://jira.codehaus.org/browse/MNG-5431 Project: Maven Issue Type: Improvement Components: Dependencies, Inheritance and Interpolation, POM Affects Versions: 3.0.4, 3.2.x Reporter: Matthew Adams Attachments: included-pom.xml, including-pom.xml I'd like to request an improvement over the current pom import support. The current import support only goes so far as adding dependencies to the dependencyManagement section of a pom. The importing pom still is left to add those dependencies to its own dependencies, which is inconvenient, especially for imported poms that define many dependencies. Instead, I propose the addition of a new scope called include that can be used to add the imported pom's dependencies section to the importing pom's dependencies section. A pom that wants to include another pom, then, would simply declare the dependency on the included pom's groupId:artifactId:version, but use a scope of include, which would imply type pom. The important thing to realize is that this could be done in the dependencies section of the including pom (not necessarily dependencyManagementdependencies). For example, in the including pom's dependencies (at XPath project/dependencies, not project/dependencyManagement/dependencies): dependency groupIdme.matthewadams/groupId artifactIddatanucleus-rdbms/artifactId scopeinclude/scope !-- NEW! different from import! -- version3.1.4/version /dependency The scope include implies typepom/type; declaring it explicitly would be ok, but declaring any other type would be an error. See the two poms attached to this request for a more thorough example. Also, see user list discussion at http://maven.40175.n5.nabble.com/New-Maven-idea-include-import-tp5745916.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5459) failure to resolve pom artifact from snapshotVersion in maven-metadata.xml
[
https://jira.codehaus.org/browse/MNG-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5459:
Affects Version/s: (was: 3.1.x)
3.1.0
failure to resolve pom artifact from snapshotVersion in maven-metadata.xml
--
Key: MNG-5459
URL: https://jira.codehaus.org/browse/MNG-5459
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.5, 3.1.0
Reporter: Claudio Bley
Assignee: Robert Scholte
Fix For: 3.1.1
Attachments: mng5459.patch, mvn-snapshot-resolve-fix.diff
We're using Artifactory on the server side, and ivy / sbt to publish
artifacts upstream.
After publishing several -SNAPSHOT versions of a project, trying to use it
from Maven, resulted in a warning and ultimately a build failure because it
cannot determine the dependencies:
{code}[WARNING] The POM for com.foo:bar:jar:0.4.0-20130404.093655-3 is
missing, no dependency information available{code}
This is the corresponding maven-metadata-snapshots.xml:
{code:xml}
metadata
groupIdcom.foo/groupId
artifactIdbar/artifactId
version0.4.0-SNAPSHOT/version
versioning
snapshot
timestamp20130404.090532/timestamp
buildNumber2/buildNumber
/snapshot
lastUpdated20130404093657/lastUpdated
snapshotVersions
snapshotVersion
extensionpom/extension
value0.4.0-20130404.090532-2/value
updated20130404090532/updated
/snapshotVersion
snapshotVersion
extensionjar/extension
value0.4.0-20130404.093655-3/value
updated20130404093655/updated
/snapshotVersion
/snapshotVersions
/versioning
/metadata
{code}
As you can see, the value for the jar artifact and the pom artifact differ:
0.4.0-20130404.093655-3
0.4.0-20130404.090532-2
Apparently, artifactory optimizes the case when an artifact doesn't change;
it does not create a new file, but just links to the existing one.
Maven, however, takes a shortcut and makes the erroneous assumption that the
values for pom and jar artifact always match up.
The attached patch fixes this.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-5323) Add ability to interrupt a build with SUCCESS status from maven plugins.
[ https://jira.codehaus.org/browse/MNG-5323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5323: Affects Version/s: (was: 3.1.x) 3.2.x Add ability to interrupt a build with SUCCESS status from maven plugins. Key: MNG-5323 URL: https://jira.codehaus.org/browse/MNG-5323 Project: Maven Issue Type: Improvement Components: General, Plugin API Affects Versions: 3.2.x Environment: any Reporter: Stanislav Tyurikov Priority: Critical Attachments: build_succeed_exception.patch Add ability to successfully finish a build from maven plugin. It can help to create maven plugins for build optimization. Currently we can interrupt a build only to fail it (by throwing an exception from the execute method of a mojo). This functionality can be easily implemented by adding BuildSuccessException to the maven core and modifying LifecycleModuleBuilder and DefaultBuildPluginManager to process this exception and finish the build as succeed. Any custom maven plugin can throw BuildSuccessException to indicate the build is OK and no further steps are needed to be executed. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5515) Allow scope validator to be configurable
[ https://jira.codehaus.org/browse/MNG-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5515: Affects Version/s: (was: 3.1.x) Allow scope validator to be configurable Key: MNG-5515 URL: https://jira.codehaus.org/browse/MNG-5515 Project: Maven Issue Type: Improvement Components: Bootstrap Build Affects Versions: 3.1.0, 3.2.x Reporter: Scott Hamilton Priority: Minor Attachments: mvn3-DefaultModelValidator-scopeValidator.patch For projects using flex mojos, those flex mojos use non-standard scopes (e.g. internal, external, rsl, cached, etc.). This throws warnings into the build output, which if one's goal is to keep the build clean, is a problem. In the DefaultModelValidator class there is even this comment: /* * TODO: Extensions like Flex Mojos use custom scopes like merged, internal, external, etc. * In order to don't break backward-compat with those, only warn but don't error out. */ This enhancement is to allow a configuration setting to either skip or configure the allowable scopes to preclude these warnings. Ideally this could be fixed in a better way (perhaps through a project extension plugin) but this was the least intrusive way I saw to get this to work. See the attached patch file where I allow two different system/user settings. skipScopeValidation can be set to skip validation of the scopes entirely, or additionalScopes can be set to a comma-delimited list of additional scopes that will pass validation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5431) Support include scope
[ https://jira.codehaus.org/browse/MNG-5431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5431: Affects Version/s: 3.2.x Support include scope --- Key: MNG-5431 URL: https://jira.codehaus.org/browse/MNG-5431 Project: Maven Issue Type: Improvement Components: Dependencies, Inheritance and Interpolation, POM Affects Versions: 3.0.4, 3.2.x Reporter: Matthew Adams Attachments: included-pom.xml, including-pom.xml I'd like to request an improvement over the current pom import support. The current import support only goes so far as adding dependencies to the dependencyManagement section of a pom. The importing pom still is left to add those dependencies to its own dependencies, which is inconvenient, especially for imported poms that define many dependencies. Instead, I propose the addition of a new scope called include that can be used to add the imported pom's dependencies section to the importing pom's dependencies section. A pom that wants to include another pom, then, would simply declare the dependency on the included pom's groupId:artifactId:version, but use a scope of include, which would imply type pom. The important thing to realize is that this could be done in the dependencies section of the including pom (not necessarily dependencyManagementdependencies). For example, in the including pom's dependencies (at XPath project/dependencies, not project/dependencyManagement/dependencies): dependency groupIdme.matthewadams/groupId artifactIddatanucleus-rdbms/artifactId scopeinclude/scope !-- NEW! different from import! -- version3.1.4/version /dependency The scope include implies typepom/type; declaring it explicitly would be ok, but declaring any other type would be an error. See the two poms attached to this request for a more thorough example. Also, see user list discussion at http://maven.40175.n5.nabble.com/New-Maven-idea-include-import-tp5745916.html -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5515) Allow scope validator to be configurable
[ https://jira.codehaus.org/browse/MNG-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5515: Affects Version/s: 3.2.x Allow scope validator to be configurable Key: MNG-5515 URL: https://jira.codehaus.org/browse/MNG-5515 Project: Maven Issue Type: Improvement Components: Bootstrap Build Affects Versions: 3.1.0, 3.2.x Reporter: Scott Hamilton Priority: Minor Attachments: mvn3-DefaultModelValidator-scopeValidator.patch For projects using flex mojos, those flex mojos use non-standard scopes (e.g. internal, external, rsl, cached, etc.). This throws warnings into the build output, which if one's goal is to keep the build clean, is a problem. In the DefaultModelValidator class there is even this comment: /* * TODO: Extensions like Flex Mojos use custom scopes like merged, internal, external, etc. * In order to don't break backward-compat with those, only warn but don't error out. */ This enhancement is to allow a configuration setting to either skip or configure the allowable scopes to preclude these warnings. Ideally this could be fixed in a better way (perhaps through a project extension plugin) but this was the least intrusive way I saw to get this to work. See the attached patch file where I allow two different system/user settings. skipScopeValidation can be set to skip validation of the scopes entirely, or additionalScopes can be set to a comma-delimited list of additional scopes that will pass validation. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-1084) Surefire-report stack traces appear on a single line.
[ https://jira.codehaus.org/browse/SUREFIRE-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348936#comment-348936 ] Herve Boutemy commented on SUREFIRE-1084: - can you point to a sample output that shows the issue? Surefire-report stack traces appear on a single line. - Key: SUREFIRE-1084 URL: https://jira.codehaus.org/browse/SUREFIRE-1084 Project: Maven Surefire Issue Type: Bug Reporter: Josh Eversmann Priority: Minor The pre tags and line breaks used by SurefireReportGenerator .constructFailureDetails do not correctly format the stack trace in the generated page. Related PR: https://github.com/apache/maven-surefire/pull/41 -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (DOXIASITETOOLS-76) Missing inheritance of 'googleAdSenseClient', 'googleAdSenseSlot' and 'googleAnalyticsAccountId' elements.
[ https://jira.codehaus.org/browse/DOXIASITETOOLS-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed DOXIASITETOOLS-76. --- Resolution: Fixed Fix Version/s: 1.6 Assignee: Herve Boutemy patch applied in [r1606223|http://svn.apache.org/r1606223] thank you Missing inheritance of 'googleAdSenseClient', 'googleAdSenseSlot' and 'googleAnalyticsAccountId' elements. -- Key: DOXIASITETOOLS-76 URL: https://jira.codehaus.org/browse/DOXIASITETOOLS-76 Project: Maven Doxia Sitetools Issue Type: Bug Components: Decoration model Affects Versions: 1.3 Reporter: Christian Schulte Assignee: Herve Boutemy Fix For: 1.6 Attachments: DOXIASITETOOLS-76.patch -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5534) Update to Sisu 0.1.0 and Guice 3.1.6
[ https://jira.codehaus.org/browse/MNG-5534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348938#comment-348938 ] Stuart McCulloch commented on MNG-5534: --- FYI, latest releases are Sisu 0.2.1 and Guice 3.2.2 (note you can also update to the latest version of Guava with this version of Guice) Update to Sisu 0.1.0 and Guice 3.1.6 Key: MNG-5534 URL: https://jira.codehaus.org/browse/MNG-5534 Project: Maven Issue Type: Improvement Reporter: Mikolaj Izdebski Assignee: Jason van Zyl Attachments: 0001-Update-to-Sisu-0.1.0-and-Guice-3.1.6.patch, upgrade_to_eclipse_sisu_0.1.1.patch Please update to Eclipse Sisu 0.1.0 and Sisu Guice 3.1.6. Sisu depends on Guice, but dependency scope changed from compile to provided in Sisu 0.1.0. As a Sisu user, Maven needs to have runtime dependency on Guice. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEPLOY-183) Add a delay before deployAtEnd
Matthew Jones created MDEPLOY-183: - Summary: Add a delay before deployAtEnd Key: MDEPLOY-183 URL: https://jira.codehaus.org/browse/MDEPLOY-183 Project: Maven Deploy Plugin Issue Type: Improvement Components: deploy:deploy Affects Versions: 2.8.1 Reporter: Matthew Jones Priority: Minor Attachments: DeployMojoSleep.patch The deployAtEnd is a great feature but I've had to make this modification to allow for a short wait time before deployment in order to make a few adjustments to files that were created during the build process. It really saved me a lot of headache just being able to get in and fix things manually. New parameter deployAtEndSleep - ms to sleep before deploying at end. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-77) Upgrade to Lucene 4.1
[ https://jira.codehaus.org/browse/MINDEXER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348941#comment-348941 ] Martin Todorov commented on MINDEXER-77: Hi, Is there any outstanding work that needs to be done on this? We've started work on 6.0-SNAPSHOT and are considering merging and polishing some issues/fixes. Kind regards, Martin Upgrade to Lucene 4.1 - Key: MINDEXER-77 URL: https://jira.codehaus.org/browse/MINDEXER-77 Project: Maven Indexer Issue Type: Improvement Reporter: Emmanuel Hugonnet Lucene has made a great effort in being quicker and smaller in the 4.x versions. Moving to this new version would make maven indexer better -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MINDEXER-49) M2GavCalculator does not parse GAV correctly for classifiers with dots
[
https://jira.codehaus.org/browse/MINDEXER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=348942#comment-348942
]
Martin Todorov commented on MINDEXER-49:
I don't think it's a very good idea to have dots in your classifier at all.
What would constitute a reasonable use case? Could you provide a real-life
example?
The dot is used across a lot of places as an indication of where the GAV
details end. You cannot currently guess easily where the GAV ends otherwise.
Perhaps somebody didn't consider mentioning this in the Maven docs. I think
this should not be implemented/supported, or encouraged as a practice.
M2GavCalculator does not parse GAV correctly for classifiers with dots
--
Key: MINDEXER-49
URL: https://jira.codehaus.org/browse/MINDEXER-49
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.1.1, 4.1.2
Environment: all
Reporter: René Zanner
Priority: Critical
When having a classifier with dots (classifier.with.dots) and an extension
with or without dots (e.g. tar.gz), the calculation of Gav changes classifier
and type/extension to something clearly not intended:
|| ||Attached artifact definition||M2GavCalculator result||
||classifier|classifier.with.dots|classifier|
||extension/type|tar.gz|with.dots.tar.gz|
The problem seems to be located in lines 136ff, 175ff *and* 216ff (do you
have a code duplication issue as well? ;-) ):
{code}
int nExtPos = tail.indexOf( '.' );
...
ext = tail.substring( nExtPos + 1 );
classifier = tail.charAt( 0 ) == '-' ? tail.substring( 1, nExtPos ) : null;
{code}
This code assumes that the classifier ends at the first dot in the tail
(which is everything after the version number).
Since Maven allows dots in classifiers _as well as in extensions_, the
parsing has to be made more intelligent. So, it is not enough to just turn
the parsing around and use the part after the last dot as extension and
before it as classifier (that's why I used the 'tar.gz' extension in my
example above).
I do not have a solution for this except checking for well-known extensions
(tar.gz, xml, jar, zip, a.s.o.) and build the classifier/extension parsing
around it.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
