[jira] [Created] (MSHADE-231) Multiple shade artifacts + reduced pom from the same artifact
Romain Manni-Bucau created MSHADE-231: - Summary: Multiple shade artifacts + reduced pom from the same artifact Key: MSHADE-231 URL: https://issues.apache.org/jira/browse/MSHADE-231 Project: Maven Shade Plugin Issue Type: Improvement Reporter: Romain Manni-Bucau Hi guys, in tomee we create several flavors of tomee-embedded from tomee-embedded module. We basically deploy: - tomee-embedded normal jar - tomee-embedded "uber" shade - tomee-embedded "jaxws" shade - tomee-embedded "jaxrs" shade We would add few more flavors if we can solve this issue: we can't get reduced pom and attach it to let our users depend on the reduced pom. Best would be to: 1- have the reduced pom created in target/ 2- attach it to deploy it with another artifact (to avoid pom conflicts) is that something mvn-shade could do? Here is the pom: https://github.com/apache/tomee/blob/master/tomee/tomee-embedded/pom.xml#L55 Side note: the obvious fix it to define 1 pom by shade but it would make the maintenance harder for us and create inconsistencies long term. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MCHECKSTYLE-324) cleanup debug "error messages" when using inline checkstyle rules (on windows)
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MCHECKSTYLE-324:
---
Summary: cleanup debug "error messages" when using inline checkstyle rules
(on windows) (was: inline checkstyle rules fails on windows)
> cleanup debug "error messages" when using inline checkstyle rules (on windows)
> --
>
> Key: MCHECKSTYLE-324
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-324
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Minor
>
> Seems
> {code}
> configLocation = rulesFiles.getAbsolutePath();
> {code}
> should be
> {code}
> configLocation = rulesFiles.toURI().toURL().toExternalForm();
> {code}
> should use a URI instead of a file path for windows otherwise you get
> {code}
> [DEBUG] URLResourceLoader: Exception when looking for
> 'C:\cygwin\drone\src\github.com\rmannibucau\crest\target\checkstyle-rules.xml'
> at ''
> java.net.MalformedURLException: unknown protocol: c
> at java.net.URL.(URL.java:600)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:71)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfigFile(DefaultCheckstyleExecutor.java:822)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:378)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:217)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:538)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCHECKSTYLE-324) inline checkstyle rules fails on windows
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15352982#comment-15352982
]
Romain Manni-Bucau commented on MCHECKSTYLE-324:
just this pom.xml should reproduce it:
{code}
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/xsd/maven-4.0.0.xsd";>
4.0.0
MCHECKSTYLE-324
MCHECKSTYLE-324
1.0-SNAPSHOT
org.apache.maven.plugins
maven-checkstyle-plugin
2.17
provided
org.apache.maven.plugins
maven-compiler-plugin
3.5.1
1.8
1.8
org.apache.maven.plugins
maven-checkstyle-plugin
2.17
verify-style
process-classes
check
{code}
you need to run in debug and see that the checkstyle mojo line:
{code}
File configFile = locator.getResourceAsFile( request.getConfigLocation(),
"checkstyle-checker.xml" );
{code}
likely go through org.codehaus.plexus.resource.loader.URLResourceLoader before
jar then FileResourceLoader which pollutes logs with this message.
The case of File being trivial enough to check it would be great to be able to
get rid of it
Note: I'll update the title since it is misleading
> inline checkstyle rules fails on windows
>
>
> Key: MCHECKSTYLE-324
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-324
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Minor
>
> Seems
> {code}
> configLocation = rulesFiles.getAbsolutePath();
> {code}
> should be
> {code}
> configLocation = rulesFiles.toURI().toURL().toExternalForm();
> {code}
> should use a URI instead of a file path for windows otherwise you get
> {code}
> [DEBUG] URLResourceLoader: Exception when looking for
> 'C:\cygwin\drone\src\github.com\rmannibucau\crest\target\checkstyle-rules.xml'
> at ''
> java.net.MalformedURLException: unknown protocol: c
> at java.net.URL.(URL.java:600)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:71)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfigFile(DefaultCheckstyleExecutor.java:822)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:378)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:217)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:538)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (MCHECKSTYLE-324) inline checkstyle rules fails on windows
[
https://issues.apache.org/jira/browse/MCHECKSTYLE-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MCHECKSTYLE-324:
---
Priority: Minor (was: Major)
> inline checkstyle rules fails on windows
>
>
> Key: MCHECKSTYLE-324
> URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-324
> Project: Maven Checkstyle Plugin
> Issue Type: Bug
>Reporter: Romain Manni-Bucau
>Priority: Minor
>
> Seems
> {code}
> configLocation = rulesFiles.getAbsolutePath();
> {code}
> should be
> {code}
> configLocation = rulesFiles.toURI().toURL().toExternalForm();
> {code}
> should use a URI instead of a file path for windows otherwise you get
> {code}
> [DEBUG] URLResourceLoader: Exception when looking for
> 'C:\cygwin\drone\src\github.com\rmannibucau\crest\target\checkstyle-rules.xml'
> at ''
> java.net.MalformedURLException: unknown protocol: c
> at java.net.URL.(URL.java:600)
> at java.net.URL.(URL.java:490)
> at java.net.URL.(URL.java:439)
> at
> org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:71)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
> at
> org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfigFile(DefaultCheckstyleExecutor.java:822)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:378)
> at
> org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:217)
> at
> org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:538)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MCHECKSTYLE-324) inline checkstyle rules fails on windows
Romain Manni-Bucau created MCHECKSTYLE-324:
--
Summary: inline checkstyle rules fails on windows
Key: MCHECKSTYLE-324
URL: https://issues.apache.org/jira/browse/MCHECKSTYLE-324
Project: Maven Checkstyle Plugin
Issue Type: Bug
Reporter: Romain Manni-Bucau
Seems
{code}
configLocation = rulesFiles.getAbsolutePath();
{code}
should be
{code}
configLocation = rulesFiles.toURI().toURL().toExternalForm();
{code}
should use a URI instead of a file path for windows otherwise you get
{code}
[DEBUG] URLResourceLoader: Exception when looking for
'C:\cygwin\drone\src\github.com\rmannibucau\crest\target\checkstyle-rules.xml'
at ''
java.net.MalformedURLException: unknown protocol: c
at java.net.URL.(URL.java:600)
at java.net.URL.(URL.java:490)
at java.net.URL.(URL.java:439)
at
org.codehaus.plexus.resource.loader.URLResourceLoader.getResource(URLResourceLoader.java:71)
at
org.codehaus.plexus.resource.DefaultResourceManager.getResource(DefaultResourceManager.java:159)
at
org.codehaus.plexus.resource.DefaultResourceManager.getResourceAsFile(DefaultResourceManager.java:91)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfigFile(DefaultCheckstyleExecutor.java:822)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.getConfiguration(DefaultCheckstyleExecutor.java:378)
at
org.apache.maven.plugin.checkstyle.exec.DefaultCheckstyleExecutor.executeCheckstyle(DefaultCheckstyleExecutor.java:217)
at
org.apache.maven.plugin.checkstyle.CheckstyleViolationCheckMojo.execute(CheckstyleViolationCheckMojo.java:538)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5994) add explicit ordering support for plugins
Romain Manni-Bucau created MNG-5994: --- Summary: add explicit ordering support for plugins Key: MNG-5994 URL: https://issues.apache.org/jira/browse/MNG-5994 Project: Maven Issue Type: New Feature Affects Versions: 3.3.9 Reporter: Romain Manni-Bucau Hi On one side maven doesn't really support plugin ordering in a deterministic manner (on some doc the merging mecanism states it follows the pom ordering but with some exceptions making a pom rarely deterministic and user friendly or at a very very high cost when pom hierarchy + profile are there). On another side it is more and more common to need to add some custom processing (another plugin, a main through mvn-exec or a groovy script) between 2 plugins. Very common use cases are frontend optimizations, documentation generation etc... That's why I'd like maven to support an explicit ordering. It can be as easy as adding to plugin a before/after tag(s) referring execution id of another plugin. This would allow end users to explicitly control their whole build chain without having to hack maven with either meta-tasks, custom mojo or worse custom lifecycle. This would also finally allows users to remove workaround using wrong phases to ensure of the ordering for instance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MRELEASE-943) be more tolerant with project version
Romain Manni-Bucau created MRELEASE-943:
---
Summary: be more tolerant with project version
Key: MRELEASE-943
URL: https://issues.apache.org/jira/browse/MRELEASE-943
Project: Maven Release Plugin
Issue Type: Bug
Reporter: Romain Manni-Bucau
In current version of maven-release-manager, the project version is quite
strict and several cases are not handled preventing mvn release plugin to be
used:
1- version aliases (${project.version}), it can
makes sense to use that in some projects and is sometimes a way to avoid to
spend nights rewriting multiple poms. This is ignored in hierarchic projects
(at least 2 or 3 levels).
2- children not listing the parent. If the parent list children and children
doesn't list the parent cause the goal is to let them be checkout directly then
the child version is not handled by the mvn release plugin at all.
3- support autoVersionModules with multiple versions (just removing SNAPSHOT
instead of applying parent version to all poms)
Would be great to at least have a flag to support 2 and detect properly or have
a list of tolerated expressions as alias of the project version in the plugin
(= tolerate 1). 3 is a nice to have.
Note: if it can help tomee project does it and the number of poms - ~251 poms
(144 follow rule 2) - justified historically the rule 1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MCOMPILER-197) dependencies no more at classpath
[ https://issues.apache.org/jira/browse/MCOMPILER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15134645#comment-15134645 ] Romain Manni-Bucau commented on MCOMPILER-197: -- Well not really, being said it is a *regression* it needs to be fixed and can get a flag to switch it off/on. > dependencies no more at classpath > - > > Key: MCOMPILER-197 > URL: https://issues.apache.org/jira/browse/MCOMPILER-197 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Romain Manni-Bucau > Attachments: compiler-test.zip > > > before (version 2.5.1) dependencies of compiler plugin were added to javac > classpath, now it seems (didn't check so maybe it is wrong) it is no more the > case > i attached a sample. Running "mvn compile" with version 2.5.1 you'll get a > file target/generated-sources/org/issue/Person_.java. With version 3.0 you > get a folder target/annotations and no more file. > This is really blocking for stuff like openjpa metamodel generation where > with version 3.0 it needs to use an ant task which is not so straight forward. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCOMPILER-256) annotation processors not escaped
[ https://issues.apache.org/jira/browse/MCOMPILER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069770#comment-15069770 ] Romain Manni-Bucau commented on MCOMPILER-256: -- [~agudian] yep, seems the explanation Gunnar gave. Thanks to have had a look! > annotation processors not escaped > - > > Key: MCOMPILER-256 > URL: https://issues.apache.org/jira/browse/MCOMPILER-256 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Romain Manni-Bucau >Assignee: Andreas Gudian > > annotation processors name can contain interpreted characters in the command > line, it should be quoted > (http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.plexus/plexus-compiler-javac/2.5/org/codehaus/plexus/compiler/javac/JavacCompiler.java#255) > Sample: lombok processor is an inner class so 'foo$bar' name so under UNIx it > is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCOMPILER-256) annotation processors not escaped
[ https://issues.apache.org/jira/browse/MCOMPILER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15069692#comment-15069692 ] Romain Manni-Bucau commented on MCOMPILER-256: -- [~agudian] here it is https://github.com/rmannibucau/lombokmapstruct > annotation processors not escaped > - > > Key: MCOMPILER-256 > URL: https://issues.apache.org/jira/browse/MCOMPILER-256 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Romain Manni-Bucau >Assignee: Andreas Gudian > > annotation processors name can contain interpreted characters in the command > line, it should be quoted > (http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.plexus/plexus-compiler-javac/2.5/org/codehaus/plexus/compiler/javac/JavacCompiler.java#255) > Sample: lombok processor is an inner class so 'foo$bar' name so under UNIx it > is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCOMPILER-256) annotation processors not escaped
[ https://issues.apache.org/jira/browse/MCOMPILER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15055100#comment-15055100 ] Romain Manni-Bucau commented on MCOMPILER-256: -- OS: MacOS or Ubuntu Project: simply 2 pojo with @Data and a mapstruct mapper mapping a single property of these pojos without any getter/setter (or said otherwise using lombok generated getter/setter) > annotation processors not escaped > - > > Key: MCOMPILER-256 > URL: https://issues.apache.org/jira/browse/MCOMPILER-256 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Romain Manni-Bucau >Assignee: Andreas Gudian > > annotation processors name can contain interpreted characters in the command > line, it should be quoted > (http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.plexus/plexus-compiler-javac/2.5/org/codehaus/plexus/compiler/javac/JavacCompiler.java#255) > Sample: lombok processor is an inner class so 'foo$bar' name so under UNIx it > is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCOMPILER-256) annotation processors not escaped
[ https://issues.apache.org/jira/browse/MCOMPILER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054997#comment-15054997 ] Romain Manni-Bucau commented on MCOMPILER-256: -- On mac os https://github.com/mapstruct/mapstruct/issues/510#issuecomment-164172815 is not deterministic and reliable - build fails/suceeds without changing anything > annotation processors not escaped > - > > Key: MCOMPILER-256 > URL: https://issues.apache.org/jira/browse/MCOMPILER-256 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Romain Manni-Bucau >Assignee: Andreas Gudian > > annotation processors name can contain interpreted characters in the command > line, it should be quoted > (http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.plexus/plexus-compiler-javac/2.5/org/codehaus/plexus/compiler/javac/JavacCompiler.java#255) > Sample: lombok processor is an inner class so 'foo$bar' name so under UNIx it > is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MCOMPILER-256) annotation processors not escaped
[ https://issues.apache.org/jira/browse/MCOMPILER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15054874#comment-15054874 ] Romain Manni-Bucau commented on MCOMPILER-256: -- [~agudian] only got the issue on UNIx where '$' means something. On Windows "'" means something so the solution will be OS dependent I guess. > annotation processors not escaped > - > > Key: MCOMPILER-256 > URL: https://issues.apache.org/jira/browse/MCOMPILER-256 > Project: Maven Compiler Plugin > Issue Type: Bug >Affects Versions: 3.3 >Reporter: Romain Manni-Bucau >Assignee: Andreas Gudian > > annotation processors name can contain interpreted characters in the command > line, it should be quoted > (http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.plexus/plexus-compiler-javac/2.5/org/codehaus/plexus/compiler/javac/JavacCompiler.java#255) > Sample: lombok processor is an inner class so 'foo$bar' name so under UNIx it > is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (MCOMPILER-256) annotation processors not escaped
Romain Manni-Bucau created MCOMPILER-256: Summary: annotation processors not escaped Key: MCOMPILER-256 URL: https://issues.apache.org/jira/browse/MCOMPILER-256 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 3.3 Reporter: Romain Manni-Bucau annotation processors name can contain interpreted characters in the command line, it should be quoted (http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.plexus/plexus-compiler-javac/2.5/org/codehaus/plexus/compiler/javac/JavacCompiler.java#255) Sample: lombok processor is an inner class so 'foo$bar' name so under UNIx it is broken. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MRELEASE-897) support multiple release versions
Romain Manni-Bucau created MRELEASE-897: --- Summary: support multiple release versions Key: MRELEASE-897 URL: https://jira.codehaus.org/browse/MRELEASE-897 Project: Maven Release Plugin Issue Type: Improvement Reporter: Romain Manni-Bucau In some project multiple versions are used (tomee release = tomee + openejb releases for instance). It is not always possible to split the project in sub projects and then it is not possible to use maven release plugin. Idea would be to support a whitelist of artifacts (a list of patterns would be great). org.superbiz.component:*:1.0.1 org.superbiz.component:*:4.5.8 For instance or even: org.superbiz.component:*:@major.@minor.@patch org.superbiz.component:*:(@major + 3).@minor.@patch to avoid to change it for each release. This of course would imply the CLI to ask for the multiple versions and not only one even when autoSubModules is set to true (it would just group by versions) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-897) support multiple release versions
[
https://jira.codehaus.org/browse/MRELEASE-897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MRELEASE-897:
Description:
In some project multiple versions are used (tomee release = tomee + openejb
releases for instance). It is not always possible to split the project in sub
projects and then it is not possible to use maven release plugin. Idea would be
to support a whitelist of artifacts (a list of patterns would be great).
{code}
org.superbiz.component:*:1.0.1
org.superbiz.component:*:4.5.8
{code}
For instance or even:
{code}
org.superbiz.component:*:@major.@minor.@patch
org.superbiz.component:*:(@major +
3).@minor.@patch
{code}
to avoid to change it for each release.
This of course would imply the CLI to ask for the multiple versions and not
only one even when autoSubModules is set to true (it would just group by
versions)
was:
In some project multiple versions are used (tomee release = tomee + openejb
releases for instance). It is not always possible to split the project in sub
projects and then it is not possible to use maven release plugin. Idea would be
to support a whitelist of artifacts (a list of patterns would be great).
org.superbiz.component:*:1.0.1
org.superbiz.component:*:4.5.8
For instance or even:
org.superbiz.component:*:@major.@minor.@patch
org.superbiz.component:*:(@major +
3).@minor.@patch
to avoid to change it for each release.
This of course would imply the CLI to ask for the multiple versions and not
only one even when autoSubModules is set to true (it would just group by
versions)
> support multiple release versions
> -
>
> Key: MRELEASE-897
> URL: https://jira.codehaus.org/browse/MRELEASE-897
> Project: Maven Release Plugin
> Issue Type: Improvement
>Reporter: Romain Manni-Bucau
>
> In some project multiple versions are used (tomee release = tomee + openejb
> releases for instance). It is not always possible to split the project in sub
> projects and then it is not possible to use maven release plugin. Idea would
> be to support a whitelist of artifacts (a list of patterns would be great).
> {code}
>
> org.superbiz.component:*:1.0.1
> org.superbiz.component:*:4.5.8
>
> {code}
> For instance or even:
> {code}
>
>
> org.superbiz.component:*:@major.@minor.@patch
> org.superbiz.component:*:(@major +
> 3).@minor.@patch
>
> {code}
> to avoid to change it for each release.
> This of course would imply the CLI to ask for the multiple versions and not
> only one even when autoSubModules is set to true (it would just group by
> versions)
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-267) maven merge policy breaks checkstyle inline configuration
Romain Manni-Bucau created MCHECKSTYLE-267: -- Summary: maven merge policy breaks checkstyle inline configuration Key: MCHECKSTYLE-267 URL: https://jira.codehaus.org/browse/MCHECKSTYLE-267 Project: Maven Checkstyle Plugin Issue Type: Bug Affects Versions: 2.13 Reporter: Romain Manni-Bucau This is surely a bug in maven itself since it appears in effective pom but please redirect and link this issue if you think so (it can be worked around in checkstyle plugin and I'm not sure maven cares) Issue is: you have a pom and a child pom. Both configure checkstyle "inline" (ie without checkstyle.xml but directly in ). In this case maven merge both configs (great) but tag by tag. it means if both checkstyle configs dont have the same modules then configuraiton is broken and the child module config can slip to another module for instance. Workaround would be to get raw config of both pom and do the merge in the plugin. Correct solution IMO is to consider attribute values during maven merge. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
[
https://jira.codehaus.org/browse/MCHECKSTYLE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MCHECKSTYLE-211:
---
Attachment: CHECKSTYLE-inlineCDATA.patch
oops, previous patch got tabulations, sorry. Fixed with this one.
> allow inline configuration for checkstyle plugin
>
>
> Key: MCHECKSTYLE-211
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
> Attachments: CHECKSTYLE-inlineCDATA.patch,
> CHECKSTYLE-inlineCDATA.patch, CHECKSTYLE-inline.patch
>
>
> Make possible to not rely on an external module or file:
> {code}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> @pom.version@
>
>
> check
> process-resources
>
> check
>
>
>
>
>
> Checker
>
>
> TreeWalker
>
>
> EmptyBlock
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
[
https://jira.codehaus.org/browse/MCHECKSTYLE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MCHECKSTYLE-211:
---
Description:
Make possible to not rely on an external module or file:
{code}
org.apache.maven.plugins
maven-checkstyle-plugin
@pom.version@
check
process-resources
check
Checker
TreeWalker
EmptyBlock
{code}
or (better) this one:
{code}
true
{code}
was:
Make possible to not rely on an external module or file:
{code}
org.apache.maven.plugins
maven-checkstyle-plugin
@pom.version@
check
process-resources
check
Checker
TreeWalker
EmptyBlock
{code}
> allow inline configuration for checkstyle plugin
>
>
> Key: MCHECKSTYLE-211
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
> Attachments: CHECKSTYLE-inlineCDATA.patch,
> CHECKSTYLE-inlineCDATA.patch, CHECKSTYLE-inline.patch
>
>
> Make possible to not rely on an external module or file:
> {code}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> @pom.version@
>
>
> check
> process-resources
>
> check
>
>
>
>
>
> Checker
>
>
> TreeWalker
>
>
> EmptyBlock
>
>
>
>
>
>
>
> {code}
> or (better) this one:
> {code}
>
> true
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
[
https://jira.codehaus.org/browse/MCHECKSTYLE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Manni-Bucau updated MCHECKSTYLE-211:
---
Attachment: CHECKSTYLE-inlineCDATA.patch
patch using cdata to allow to reuse exact same syntax as checkstyle.xml (better
IMO)
> allow inline configuration for checkstyle plugin
>
>
> Key: MCHECKSTYLE-211
> URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
> Project: Maven Checkstyle Plugin
> Issue Type: New Feature
>Reporter: Romain Manni-Bucau
> Attachments: CHECKSTYLE-inlineCDATA.patch, CHECKSTYLE-inline.patch
>
>
> Make possible to not rely on an external module or file:
> {code}
>
> org.apache.maven.plugins
> maven-checkstyle-plugin
> @pom.version@
>
>
> check
> process-resources
>
> check
>
>
>
>
>
> Checker
>
>
> TreeWalker
>
>
> EmptyBlock
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHECKSTYLE-211) allow inline configuration for checkstyle plugin
Romain Manni-Bucau created MCHECKSTYLE-211:
--
Summary: allow inline configuration for checkstyle plugin
Key: MCHECKSTYLE-211
URL: https://jira.codehaus.org/browse/MCHECKSTYLE-211
Project: Maven Checkstyle Plugin
Issue Type: New Feature
Reporter: Romain Manni-Bucau
Attachments: CHECKSTYLE-inline.patch
Make possible to not rely on an external module or file:
{code}
org.apache.maven.plugins
maven-checkstyle-plugin
@pom.version@
check
process-resources
check
Checker
TreeWalker
EmptyBlock
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCOMPILER-197) dependencies no more at classpath
[ https://jira.codehaus.org/browse/MCOMPILER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318796#comment-318796 ] Romain Manni-Bucau commented on MCOMPILER-197: -- it works Olivier, thanks. > dependencies no more at classpath > - > > Key: MCOMPILER-197 > URL: https://jira.codehaus.org/browse/MCOMPILER-197 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Romain Manni-Bucau > Attachments: compiler-test.zip > > > before (version 2.5.1) dependencies of compiler plugin were added to javac > classpath, now it seems (didn't check so maybe it is wrong) it is no more the > case > i attached a sample. Running "mvn compile" with version 2.5.1 you'll get a > file target/generated-sources/org/issue/Person_.java. With version 3.0 you > get a folder target/annotations and no more file. > This is really blocking for stuff like openjpa metamodel generation where > with version 3.0 it needs to use an ant task which is not so straight forward. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-197) dependencies no more at classpath
[ https://jira.codehaus.org/browse/MCOMPILER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318785#comment-318785 ] Romain manni-Bucau commented on MCOMPILER-197: -- Apache Maven 3.1.0 (r1413381; 2012-11-25 19:04:49+0100) Maven home: /opt/softs/Apache/apache-maven-3.1.0 Java version: 1.6.0_30, vendor: Sun Microsystems Inc. Java home: /opt/softs/java/jdk1.6.0_30/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.5.0-17-generic", arch: "amd64", family: "unix" > dependencies no more at classpath > - > > Key: MCOMPILER-197 > URL: https://jira.codehaus.org/browse/MCOMPILER-197 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Romain manni-Bucau > Attachments: compiler-test.zip > > > before (version 2.5.1) dependencies of compiler plugin were added to javac > classpath, now it seems (didn't check so maybe it is wrong) it is no more the > case > i attached a sample. Running "mvn compile" with version 2.5.1 you'll get a > file target/generated-sources/org/issue/Person_.java. With version 3.0 you > get a folder target/annotations and no more file. > This is really blocking for stuff like openjpa metamodel generation where > with version 3.0 it needs to use an ant task which is not so straight forward. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-197) dependencies no more at classpath
[ https://jira.codehaus.org/browse/MCOMPILER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317926#comment-317926 ] Romain manni-Bucau commented on MCOMPILER-197: -- 3.0.4 > dependencies no more at classpath > - > > Key: MCOMPILER-197 > URL: https://jira.codehaus.org/browse/MCOMPILER-197 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Romain manni-Bucau > Attachments: compiler-test.zip > > > before (version 2.5.1) dependencies of compiler plugin were added to javac > classpath, now it seems (didn't check so maybe it is wrong) it is no more the > case > i attached a sample. Running "mvn compile" with version 2.5.1 you'll get a > file target/generated-sources/org/issue/Person_.java. With version 3.0 you > get a folder target/annotations and no more file. > This is really blocking for stuff like openjpa metamodel generation where > with version 3.0 it needs to use an ant task which is not so straight forward. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-197) dependencies no more at classpath
[ https://jira.codehaus.org/browse/MCOMPILER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317857#comment-317857 ] Romain manni-Bucau commented on MCOMPILER-197: -- weird, i have target/generated-sources/org/issue/Person_.java with 2.5.1 > dependencies no more at classpath > - > > Key: MCOMPILER-197 > URL: https://jira.codehaus.org/browse/MCOMPILER-197 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Romain manni-Bucau > Attachments: compiler-test.zip > > > before (version 2.5.1) dependencies of compiler plugin were added to javac > classpath, now it seems (didn't check so maybe it is wrong) it is no more the > case > i attached a sample. Running "mvn compile" with version 2.5.1 you'll get a > file target/generated-sources/org/issue/Person_.java. With version 3.0 you > get a folder target/annotations and no more file. > This is really blocking for stuff like openjpa metamodel generation where > with version 3.0 it needs to use an ant task which is not so straight forward. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-197) dependencies no more at classpath
[ https://jira.codehaus.org/browse/MCOMPILER-197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317850#comment-317850 ] Romain manni-Bucau commented on MCOMPILER-197: -- Hi Olivier, with v2.5.1 it was generated. basically any java 6 processor is now skipped (there are workaround with other plugins but that's a regression) > dependencies no more at classpath > - > > Key: MCOMPILER-197 > URL: https://jira.codehaus.org/browse/MCOMPILER-197 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Romain manni-Bucau > Attachments: compiler-test.zip > > > before (version 2.5.1) dependencies of compiler plugin were added to javac > classpath, now it seems (didn't check so maybe it is wrong) it is no more the > case > i attached a sample. Running "mvn compile" with version 2.5.1 you'll get a > file target/generated-sources/org/issue/Person_.java. With version 3.0 you > get a folder target/annotations and no more file. > This is really blocking for stuff like openjpa metamodel generation where > with version 3.0 it needs to use an ant task which is not so straight forward. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MCOMPILER-197) dependencies no more at classpath
Romain manni-Bucau created MCOMPILER-197: Summary: dependencies no more at classpath Key: MCOMPILER-197 URL: https://jira.codehaus.org/browse/MCOMPILER-197 Project: Maven 2.x Compiler Plugin Issue Type: Bug Affects Versions: 3.0 Reporter: Romain manni-Bucau Attachments: compiler-test.zip before (version 2.5.1) dependencies of compiler plugin were added to javac classpath, now it seems (didn't check so maybe it is wrong) it is no more the case i attached a sample. Running "mvn compile" with version 2.5.1 you'll get a file target/generated-sources/org/issue/Person_.java. With version 3.0 you get a folder target/annotations and no more file. This is really blocking for stuff like openjpa metamodel generation where with version 3.0 it needs to use an ant task which is not so straight forward. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-942) surefire + testng suite doesn't do anything
[
https://jira.codehaus.org/browse/SUREFIRE-942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316223#comment-316223
]
Romain manni-Bucau commented on SUREFIRE-942:
-
worked for me, thanks
> surefire + testng suite doesn't do anything
> ---
>
> Key: SUREFIRE-942
> URL: https://jira.codehaus.org/browse/SUREFIRE-942
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.12.4
>Reporter: Romain manni-Bucau
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
> Attachments: surefire-testng.zip
>
>
> In OpenEJB project we use surefire to run a testng suite (xml file) but no
> test files are in src/test/java (all is in dependencies).
> When we run tests against surefire 2.12.4 nothing is done.
> Here the debug output:
> {code}
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ cdi-embedded ---
> [DEBUG] org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:2.0.9:compile
> [DEBUG]org.apache.maven.surefire:surefire-booter:jar:2.12.4:compile
> [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.12.4:compile
> [DEBUG]org.apache.maven.surefire:maven-surefire-common:jar:2.12.4:compile
> [DEBUG] org.apache.commons:commons-lang3:jar:3.1:compile
> [DEBUG]
> org.apache.maven.shared:maven-common-artifact-filters:jar:1.3:compile
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.8:compile
> [DEBUG]org.apache.maven:maven-artifact:jar:2.0.9:compile
> [DEBUG]org.apache.maven:maven-project:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-settings:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-model:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-plugin-registry:jar:2.0.9:compile
> [DEBUG]
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
> [DEBUG] junit:junit:jar:3.8.1:test (scope managed from compile)
> [DEBUG]org.apache.maven:maven-core:jar:2.0.9:compile
> [DEBUG]
> org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9:compile
> [DEBUG] org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-error-diagnostics:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-plugin-descriptor:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-monitor:jar:2.0.9:compile
> [DEBUG] classworlds:classworlds:jar:1.1:compile
> [DEBUG]org.apache.maven:maven-toolchain:jar:2.0.9:compile
> [DEBUG]
> org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.1:compile
> [DEBUG] Created new class realm
> plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> [DEBUG] Importing foreign packages into class realm
> plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> [DEBUG] Imported: < project>org.apache.openejb:cdi-embedded:1.5.2-SNAPSHOT
> [DEBUG] Populating class realm
> plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> [DEBUG] Included: org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4
> [DEBUG] Included: org.apache.maven.surefire:surefire-booter:jar:2.12.4
> [DEBUG] Included: org.apache.maven.surefire:surefire-api:jar:2.12.4
> [DEBUG] Included: org.apache.maven.surefire:maven-surefire-common:jar:2.12.4
> [DEBUG] Included: org.apache.commons:commons-lang3:jar:3.1
> [DEBUG] Included:
> org.apache.maven.shared:maven-common-artifact-filters:jar:1.3
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:3.0.8
> [DEBUG] Included: org.apache.maven.reporting:maven-reporting-api:jar:2.0.9
> [DEBUG] Included:
> org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.1
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.9
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Excluded: junit:junit:jar:3.8.1
> [DEBUG] Excluded: org.apache.maven:maven-core:jar:2.0.9
> [DEBUG] Excluded:
> org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-
[jira] (SUREFIRE-942) surefire + testng suite doesn't do anything
[
https://jira.codehaus.org/browse/SUREFIRE-942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain manni-Bucau updated SUREFIRE-942:
Attachment: surefire-testng.zip
just play with the surefire version in this pom 2.12 (works)/2.12.4 (doesn't
work)
> surefire + testng suite doesn't do anything
> ---
>
> Key: SUREFIRE-942
> URL: https://jira.codehaus.org/browse/SUREFIRE-942
> Project: Maven Surefire
> Issue Type: Bug
> Components: TestNG support
>Affects Versions: 2.12.4
>Reporter: Romain manni-Bucau
> Attachments: surefire-testng.zip
>
>
> In OpenEJB project we use surefire to run a testng suite (xml file) but no
> test files are in src/test/java (all is in dependencies).
> When we run tests against surefire 2.12.4 nothing is done.
> Here the debug output:
> {code}
> [INFO]
> [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ cdi-embedded ---
> [DEBUG] org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4:
> [DEBUG]org.apache.maven:maven-plugin-api:jar:2.0.9:compile
> [DEBUG]org.apache.maven.surefire:surefire-booter:jar:2.12.4:compile
> [DEBUG] org.apache.maven.surefire:surefire-api:jar:2.12.4:compile
> [DEBUG]org.apache.maven.surefire:maven-surefire-common:jar:2.12.4:compile
> [DEBUG] org.apache.commons:commons-lang3:jar:3.1:compile
> [DEBUG]
> org.apache.maven.shared:maven-common-artifact-filters:jar:1.3:compile
> [DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.8:compile
> [DEBUG]org.apache.maven:maven-artifact:jar:2.0.9:compile
> [DEBUG]org.apache.maven:maven-project:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-settings:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-profile:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-model:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-plugin-registry:jar:2.0.9:compile
> [DEBUG]
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
> [DEBUG] junit:junit:jar:3.8.1:test (scope managed from compile)
> [DEBUG]org.apache.maven:maven-core:jar:2.0.9:compile
> [DEBUG]
> org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9:compile
> [DEBUG] org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-error-diagnostics:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-plugin-descriptor:jar:2.0.9:compile
> [DEBUG] org.apache.maven:maven-monitor:jar:2.0.9:compile
> [DEBUG] classworlds:classworlds:jar:1.1:compile
> [DEBUG]org.apache.maven:maven-toolchain:jar:2.0.9:compile
> [DEBUG]
> org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.1:compile
> [DEBUG] Created new class realm
> plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> [DEBUG] Importing foreign packages into class realm
> plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> [DEBUG] Imported: < project>org.apache.openejb:cdi-embedded:1.5.2-SNAPSHOT
> [DEBUG] Populating class realm
> plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
> [DEBUG] Included: org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4
> [DEBUG] Included: org.apache.maven.surefire:surefire-booter:jar:2.12.4
> [DEBUG] Included: org.apache.maven.surefire:surefire-api:jar:2.12.4
> [DEBUG] Included: org.apache.maven.surefire:maven-surefire-common:jar:2.12.4
> [DEBUG] Included: org.apache.commons:commons-lang3:jar:3.1
> [DEBUG] Included:
> org.apache.maven.shared:maven-common-artifact-filters:jar:1.3
> [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:3.0.8
> [DEBUG] Included: org.apache.maven.reporting:maven-reporting-api:jar:2.0.9
> [DEBUG] Included:
> org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.1
> [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.9
> [DEBUG] Excluded:
> org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
> [DEBUG] Excluded: junit:junit:jar:3.8.1
> [DEBUG] Excluded: org.apache.maven:maven-core:jar:2.0.9
> [DEBUG] Excluded:
> org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9
> [DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.
[jira] (SUREFIRE-942) surefire + testng suite doesn't do anything
Romain manni-Bucau created SUREFIRE-942:
---
Summary: surefire + testng suite doesn't do anything
Key: SUREFIRE-942
URL: https://jira.codehaus.org/browse/SUREFIRE-942
Project: Maven Surefire
Issue Type: Bug
Components: TestNG support
Affects Versions: 2.12.4
Reporter: Romain manni-Bucau
In OpenEJB project we use surefire to run a testng suite (xml file) but no test
files are in src/test/java (all is in dependencies).
When we run tests against surefire 2.12.4 nothing is done.
Here the debug output:
{code}
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ cdi-embedded ---
[DEBUG] org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4:
[DEBUG]org.apache.maven:maven-plugin-api:jar:2.0.9:compile
[DEBUG]org.apache.maven.surefire:surefire-booter:jar:2.12.4:compile
[DEBUG] org.apache.maven.surefire:surefire-api:jar:2.12.4:compile
[DEBUG]org.apache.maven.surefire:maven-surefire-common:jar:2.12.4:compile
[DEBUG] org.apache.commons:commons-lang3:jar:3.1:compile
[DEBUG]
org.apache.maven.shared:maven-common-artifact-filters:jar:1.3:compile
[DEBUG]org.codehaus.plexus:plexus-utils:jar:3.0.8:compile
[DEBUG]org.apache.maven:maven-artifact:jar:2.0.9:compile
[DEBUG]org.apache.maven:maven-project:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-settings:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-profile:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-model:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-artifact-manager:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-plugin-registry:jar:2.0.9:compile
[DEBUG]
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1:compile
[DEBUG] junit:junit:jar:3.8.1:test (scope managed from compile)
[DEBUG]org.apache.maven:maven-core:jar:2.0.9:compile
[DEBUG]
org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9:compile
[DEBUG] org.apache.maven.reporting:maven-reporting-api:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-repository-metadata:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-error-diagnostics:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-plugin-descriptor:jar:2.0.9:compile
[DEBUG] org.apache.maven:maven-monitor:jar:2.0.9:compile
[DEBUG] classworlds:classworlds:jar:1.1:compile
[DEBUG]org.apache.maven:maven-toolchain:jar:2.0.9:compile
[DEBUG]
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.1:compile
[DEBUG] Created new class realm
plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
[DEBUG] Importing foreign packages into class realm
plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
[DEBUG] Imported: < project>org.apache.openejb:cdi-embedded:1.5.2-SNAPSHOT
[DEBUG] Populating class realm
plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12.4
[DEBUG] Included: org.apache.maven.plugins:maven-surefire-plugin:jar:2.12.4
[DEBUG] Included: org.apache.maven.surefire:surefire-booter:jar:2.12.4
[DEBUG] Included: org.apache.maven.surefire:surefire-api:jar:2.12.4
[DEBUG] Included: org.apache.maven.surefire:maven-surefire-common:jar:2.12.4
[DEBUG] Included: org.apache.commons:commons-lang3:jar:3.1
[DEBUG] Included:
org.apache.maven.shared:maven-common-artifact-filters:jar:1.3
[DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:3.0.8
[DEBUG] Included: org.apache.maven.reporting:maven-reporting-api:jar:2.0.9
[DEBUG] Included:
org.apache.maven.plugin-tools:maven-plugin-annotations:jar:3.1
[DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-artifact:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-project:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-settings:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-profile:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-model:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-artifact-manager:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-plugin-registry:jar:2.0.9
[DEBUG] Excluded:
org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1
[DEBUG] Excluded: junit:junit:jar:3.8.1
[DEBUG] Excluded: org.apache.maven:maven-core:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-plugin-parameter-documenter:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-repository-metadata:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-error-diagnostics:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-plugin-descriptor:jar:2.0.9
[DEBUG] Excluded: org.apache.maven:maven-monitor:jar:2.0.9
[DEBUG] Excluded: classworlds:classworlds:jar:1.1
[DEBUG] Excluded: org.apache.maven:maven-toolchain:jar:2.0.9
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-surefire-plugin:2.12.4:test from plugin realm
ClassRealm[plugin>org.apache.maven.plugins:maven-suref
[jira] (MNG-5247) be able to propagate the proxy from settings.xml to plugins
[ https://jira.codehaus.org/browse/MNG-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315093#comment-315093 ] Romain manni-Bucau commented on MNG-5247: - Hmm, not sure it can be done for all plugin (got the need for dockbook and ant plugins) Moreover i use a script to switch proxy in my conf file so the pain is just when it is not propagated in my builds > be able to propagate the proxy from settings.xml to plugins > --- > > Key: MNG-5247 > URL: https://jira.codehaus.org/browse/MNG-5247 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: Romain manni-Bucau > Attachments: MAVEN-PLUGINS-PROXY.diff > > > can be nice if plugins could get proxies defined in settings.xml. > for surefire a way to do it without modifying the plugin is to set proxy > information in user properties (otherwise it doesn't work in forked mode) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5327) set *failOnMissingWebXml* to false by default for maven war plugin
Romain manni-Bucau created MNG-5327: --- Summary: set *failOnMissingWebXml* to false by default for maven war plugin Key: MNG-5327 URL: https://jira.codehaus.org/browse/MNG-5327 Project: Maven 2 & 3 Issue Type: Improvement Components: Plugins and Lifecycle Reporter: Romain manni-Bucau Since now web.xml is optional it is a pain to have the default to true. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-782) Properties defined in a child pom hide all the properties defined in the parent pom while performing release:prepare
[
https://jira.codehaus.org/browse/MRELEASE-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305297#comment-305297
]
Romain manni-Bucau commented on MRELEASE-782:
-
seems linked to line 538 in
http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/AbstractRewritePomsPhase.java
"Element property = properties.getChild( expression, properties.getNamespace()
);"
the else explicit this issue:
"
// the expression used to define the version of this artifact may be inherited
// TODO needs a better error message, what pom? what dependency?
throw new ReleaseFailureException( "The version could not be updated: " +
rawVersion );
"
but why isn't it fixed? At least an option to ignore the value and keep it
could be fine (typically a variable to define a version doesn't need any update)
> Properties defined in a child pom hide all the properties defined in the
> parent pom while performing release:prepare
>
>
> Key: MRELEASE-782
> URL: https://jira.codehaus.org/browse/MRELEASE-782
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: Any
>Reporter: Marius Dumitru Florea
>
> Suppose you have this two poms:
> {code:title=Parent POM}
> ...
>
> 1.6
>
> ...
> {code}
> {code:title=Child POM}
> ...
>
> ...
>
> ...
>
>
> ...
> ${my.version}
>
>
>
> ...
> {code}
> Running release:prepare on this works just fine. Now, if we add a
> {{properties}} section with any property to the child pom we get:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on
> project XYZ: The version could not be updated: ${my.version} -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare
> (default-cli) on project XYZ: The version could not be updated: ${my.version}
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> Caused by: org.apache.maven.plugin.MojoFailureException: The version could
> not be updated: ${commons.version}
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:299)
> at
> org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> ... 19 more
> Caused by: org.apache.maven.shared.release.ReleaseFailureException: The
> version could not be updated: ${my.version}
> at
> org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.rewriteArtifactVersions(AbstractRewritePomsPhase.java:578)
> at
> org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocum
[jira] (MNG-5247) be able to propagate the proxy from settings.xml to plugins
[ https://jira.codehaus.org/browse/MNG-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain manni-Bucau updated MNG-5247: Attachment: MAVEN-PLUGINS-PROXY.diff attached plugin was generated from https://svn.apache.org/repos/asf/maven/plugins/trunk it adds maven-proxy-plugin > be able to propagate the proxy from settings.xml to plugins > --- > > Key: MNG-5247 > URL: https://jira.codehaus.org/browse/MNG-5247 > Project: Maven 2 & 3 > Issue Type: New Feature >Reporter: Romain manni-Bucau > Attachments: MAVEN-PLUGINS-PROXY.diff > > > can be nice if plugins could get proxies defined in settings.xml. > for surefire a way to do it without modifying the plugin is to set proxy > information in user properties (otherwise it doesn't work in forked mode) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5247) be able to propagate the proxy from settings.xml to plugins
Romain manni-Bucau created MNG-5247: --- Summary: be able to propagate the proxy from settings.xml to plugins Key: MNG-5247 URL: https://jira.codehaus.org/browse/MNG-5247 Project: Maven 2 & 3 Issue Type: New Feature Reporter: Romain manni-Bucau can be nice if plugins could get proxies defined in settings.xml. for surefire a way to do it without modifying the plugin is to set proxy information in user properties (otherwise it doesn't work in forked mode) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
