[jira] Commented: (MSITE-484) Support adding and overriding report plugins in new maven-site-plugin 3.x reportPlugins configuration format
[
https://jira.codehaus.org/browse/MSITE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279822#comment-279822
]
Herve Boutemy commented on MSITE-484:
-
I didn't have time to check for the moment, but yes, this seems interesting at
Maven core level: there have already been discussion about having more flexible
merge policy for some pom content
see MNG-3124 and MNG-2807
> Support adding and overriding report plugins in new maven-site-plugin 3.x
> reportPlugins configuration format
>
>
> Key: MSITE-484
> URL: https://jira.codehaus.org/browse/MSITE-484
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, Maven 3
>Affects Versions: 3.0-beta-1, 3.0-beta-2, 3.0-beta-3
> Environment: 3.0-beta-1-SNAPSHOT
>Reporter: Michael Pilquist
>Assignee: Olivier Lamy
> Fix For: 3.1
>
> Attachments: MSITE-484.patch, MSITE-484.patch,
> site-cfg-inheritance.zip
>
>
> When using the new configuration format for reportPlugins, it appears that
> there's no way to:
> - Add a report plugin to a submodule
> - Override the configuration of a report plugin in a submodule
> Using the old section, both of these use cases were supported.
> For large, multi-module builds, it is problematic having to respecify all
> reporting plugins in any submodule pom that needs to either add an additional
> reporting plugin or change the configuration of a reporting plugin.
> Attached is a sample project that has a parent POM configured with
> project-info-reports and javadoc plugin and a submodule configured with jxr
> plugin and javadoc plugin. The relevant output is here:
> {code}
> [INFO]
>
> [INFO] Building parent 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent ---
> [INFO] Deleting file set: /Users/mpilquist/Downloads/site-parent-issue/target
> (included: [**], excluded: [])
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @ parent
> ---
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:2.2
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
> ...
> [INFO]
>
> [INFO] Building parent-usage-test 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent-usage-test
> ---
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @
> parent-usage-test ---
> [INFO] configuring reportPlugin org.apache.maven.plugins:maven-jxr-plugin:2.1
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
> {code}
> Looking at the maven-site-plugin code, it appears the the reportPlugins
> parameter is just a regular array parameter. AFAIK, there's no way to merge
> list configuration items. Other plugins have worked around this by defining
> additional mojo parameters (e.g., maven-eclipse-plugin and buildCommands /
> additionalBuildCommands --
> http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html).
> This isn't the most flexible option though as it only solves 1 level
> inheritance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SUREFIRE-766) Regression in excludes feature between surefire 2.6 and 2.7.
[
https://jira.codehaus.org/browse/SUREFIRE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed SUREFIRE-766.
--
Resolution: Fixed
Fixed in [r1175098|http://svn.apache.org/viewvc?view=revision&revision=1175098].
The reason that "once" worked but not "always" and "never", is because forking
"once" uses the directory scanner after the list of excludes is split and put
into a properties file and then read back in as separate elements. "always"
and "never" use the list of excludes without splitting the elements with a
comma, and the plexus utils scanner couldn't deal with elements with a comma in
them.
> Regression in excludes feature between surefire 2.6 and 2.7.
>
>
> Key: SUREFIRE-766
> URL: https://jira.codehaus.org/browse/SUREFIRE-766
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.7, 2.7.1, 2.7.2, 2.8, 2.8.1, 2.9
>Reporter: Jonathan Hsieh
>Assignee: Paul Gier
> Fix For: 2.10
>
>
> I have a build that excludes certain JUnit 4 test cases by allowing users to
> specify a -Dtest.exclude.pattern=**/TestA*.java,**/TestB*.java style command
> line argument. This worked for surefire 2.5, 2.6 but fails to work in 2.7,
> 2.7.1, 2.7.2, 2.8, 2.8.1, and 2.9 releases.
> Here's how I pass in the excludes from the command line:
> {code}
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> always
>
> **/Test*.java
>
>
> **/*$*
> ${test.exclude.pattern}
>
> ...
> {code}
> and
> {code}
> ...
>
>...
>
>
> **/${test.exclude}.java
>
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-766) Regression in excludes feature between surefire 2.6 and 2.7.
[
https://jira.codehaus.org/browse/SUREFIRE-766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated SUREFIRE-766:
---
Fix Version/s: 2.10
Assignee: Paul Gier
I found that to reproduce the problem, you have to have forkMode set to
"always" or "never". If it's set to "once", the problem goes away. Also, the
problem only occurs when there is a comma in the list of excludes.
> Regression in excludes feature between surefire 2.6 and 2.7.
>
>
> Key: SUREFIRE-766
> URL: https://jira.codehaus.org/browse/SUREFIRE-766
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.x support
>Affects Versions: 2.7, 2.7.1, 2.7.2, 2.8, 2.8.1, 2.9
>Reporter: Jonathan Hsieh
>Assignee: Paul Gier
> Fix For: 2.10
>
>
> I have a build that excludes certain JUnit 4 test cases by allowing users to
> specify a -Dtest.exclude.pattern=**/TestA*.java,**/TestB*.java style command
> line argument. This worked for surefire 2.5, 2.6 but fails to work in 2.7,
> 2.7.1, 2.7.2, 2.8, 2.8.1, and 2.9 releases.
> Here's how I pass in the excludes from the command line:
> {code}
> ...
>
> org.apache.maven.plugins
> maven-surefire-plugin
>
> always
>
> **/Test*.java
>
>
> **/*$*
> ${test.exclude.pattern}
>
> ...
> {code}
> and
> {code}
> ...
>
>...
>
>
> **/${test.exclude}.java
>
> ...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (WAGON-350) add unit tests for wagon-ssh
[ https://jira.codehaus.org/browse/WAGON-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-350. -- Resolution: Fixed some issues with ssh authz fixed in unit tests. > add unit tests for wagon-ssh > - > > Key: WAGON-350 > URL: https://jira.codehaus.org/browse/WAGON-350 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-ssh >Affects Versions: 1.0 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.0 > > > using mina sshd can help for embedded ssh server : > http://mina.apache.org/sshd/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (WAGON-351) fix time out configuration in wagon-http
[ https://jira.codehaus.org/browse/WAGON-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed WAGON-351. -- Resolution: Fixed fixed rev 1174993. > fix time out configuration in wagon-http > > > Key: WAGON-351 > URL: https://jira.codehaus.org/browse/WAGON-351 > Project: Maven Wagon > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.0 > > > currently the configuration called connectionTimeout is used for SO_TIMEOUT > which is a read time out !. > I will introduce a new parameter called readTimeout. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (WAGON-351) fix time out configuration in wagon-http
[ https://jira.codehaus.org/browse/WAGON-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated WAGON-351: --- Fix Version/s: 2.0 Assignee: Olivier Lamy > fix time out configuration in wagon-http > > > Key: WAGON-351 > URL: https://jira.codehaus.org/browse/WAGON-351 > Project: Maven Wagon > Issue Type: Bug >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 2.0 > > > currently the configuration called connectionTimeout is used for SO_TIMEOUT > which is a read time out !. > I will introduce a new parameter called readTimeout. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (WAGON-351) fix time out configuration in wagon-http
fix time out configuration in wagon-http Key: WAGON-351 URL: https://jira.codehaus.org/browse/WAGON-351 Project: Maven Wagon Issue Type: Bug Reporter: Olivier Lamy currently the configuration called connectionTimeout is used for SO_TIMEOUT which is a read time out !. I will introduce a new parameter called readTimeout. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-698) EclipseSourceDir writes full path unnecessarily for includes/excludes
[
https://jira.codehaus.org/browse/MECLIPSE-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lon Binder updated MECLIPSE-698:
Attachment: MECLIPSE-698.patch
The attached patch resolves this issue by checking the includes and excludes
during the set invocation.
> EclipseSourceDir writes full path unnecessarily for includes/excludes
> -
>
> Key: MECLIPSE-698
> URL: https://jira.codehaus.org/browse/MECLIPSE-698
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
>Affects Versions: 2.8
>Reporter: Lon Binder
> Attachments: MECLIPSE-698.patch
>
>
> The {{including}} and {{excluding}} attributes for {{.classpath}} entries are
> written fully regardless of their {{path}} value. The {{path}} part can
> (should) be excluded from the attribute values.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-698) EclipseSourceDir writes full path unnecessarily for includes/excludes
EclipseSourceDir writes full path unnecessarily for includes/excludes
-
Key: MECLIPSE-698
URL: https://jira.codehaus.org/browse/MECLIPSE-698
Project: Maven 2.x Eclipse Plugin
Issue Type: Improvement
Affects Versions: 2.8
Reporter: Lon Binder
The {{including}} and {{excluding}} attributes for {{.classpath}} entries are
written fully regardless of their {{path}} value. The {{path}} part can
(should) be excluded from the attribute values.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-484) Support adding and overriding report plugins in new maven-site-plugin 3.x reportPlugins configuration format
[
https://jira.codehaus.org/browse/MSITE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Dalquist updated MSITE-484:
Attachment: MSITE-484.patch
Updated patch, replaces mergePolicy. prefix with merge: xml namespace. In my
testing you can specify whatever you want for the namespace URI since I don't
actually have an XSD to go with it, I used
xmlns:merge="http://maven.apache.org/plugin-merge"; in my test pom.
This patch should be complete, all integration tests pass and the copyright
headers are correct. I do have an Apache ICLA on file and am an active
committer in the portals project: http://people.apache.org/committer-index.html
I would love this to become a core feature of Maven itself for merging plugin
configurations. I'm not sure where to go with getting that requested as a
feature. I'm hoping that this this seems to affect the site plugin more than
others it would be faster to get the fix in here so it could be used as soon as
possible.
> Support adding and overriding report plugins in new maven-site-plugin 3.x
> reportPlugins configuration format
>
>
> Key: MSITE-484
> URL: https://jira.codehaus.org/browse/MSITE-484
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, Maven 3
>Affects Versions: 3.0-beta-1, 3.0-beta-2, 3.0-beta-3
> Environment: 3.0-beta-1-SNAPSHOT
>Reporter: Michael Pilquist
>Assignee: Olivier Lamy
> Fix For: 3.1
>
> Attachments: MSITE-484.patch, MSITE-484.patch,
> site-cfg-inheritance.zip
>
>
> When using the new configuration format for reportPlugins, it appears that
> there's no way to:
> - Add a report plugin to a submodule
> - Override the configuration of a report plugin in a submodule
> Using the old section, both of these use cases were supported.
> For large, multi-module builds, it is problematic having to respecify all
> reporting plugins in any submodule pom that needs to either add an additional
> reporting plugin or change the configuration of a reporting plugin.
> Attached is a sample project that has a parent POM configured with
> project-info-reports and javadoc plugin and a submodule configured with jxr
> plugin and javadoc plugin. The relevant output is here:
> {code}
> [INFO]
>
> [INFO] Building parent 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent ---
> [INFO] Deleting file set: /Users/mpilquist/Downloads/site-parent-issue/target
> (included: [**], excluded: [])
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @ parent
> ---
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:2.2
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
> ...
> [INFO]
>
> [INFO] Building parent-usage-test 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent-usage-test
> ---
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @
> parent-usage-test ---
> [INFO] configuring reportPlugin org.apache.maven.plugins:maven-jxr-plugin:2.1
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
> {code}
> Looking at the maven-site-plugin code, it appears the the reportPlugins
> parameter is just a regular array parameter. AFAIK, there's no way to merge
> list configuration items. Other plugins have worked around this by defining
> additional mojo parameters (e.g., maven-eclipse-plugin and buildCommands /
> additionalBuildCommands --
> http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html).
> This isn't the most flexible option though as it only solves 1 level
> inheritance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[
https://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279790#comment-279790
]
Lon Binder edited comment on MECLIPSE-94 at 9/23/11 1:36 PM:
-
Ok, because the will of the maven-eclipse-plugin should not determine the
multi-module folder structure for all projects in the universe, I have created
a complete patch {{MECLIPSE-94-lonbinder.patch}}. Also, I created this patch
off the latest 2.8 code, so it's more up-to-date than previous patch.
Three new config options now available:
* {{includeModulesInClasspath}} - If true the classpath config writer will
include the dependencies of sub-modules in the given project.
* {{alwaysWriteProjectConfig}} - Always create the {{.project}} configuration
for Maven projects regardless of packaging type.
* {{forceTreatAsJavaProject}} - Forces project to be treated as if it was a
Java project. Maven packaging type will therefore be ignored and behaviors will
be as if Java. This includes always creating the {{.classpath}} configuration.
One potential flaw, my implementation of filtering using wildcards in the
includes/excludes paths is immature.
was (Author: lonbinder):
Ok, because the will of the maven-eclipse-plugin should not determine the
multi-module folder structure for all projects in the universe, I have created
a complete patch {{MECLIPSE-94-lonbinder.patch}}.
Three new config options now available:
* {{includeModulesInClasspath}} - If true the classpath config writer will
include the dependencies of sub-modules in the given project.
* {{alwaysWriteProjectConfig}} - Always create the {{.project}} configuration
for Maven projects regardless of packaging type.
* {{forceTreatAsJavaProject}} - Forces project to be treated as if it was a
Java project. Maven packaging type will therefore be ignored and behaviors will
be as if Java. This includes always creating the {{.classpath}} configuration.
One potential flaw, my implementation of filtering using wildcards in the
includes/excludes paths is immature.
> Allow eclipse:eclipse to work on pom (and other) projects
> -
>
> Key: MECLIPSE-94
> URL: https://jira.codehaus.org/browse/MECLIPSE-94
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Felipe Leme
> Attachments: MECLIPSE-94-lonbinder.patch, MECLIPSE-94.patch
>
>
> I'm creating a Java EE project based on the m2book (which I was reviewing;
> it's not available yet...) and one of the projects is a pom-packaging project
> used for integration tests. According to Vincent, currently this project must
> be a pom (in fact, I tried to set it as jar, but then the test phase would be
> run anyway, which would cause the tests to fail), as it doesn't produces a
> jar. But as it has java files (on the src/main/it/java directory), I tried to
> call eclipse:eclipse but it fails, saying that "Not running eclipse plugin
> goal for pom project".
> For these scenarios, I think a propery would be enough. At first I thought
> something about a 'force' or 'forceGeneration' property, would enough, which
> the code change being from:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null )
> to:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !forceGeneration )
> Then I realized there is other place where the pom nature is checked:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !forceGeneration )
> So, I think a better name for the property would be 'javaProject' and the
> change would be:
> final boolean isJavaProjectProperty = // read property; defaults to false...
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !isJavaProjectProperty )
> isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) &&
> !"pom".equals( packaging );
> If nobody objects and someone is willing to apply the changes, I can provide
> such patch (with the proper test cases).
> -- Felipe
> PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features
> already existed :-)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-94) Allow eclipse:eclipse to work on pom (and other) projects
[
https://jira.codehaus.org/browse/MECLIPSE-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lon Binder updated MECLIPSE-94:
---
Attachment: MECLIPSE-94-lonbinder.patch
Ok, because the will of the maven-eclipse-plugin should not determine the
multi-module folder structure for all projects in the universe, I have created
a complete patch {{MECLIPSE-94-lonbinder.patch}}.
Three new config options now available:
* {{includeModulesInClasspath}} - If true the classpath config writer will
include the dependencies of sub-modules in the given project.
* {{alwaysWriteProjectConfig}} - Always create the {{.project}} configuration
for Maven projects regardless of packaging type.
* {{forceTreatAsJavaProject}} - Forces project to be treated as if it was a
Java project. Maven packaging type will therefore be ignored and behaviors will
be as if Java. This includes always creating the {{.classpath}} configuration.
One potential flaw, my implementation of filtering using wildcards in the
includes/excludes paths is immature.
> Allow eclipse:eclipse to work on pom (and other) projects
> -
>
> Key: MECLIPSE-94
> URL: https://jira.codehaus.org/browse/MECLIPSE-94
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Felipe Leme
> Attachments: MECLIPSE-94-lonbinder.patch, MECLIPSE-94.patch
>
>
> I'm creating a Java EE project based on the m2book (which I was reviewing;
> it's not available yet...) and one of the projects is a pom-packaging project
> used for integration tests. According to Vincent, currently this project must
> be a pom (in fact, I tried to set it as jar, but then the test phase would be
> run anyway, which would cause the tests to fail), as it doesn't produces a
> jar. But as it has java files (on the src/main/it/java directory), I tried to
> call eclipse:eclipse but it fails, saying that "Not running eclipse plugin
> goal for pom project".
> For these scenarios, I think a propery would be enough. At first I thought
> something about a 'force' or 'forceGeneration' property, would enough, which
> the code change being from:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null )
> to:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !forceGeneration )
> Then I realized there is other place where the pom nature is checked:
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !forceGeneration )
> So, I think a better name for the property would be 'javaProject' and the
> change would be:
> final boolean isJavaProjectProperty = // read property; defaults to false...
> if ( "pom".equals( packaging ) && eclipseProjectDir == null &&
> !isJavaProjectProperty )
> isJavaProject = isJavaProjectProperty || !"ear".equals( packaging ) &&
> !"pom".equals( packaging );
> If nobody objects and someone is willing to apply the changes, I can provide
> such patch (with the proper test cases).
> -- Felipe
> PS: I'm assigning it to Vincent for now, as he 'dreamed' that such features
> already existed :-)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCOMPILER-21) compiler smarts
[ https://jira.codehaus.org/browse/MCOMPILER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279787#comment-279787 ] Narendra commented on MCOMPILER-21: --- I have following directory for java source code --lion --com test1 --> contains pom.xml and java source code with package com.test1 test2 -> contains pom.cml and java source code with pakage com.test2 when compiler plugin compiles it does directory scanning and compiles only java code that are modified from previous build. But In above directory structure case it recompiles the all source code in subsequent builds. How to overcome this ? I found that it is because of basedirectory do not follow maven standard direcotry layout. Please advise. > compiler smarts > --- > > Key: MCOMPILER-21 > URL: https://jira.codehaus.org/browse/MCOMPILER-21 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Reporter: Brett Porter >Priority: Minor > Fix For: 2.4 > > > there are probably other ways we can make the compiler stale check smarter. > List them out here if you think of them. > 1) if a snapshot was resolved to a newer version, rebuild everything. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEAR-142) bundleFileName ignored when plugin used with multiple profile
bundleFileName ignored when plugin used with multiple profile - Key: MEAR-142 URL: https://jira.codehaus.org/browse/MEAR-142 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.6 Environment: linux, or windows same behaviour maven 2, jdk 1.5 Reporter: Stefano Ghezzi I want to build ear with different sets of modules based on the profiles activated In every profile i have a configuration like this profile1 .. org.apache.maven.plugins maven-ear-plugin 2.6 xxx-yyy xxx-yyy.jar As soon as i use two different profiles the bundleFileName attribute is ignored and ejb/jar/war are packaged with the original filename Only workaround possibile at the moment: have only two profiles replicate all the ejb/jar/war in the two profiles but obviously this is less than optimal bye -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSOURCES-58) Maven Source Plugin does not work if project packaging=bundle (OSGi Bundle)
Maven Source Plugin does not work if project packaging=bundle (OSGi Bundle) --- Key: MSOURCES-58 URL: https://jira.codehaus.org/browse/MSOURCES-58 Project: Maven 2.x Source Plugin Issue Type: Bug Affects Versions: 2.1.2 Reporter: Hendy Irawan With project that configured as such: bundle ... org.apache.felix maven-bundle-plugin true Running mvn source:jar produces: [WARNING] NOT adding sources to artifacts with classifier as Maven only supports one classifier per artifact. Current artifact [id.co.bippo:magento-kettle:bundle:1.1.2-SNAPSHOT] has a [] classifier. It should create a source artifact just fine, the bundle packaging can be treated just like jar packaging. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHARED-208) DefaultSiteTool.getRelativePath does not work between files
DefaultSiteTool.getRelativePath does not work between files
---
Key: MSHARED-208
URL: https://jira.codehaus.org/browse/MSHARED-208
Project: Maven Shared Components
Issue Type: Bug
Components: maven-doxia-tools
Affects Versions: maven-doxia-tools-1.4
Reporter: Lukas Theussl
See test case committed in
[r1174674|http://svn.apache.org/viewvc?rev=1174674&view=rev]. Given
{code}
to = "http://maven.apache.org/downloads.html";;
from = "http://maven.apache.org/index.html";;
{code}
getRelativePath( to, from ) returns "../downloads.html" instead of
"downloads.html". It seems like the 'from' parameter is always supposed to be a
directory. That's confusing and not very useful, also the
[javadocs|http://maven.apache.org/shared/maven-doxia-tools/apidocs/org/apache/maven/doxia/tools/SiteTool.html#getRelativePath%28java.lang.String,%20java.lang.String%29]
state that the method should 'Calculate the relative path between two URLs or
between two files.'.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-324) DependencySet scope runtime includes jars that are scope provided
[
https://jira.codehaus.org/browse/MASSEMBLY-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-324:
--
Description:
I use some jars in provided scope:
{code:xml}
javax.servlet
servlet-api
2.5
provided
{code}
in my assembly, I specify scope as runtime:
{code:xml}
WEB-INF/lib
false
runtime
{code}
Yet I still find the servlet-api-2.5.jar in my WAR. SInce the servlet-api is
scope provided, it should be provided by the container and not included in the
WAR.
was:
I use some jars in provided scope:
javax.servlet
servlet-api
2.5
provided
in my assembly, I specify scope as runtime:
WEB-INF/lib
false
runtime
Yet I still find the servlet-api-2.5.jar in my WAR. SInce the servlet-api is
scope provided, it should be provided by the container and not included in the
WAR.
> DependencySet scope runtime includes jars that are scope provided
> -
>
> Key: MASSEMBLY-324
> URL: https://jira.codehaus.org/browse/MASSEMBLY-324
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
>Reporter: Michael Mattox
>
> I use some jars in provided scope:
> {code:xml}
>
> javax.servlet
> servlet-api
> 2.5
> provided
>
> {code}
> in my assembly, I specify scope as runtime:
> {code:xml}
>
> WEB-INF/lib
> false
> runtime
>
> {code}
> Yet I still find the servlet-api-2.5.jar in my WAR. SInce the servlet-api is
> scope provided, it should be provided by the container and not included in
> the WAR.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-276) pom.properties and pom.xml missing from jar generated by jar-with-dependencies
[
https://jira.codehaus.org/browse/MASSEMBLY-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MASSEMBLY-276:
--
Description:
How to reproduce:
* create a new project with
mvn archetype:create -DgroupId=org.sample -DartifactId=sample2
* modify the pom.xml, adding maven-assembly-plugin configuration (see below)
* run mvn assembly:directory or mvn assemby:assembly
Expected result: the created directory
target/sample2-1.0-SNAPSHOT-jar-with-dependencies.dir or JAR
target/sample2-1.0-SNAPSHOT-jar-with-dependencies.jar should contain files
META-INF/maven/org.sample/sample2/pom.properties and
META-INF/maven/org.sample/sample2/pom.xml,
as in the example in
http://maven.apache.org/plugins/maven-assembly-plugin/usage.html.
Actual result: no pom.xml and pom.properties in the created directory or JAR.
This is the pom.xml:
{code:xml}
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";>
4.0.0
org.sample
sample2
jar
1.0-SNAPSHOT
sample2
http://maven.apache.org
junit
junit
3.8.1
test
maven-assembly-plugin
2.2-beta-1
jar-with-dependencies
pluginrepo
http://repo1.maven.org/maven2
true
true
{code}
was:
How to reproduce:
* create a new project with
mvn archetype:create -DgroupId=org.sample -DartifactId=sample2
* modify the pom.xml, adding maven-assembly-plugin configuration (see below)
* run mvn assembly:directory or mvn assemby:assembly
Expected result: the created directory
target/sample2-1.0-SNAPSHOT-jar-with-dependencies.dir or JAR
target/sample2-1.0-SNAPSHOT-jar-with-dependencies.jar should contain files
META-INF/maven/org.sample/sample2/pom.properties and
META-INF/maven/org.sample/sample2/pom.xml,
as in the example in
http://maven.apache.org/plugins/maven-assembly-plugin/usage.html.
Actual result: no pom.xml and pom.properties in the created directory or JAR.
This is the pom.xml:
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";>
4.0.0
org.sample
sample2
jar
1.0-SNAPSHOT
sample2
http://maven.apache.org
junit
junit
3.8.1
test
maven-assembly-plugin
2.2-beta-1
jar-with-dependencies
pluginrepo
http://repo1.maven.org/maven2
true
true
> pom.properties and pom.xml missing from jar generated by jar-with-dependencies
> --
>
> Key: MASSEMBLY-276
> URL: https://jira.codehaus.org/browse/MASSEMBLY-276
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-1
>Reporter: Jaan Vajakas
>
> How to reproduce:
> * create a new project with
> mvn archetype:create -DgroupId=org.sample -DartifactId=sample2
> * modify the pom.xml, adding maven-assembly-plugin configuration (see below)
> * run mvn assembly:directory or mvn assemby:assembly
> Expected result: the created directory
> target/sample2-1.0-SNAPSHOT-jar-with-dependencies.dir or JAR
> target/sample2-1.0-SNAPSHOT-jar-with-dependencies.jar should contain files
> META-INF/maven/org.sample/sample2/pom.properties and
> META-INF/maven/org.sample/sample2/pom.xml,
> as in the example in
> http://maven.apache.org/plugins/maven-assembly-plugin/usage.html.
> Actual result: no pom.xml and pom.properties in the created directory or JAR.
> This is the pom.xml:
> {code:xml}
> 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";>
> 4.0.0
> org.sample
> sample2
> jar
> 1.0-SNAPSHOT
> sample2
> http://maven.apache.org
>
>
> junit
> junit
> 3.8.1
> test
>
>
>
>
>
> maven-assembly-plugin
> 2.2-beta-1
>
>
> jar-with-dependencies
>
>
>
>
>
>
>
> pluginrepo
> http://repo1.maven.org/maven2
>
> true
>
>
> true
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-600) site plugin 2.4 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279754#comment-279754 ] Lukas Theussl commented on MSITE-600: - I committed a fix that works for me locally (but I expect problems on Windows which I can't test): [r1174614|http://svn.apache.org/viewvc?rev=1174614&view=rev]. 3.1-SNAPSHOT is deployed, any feedback appreciated. > site plugin 2.4 does not permit a child to fully override parent site > deployment URL > > > Key: MSITE-600 > URL: https://jira.codehaus.org/browse/MSITE-600 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.3, 3.0 >Reporter: Benson Margulies >Assignee: Lukas Theussl > Fix For: 3.1 > > Attachments: child-pom.xml, muddle.tar, parent-pom.xml > > > The test cases here has a parent with a a distributionManagement/site/url, > and then a child which overrides it with an absolute URL. Except that the > override does not work ... or, at least, looks quite peculiar. > the parent is file:///tmp/bloop > the child is scp://localhost:/tmp/blop > and the result is > [INFO] Error uploading site > Embedded error: Could not make directory > '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. > [INFO] --- -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-388) Correct classpath ordering in .classpath
[
https://jira.codehaus.org/browse/MECLIPSE-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279752#comment-279752
]
Luc De Graef commented on MECLIPSE-388:
---
Initially, we had many problems during unit tests towards an embedded GF (when
running from within Eclipse).
We used the 2.9-SNAPSHOT build, and all our 'classpath'-issues vanished like
snow for the sun.
Thanks for this solution, it will save us many headaches.
> Correct classpath ordering in .classpath
>
>
> Key: MECLIPSE-388
> URL: https://jira.codehaus.org/browse/MECLIPSE-388
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.4
>Reporter: Siarhei Dudzin
>Assignee: Barrie Treloar
>Priority: Critical
> Fix For: 2.9
>
> Attachments: MECLIPSE-388-it-test.patch, MECLIPSE-388.patch,
> MECLIPSE-388.patch
>
>
> Currently plugin sorts artifacts on its own (alphabetic order???) because the
> order of dependencies that comes from maven is not reliable (random?). This
> breaks tests that use JBoss Embedded which works under maven surefire plugin
> because it still puts dependencies that came first at the beginning of the
> classpath). Apparently not all classpath elements are put in random order. At
> least I get the first ones listed in dependencies also first in the classpath
> (can be seen as ${surefire.test.class.path} and in
> target/surefire-reports/TEST-TestSuite.xml).
> While there is not much we can do for maven eclipse plugin a solution is on
> the way: MNG-1412. When maven 2.0.9 is released maven eclipse plugin can
> revert back to the default classpath order.
> Can we somehow schedule this?
> Another question: is there anyway to put certain dependencies in the first
> place except for renaming them so that alphabetic order does the job?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-484) Support adding and overriding report plugins in new maven-site-plugin 3.x reportPlugins configuration format
[
https://jira.codehaus.org/browse/MSITE-484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=279743#comment-279743
]
Andreas Sewe commented on MSITE-484:
FWIW, it would be great if the {{mergePolicy.children}} and
{{mergePolicy.removeDuplicates}} attributes (and also {{combine.children}})
could finally become part of the POM's XML Schema:
http://maven.apache.org/xsd/maven-4.0.0.xsd. It's quite annoying to see
validation errors on elements like {{developers}}, which would benefit from
this feature and are specified by the XSD (unlike, e.g., the plugins'
{{configuration}} which is {{xsd:any}}), because these attributes are not part
of the XSD.
On a related note: Why not use XML Namespaces for {{mergePolicy.*}}? Verbosity
can't be the only reason; after all, it's one {{xmlns}} declaration + a short
prefix like {{mp}} vs. the longer {{mergePolicy}} on every attribute.
> Support adding and overriding report plugins in new maven-site-plugin 3.x
> reportPlugins configuration format
>
>
> Key: MSITE-484
> URL: https://jira.codehaus.org/browse/MSITE-484
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: inheritance, Maven 3
>Affects Versions: 3.0-beta-1, 3.0-beta-2, 3.0-beta-3
> Environment: 3.0-beta-1-SNAPSHOT
>Reporter: Michael Pilquist
>Assignee: Olivier Lamy
> Fix For: 3.1
>
> Attachments: MSITE-484.patch, site-cfg-inheritance.zip
>
>
> When using the new configuration format for reportPlugins, it appears that
> there's no way to:
> - Add a report plugin to a submodule
> - Override the configuration of a report plugin in a submodule
> Using the old section, both of these use cases were supported.
> For large, multi-module builds, it is problematic having to respecify all
> reporting plugins in any submodule pom that needs to either add an additional
> reporting plugin or change the configuration of a reporting plugin.
> Attached is a sample project that has a parent POM configured with
> project-info-reports and javadoc plugin and a submodule configured with jxr
> plugin and javadoc plugin. The relevant output is here:
> {code}
> [INFO]
>
> [INFO] Building parent 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent ---
> [INFO] Deleting file set: /Users/mpilquist/Downloads/site-parent-issue/target
> (included: [**], excluded: [])
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @ parent
> ---
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-project-info-reports-plugin:2.2
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
> ...
> [INFO]
>
> [INFO] Building parent-usage-test 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-clean-plugin:2.3:clean (default-clean) @ parent-usage-test
> ---
> [INFO]
> [INFO] --- maven-site-plugin:3.0-beta-1-SNAPSHOT:site (default-site) @
> parent-usage-test ---
> [INFO] configuring reportPlugin org.apache.maven.plugins:maven-jxr-plugin:2.1
> [INFO] configuring reportPlugin
> org.apache.maven.plugins:maven-javadoc-plugin:2.6.1
> {code}
> Looking at the maven-site-plugin code, it appears the the reportPlugins
> parameter is just a regular array parameter. AFAIK, there's no way to merge
> list configuration items. Other plugins have worked around this by defining
> additional mojo parameters (e.g., maven-eclipse-plugin and buildCommands /
> additionalBuildCommands --
> http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html).
> This isn't the most flexible option though as it only solves 1 level
> inheritance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
