[jira] (MEJB-56) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEJB-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar updated MEJB-56: -- Attachment: MEJB-56_onlymaincode.patch > Add Maven version used to Created-By entry in manifest > -- > > Key: MEJB-56 > URL: https://jira.codehaus.org/browse/MEJB-56 > Project: Maven 2.x EJB Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEJB-56_onlymaincode.patch, MEJB-56.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MEJB-56) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEJB-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289598#comment-289598 ] Anders Hammar commented on MEJB-56: --- Yes Dennis, that's right. I was a little bit worried that the patch wouldn't work. Not sure my Eclipse does the svn renaming correctly. I've attached a new patch that only includes the main code changes. Apply that and fix the IT manually, please! > Add Maven version used to Created-By entry in manifest > -- > > Key: MEJB-56 > URL: https://jira.codehaus.org/browse/MEJB-56 > Project: Maven 2.x EJB Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEJB-56_onlymaincode.patch, MEJB-56.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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-799) Allow test parallelisation when forkMode=always
[
https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289606#comment-289606
]
Alexey Yudichev commented on SUREFIRE-799:
--
Thanks nkeywal, one question if you don't mind. I want surefire to fork X JVMs
and then spread the tests across them evenly without re-launching new JVM for
every test. Look like this:{code:xml}
perthread
2
{code}
runs at most 2 JVMs but still launches new JVM instance for every test. Is it
possible to reuse JVMs? Our integration tests are heavy to initialise and their
initialisation is statically defined, so to avoid re-initialisation there
should be JVM reuse.
> Allow test parallelisation when forkMode=always
> ---
>
> Key: SUREFIRE-799
> URL: https://jira.codehaus.org/browse/SUREFIRE-799
> Project: Maven Surefire
> Issue Type: New Feature
> Components: process forking
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
> Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch
>
>
> Surefire already allows:
> - forking
> - parallelization within a JVM
> Mixing both features would mean forking multiple JVM instead of only one.
> It would allow to parallelize tests that need to be executed in a separate
> JVM (i.e.: with forkMode=always). Usually these tests take longer than the
> simple ones. In our case, 40% of the tests are executed in 4 minutes, the
> other 60% need two hours. So it's obviously more interesting to parallelize
> the former, but these ones need to fork.
--
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-799) Allow test parallelisation when forkMode=always
[
https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289606#comment-289606
]
Alexey Yudichev edited comment on SUREFIRE-799 at 1/25/12 4:35 AM:
---
Thanks nkeywal, one question if you don't mind. I want surefire to fork X JVMs
and then spread the tests across them evenly without re-launching new JVM for
every test. Looks like this:{code:xml}
perthread
2
{code}
runs at most 2 JVMs but still launches new JVM instance for every test. Is it
possible to reuse JVMs? Our integration tests are heavy to initialise and their
initialisation is statically defined, so to avoid re-initialisation there
should be JVM reuse.
was (Author: ylexus):
Thanks nkeywal, one question if you don't mind. I want surefire to fork X
JVMs and then spread the tests across them evenly without re-launching new JVM
for every test. Look like this:{code:xml}
perthread
2
{code}
runs at most 2 JVMs but still launches new JVM instance for every test. Is it
possible to reuse JVMs? Our integration tests are heavy to initialise and their
initialisation is statically defined, so to avoid re-initialisation there
should be JVM reuse.
> Allow test parallelisation when forkMode=always
> ---
>
> Key: SUREFIRE-799
> URL: https://jira.codehaus.org/browse/SUREFIRE-799
> Project: Maven Surefire
> Issue Type: New Feature
> Components: process forking
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
> Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch
>
>
> Surefire already allows:
> - forking
> - parallelization within a JVM
> Mixing both features would mean forking multiple JVM instead of only one.
> It would allow to parallelize tests that need to be executed in a separate
> JVM (i.e.: with forkMode=always). Usually these tests take longer than the
> simple ones. In our case, 40% of the tests are executed in 4 minutes, the
> other 60% need two hours. So it's obviously more interesting to parallelize
> the former, but these ones need to fork.
--
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-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289612#comment-289612 ] nkeywal commented on SUREFIRE-799: -- Yes, I confirm it will relaunch a new jvm for each test. Kristian's comment above says "reusable forks" are in the roadmap. It's not something we need, so I didn't look at it when I implemented the patch. BTW you can parallelize the tests with forkMode=once, and in this case the jvm is not recreated. > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Fix For: 2.12 > > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- 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-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289618#comment-289618 ] Alexey Yudichev commented on SUREFIRE-799: -- Yes, but forkMode=once will only parallelise tests within same JVM using multiple threads, which will not work for us as our tests are inherently not thread safe. We need "1 thread multiple JVMs" type of parallelisation with JVM reuse. I'll think of some workaround in this case. > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Fix For: 2.12 > > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- 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-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289622#comment-289622 ] Kristian Rosenvold commented on SUREFIRE-799: - Re-using VM's is a planned feature, but someone has to implement it ;) > Allow test parallelisation when forkMode=always > --- > > Key: SUREFIRE-799 > URL: https://jira.codehaus.org/browse/SUREFIRE-799 > Project: Maven Surefire > Issue Type: New Feature > Components: process forking >Affects Versions: 2.10 > Environment: all >Reporter: nkeywal >Assignee: Kristian Rosenvold > Fix For: 2.12 > > Attachments: surefire_799_212_trunk.patch, surefire_799.v2.patch > > > Surefire already allows: > - forking > - parallelization within a JVM > Mixing both features would mean forking multiple JVM instead of only one. > It would allow to parallelize tests that need to be executed in a separate > JVM (i.e.: with forkMode=always). Usually these tests take longer than the > simple ones. In our case, 40% of the tests are executed in 4 minutes, the > other 60% need two hours. So it's obviously more interesting to parallelize > the former, but these ones need to fork. -- 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] (MDEPLOY-143) deploy-file goal insists on deploying javadoc file for previous deploy-file execution
JF created MDEPLOY-143:
--
Summary: deploy-file goal insists on deploying javadoc file for
previous deploy-file execution
Key: MDEPLOY-143
URL: https://jira.codehaus.org/browse/MDEPLOY-143
Project: Maven 2.x and 3.x Deploy Plugin
Issue Type: Bug
Affects Versions: 2.7
Environment: Windows Server 2008 32bit
jdk 1.6.0_27-b07
Reporter: JF
Priority: Minor
I have a pom which I use to package some third party jars to deploy to a local
nexus.
However it always fails with the second upload. It seems as if it is always
picking up the javadoc associated with the first deploy-file execution,
eventhough I have not specified this.
Is this a bug, or what am I doing wrong?
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
a.b.c
vendorx_jdbc_driver_wrapper
0.0.1-SNAPSHOT
pom
${basedir}/files/11.2.0.1.0/jdbc/javadoc.zip
${basedir}/files/11.2.0.1.0/jdbc/javadoctemp
${basedir}/files/11.2.0.1.0/jdbc/javadoctemp/thejavadocs.jar
org.apache.maven.plugins
maven-antrun-plugin
1.2
prepare
validate
run
org.apache.maven.plugins
maven-install-plugin
2.3.1
install-library-main
install
install-file
${basedir}/files/11.2.0.1.0/jdbc/lib/vjdbc99.jar
a.b.c.com.vendorx
vjdbc99
11.2.0.1.0
jar
true
install-javadocs-main
install
install-file
${vendorx_jdbc_driver_wrapper.javadocfile}
a.b.c.com.vendorx
vjdbc99
11.2.0.1.0
jar
javadoc
install-library-debug
install
install-file
${basedir}/files/11.2.0.1.0/jdbc/lib/vjdbc99_g.jar
a.b.c.com.vendorx
vjdbc99_g
11.2.0.1.0
jar
true
[jira] (MSHARED-222) Update the dependency on commons-validator
Eugen Paraschiv created MSHARED-222: --- Summary: Update the dependency on commons-validator Key: MSHARED-222 URL: https://jira.codehaus.org/browse/MSHARED-222 Project: Maven Shared Components Issue Type: Improvement Components: maven-reporting-impl Affects Versions: maven-reporting-impl-2.1 Reporter: Eugen Paraschiv The current dependency on commons-validator is out of date, an upgrade may make sense at this point. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289635#comment-289635 ] Alex Halovanic commented on MEAR-146: - You've got it exactly. Definitely a bug in WebLogic. I am working on putting together a bug report with Oracle, but from past experience, if they don't first tell me this is intended behavior, they won't release a fix to others since it's not a security flaw. > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.8 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[
https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289642#comment-289642
]
Stephane Nicoll commented on MEAR-146:
--
In that case, I prefer a weblogic configuration option, like we've done for
JBoss. Your patch is a too wide option that sole purpose is to workaround a bug.
Something like
{code:xml}
false
{code}
> Expose parameter to not write library-directory element in application.xml
> --
>
> Key: MEAR-146
> URL: https://jira.codehaus.org/browse/MEAR-146
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
>Affects Versions: 2.8
> Environment: Oracle WebLogic
>Reporter: Alex Halovanic
>Priority: Minor
> Attachments: ear-remove-librarydirectory-IT.patch,
> ear-remove-librarydirectory.patch
>
>
> The current handling of defaultLibBundleDir leads to some issues on Oracle
> Weblogic 10+. The Ear plugin currently sets library-directory to the value
> of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's
> classloading features break (specifically "Generic File Loading") when this
> element is set. defaultLibBundleDir has to be set to APP-INF/lib since this
> is the magic library folder for WebLogic.
> The patch adds a parameter to prevent setting library-directory for cases
> like this.
--
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-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289646#comment-289646
]
John Casey commented on SUREFIRE-809:
-
In revId 1235805:
Just added tests to verify the grouping expressions work both in JUnit and
TestNG. The implementation for TestNG offends my design sensibilities, but I
didn't have many options for injecting the group-expression matcher logic.
In the end, I had to split out the group-expression support into a separate
module, and handle it much the same way the testng-utils artifact is
handled...injected directly into the test classpath for testng tests. There was
a tad more fine tuning related to the new integration tests too, but it's
pretty minor.
This feature should be complete now.
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support, TestNG support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
> Fix For: 2.12
>
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey updated SUREFIRE-809:
Component/s: TestNG support
Fix Version/s: 2.12
Assignee: John Casey
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support, TestNG support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
>Assignee: John Casey
> Fix For: 2.12
>
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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-809) Implement boolean expression to define test group to be run.
[
https://jira.codehaus.org/browse/SUREFIRE-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed SUREFIRE-809.
---
Resolution: Fixed
Ready to go into the next release attempt for 2.12.
> Implement boolean expression to define test group to be run.
>
>
> Key: SUREFIRE-809
> URL: https://jira.codehaus.org/browse/SUREFIRE-809
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.x support, TestNG support
>Affects Versions: 2.11
>Reporter: Ondrej Zizka
>Assignee: John Casey
> Fix For: 2.12
>
> Attachments: BooleanExpression.g, category-expression.jj
>
>
> This is an alternative to SUREFIRE-808.
> Instead of having hard-coded filtering structure combining two lists.
> an expression could be parsed and evaluated for each test.
> Each test would be "tagged" using
> {code}
> @Categories({ MyCateg1.class, MyCateg2.class, ... })
> {code}
> Surefire's `group` config param would be an expression like:
> {code}
> ( Ejb AND (CommonCriteria OR Security) ) AND NOT( Clustering )
> {code}
> Presence of a category of given name would be evaluated as true, absence of
> it as false.
> Interface inheritance would be taken into account.
> This mechanism would provide unlimited possibilities of grouping tests, and
> would be very beneficial for huge testuites counting thousands of tests.
--
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-808) Selectable "grouping mode" for test groups - UNION or INTERSECTION.
[
https://jira.codehaus.org/browse/SUREFIRE-808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed SUREFIRE-808.
---
Resolution: Won't Fix
Assignee: John Casey
Implemented SUREFIRE-809 instead, to provide a richer set of options for
selecting groups...also has the advantage of not introducing new parameters to
a plugin that already has a nest of them.
> Selectable "grouping mode" for test groups - UNION or INTERSECTION.
> ---
>
> Key: SUREFIRE-808
> URL: https://jira.codehaus.org/browse/SUREFIRE-808
> Project: Maven Surefire
> Issue Type: New Feature
> Components: Junit 4.7+ (parallel) support, Junit 4.x support
>Affects Versions: 2.10, 2.11
>Reporter: Ondrej Zizka
>Assignee: John Casey
>
> Currently, the `groups` and `excludedGroups` work like:
> {code}
> ( include1 OR include2 ... ) AND NOT ( exclude1 OR exclude2 OR ... )
> {code}
> This doesn't cover many usecases. For instance, if the groups overlap.
> Example: user needs to run only EJB tests under security manager, while only
> some EJB tests can run under security manager.
> In such case, this is needed:
> {code}
> ( EJB AND SecurityManager )
> {code}
> The suggestion is to introduce two new params:
> {code}
> groupingMode = union|intersection
> excludeGroupingMode = union|intersection
> {code}
> They would switch AND and OR behavior.
> Union would be the default (preserving current behavior).
> Would be implemented in a filter, see:
> https://github.com/apache/maven-surefire/blob/trunk/surefire-providers/common-junit48/src/main/java/org/apache/maven/surefire/common/junit48/FilterFactory.java#L115
--
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] (ARCHETYPE-399) optionnal modules in multi modules archetype
Olivier Lamy created ARCHETYPE-399:
--
Summary: optionnal modules in multi modules archetype
Key: ARCHETYPE-399
URL: https://jira.codehaus.org/browse/ARCHETYPE-399
Project: Maven Archetype
Issue Type: New Feature
Components: Creator, Plugin
Reporter: Olivier Lamy
The goal is to have optional modules in the project generation.
in archetype-metadata.xml
{code}
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MEJB-56) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEJB-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289677#comment-289677 ] Dennis Lundberg commented on MEJB-56: - Thanks for the patches! The onlymaincode patch was applied in [r1235931|http://svn.apache.org/viewvc?view=revision&revision=1235931] and manual modification of the IT was done in [r1235935|http://svn.apache.org/viewvc?view=revision&revision=1235935]. Can you make sure that I got the manual modifications right? > Add Maven version used to Created-By entry in manifest > -- > > Key: MEJB-56 > URL: https://jira.codehaus.org/browse/MEJB-56 > Project: Maven 2.x EJB Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEJB-56_onlymaincode.patch, MEJB-56.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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] (MPMD-115) Add PMD/CPD report-only goal
[ https://jira.codehaus.org/browse/MPMD-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPMD-115. Resolution: Incomplete > Add PMD/CPD report-only goal > > > Key: MPMD-115 > URL: https://jira.codehaus.org/browse/MPMD-115 > Project: Maven 2.x PMD Plugin > Issue Type: Improvement > Environment: PHP >Reporter: Lionel Sengkouvanh > > PHP tools can generate pmd.xml and cpd.xml. > But instead of using these files, Maven PMD plugin instead of overwrite them > with empty ones. -- 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] (MPMD-94) Ignores ruleset in multiproject build
[
https://jira.codehaus.org/browse/MPMD-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MPMD-94.
---
Resolution: Incomplete
> Ignores ruleset in multiproject build
> -
>
> Key: MPMD-94
> URL: https://jira.codehaus.org/browse/MPMD-94
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
> Components: PMD
>Affects Versions: 2.4
> Environment: Maven version: 2.0.9
> Java version: 1.6.0_11
> OS name: "linux" version: "2.6.24-23-generic" arch: "i386" Family: "unix"
>Reporter: Charlie Collins
>
> I have several projects that use a custom ruleset file and work perfectly
> fine on their own. Once added as modules to a multiproject build however,
> the pmd:check goal fails these projects using rules that are NOT IN my custom
> ruleset - appears to ignore the ruleset in multiproject build.
>
> Standard single Maven project:
> {noformat}
> mvn -X pmd:check
> . . . .
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-pmd-plugin:2.4:pmd'
> -->
> [DEBUG] (f) aggregate = false
> [DEBUG] (f) compileSourceRoots =
> [/data/ccollins/projects/axioma-model/src/main/java]
> [DEBUG] (f) excludes = [Ljava.lang.String;@118fa47
> [DEBUG] (f) format = xml
> [DEBUG] (f) includeTests = false
> [DEBUG] (f) linkXRef = true
> [DEBUG] (f) minimumPriority = 5
> [DEBUG] (f) outputDirectory =
> /data/ccollins/projects/axioma-model/target/site
> [DEBUG] (f) project = MavenProject: com.axiomainc:axioma-model:0.3-SNAPSHOT
> @ /data/ccollins/projects/axioma-model/pom.xml
> [DEBUG] (f) reactorProjects = [MavenProject:
> com.axiomainc:axioma-model:0.3-SNAPSHOT @
> /data/ccollins/projects/axioma-model/pom.xml]
> [DEBUG] (s) rulesets = [Ljava.lang.String;@1dee400
> [DEBUG] (f) skip = false
> [DEBUG] (f) targetDirectory = /data/ccollins/projects/axioma-model/target
> [DEBUG] (f) targetJdk = 1.5
> [DEBUG] (f) testSourceRoots =
> [/data/ccollins/projects/axioma-model/src/test/java]
> [DEBUG] (f) xrefLocation =
> /data/ccollins/projects/axioma-model/target/site/xref
> [DEBUG] (f) xrefTestLocation =
> /data/ccollins/projects/axioma-model/target/site/xref-test
> [DEBUG] -- end configuration --
> [INFO] [pmd:pmd]
> [DEBUG] Preparing ruleset:
> /data/ccollins/projects/axioma-model/standards/AxiomaPMDConfig-Strict.xml
> [DEBUG] Before:
> /data/ccollins/projects/axioma-model/standards/AxiomaPMDConfig-Strict.xml
> After: AxiomaPMDConfig-Strict.xml
> [DEBUG] Exclusions:
> **/*~,**/#*#,**/.#*,**/%*%,**/._*,**/CVS,**/CVS/**,**/.cvsignore,**/SCCS,**/SCCS/**,**/vssver.scc,**/.svn,**/.svn/**,**/.arch-ids,**/.arch-ids/**,**/.bzr,**/.bzr/**,**/.MySCMServerInfo,**/.DS_Store,**/*Example.*
> [DEBUG] Inclusions: **/*.java
> [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e.
> build is platform dependent!
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-pmd-plugin:2.4:check' -->
> [DEBUG] (f) aggregate = false
> [DEBUG] (f) failOnViolation = true
> [DEBUG] (f) failurePriority = 5
> [DEBUG] (f) language = java
> [DEBUG] (f) project = MavenProject: com.axiomainc:axioma-model:0.3-SNAPSHOT
> @ /data/ccollins/projects/axioma-model/pom.xml
> [DEBUG] (f) skip = false
> [DEBUG] (f) targetDirectory = /data/ccollins/projects/axioma-model/target
> [DEBUG] (f) verbose = true
> [DEBUG] -- end configuration --
> [INFO] [pmd:check]
> [INFO]
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Fri Feb 20 13:12:03 EST 2009
> [INFO] Final Memory: 7M/82M
> [INFO]
>
> {noformat}
>
> Simple multi module project WITH ONLY ONE MODULE - the same project as the
> previous example that works:
> {noformat}
> mvn -X clean pmd:check
> . . . .
> [DEBUG] (f) reactorProjects = [MavenProject:
> com.axiomainc:axioma-common-utils:0.3-SNAPSHOT @
> /data/ccollins/projects/axioma-common-utils/pom.xml, MavenProject:
> com.axiomainc:PanaceaMultiproject:1.0-SNAPSHOT @
> /data/ccollins/projects/axioma-PanaceaMultiProject/pom.xml]
> [DEBUG] (s) rulesets = [Ljava.lang.String;@8f9a32
> [DEBUG] (f) skip = false
> [DEBUG] (f) targetDirectory =
> /data/ccollins/projects/axioma-common-utils/target
> [DEBUG] (f) targetJdk = 1.5
> [DEBUG] (f) testSourceRoots =
> [/data/ccollins/projects/axioma-common-utils/src/test/java]
> [DEBUG] (f) xrefLocation =
> /data/ccollins/projects/axioma-common-utils/target/site/xref
> [DEBUG] (f) xrefTestLocation =
> /data/ccollins/projects/axioma-common-utils/target/site/xref-test
> [DEBUG] -- end configuration --
> [INFO] [pmd:pmd]
> [DEBUG] Preparing ruleset:
> /data/
[jira] (MPMD-81) Alow to generate a report with a specific XSL
[ https://jira.codehaus.org/browse/MPMD-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPMD-81. --- Resolution: Won't Fix The Maven plugin creates a standard Maven report for PMD that integrates nicely into a Maven-generated site. If you really want to create a "custom" report you could use an XSLT-capable plugin, like XML Maven Plugin, that would work on the xml file that PMD generates. http://mojo.codehaus.org/xml-maven-plugin/ > Alow to generate a report with a specific XSL > - > > Key: MPMD-81 > URL: https://jira.codehaus.org/browse/MPMD-81 > Project: Maven 2.x PMD Plugin > Issue Type: New Feature > Components: PMD >Affects Versions: 2.3 > Environment: ALL >Reporter: Fabio Retzlaff >Priority: Critical > > PMD supports the -xslt parameter to generate a custom report. > It is very useful if maven pmd plugin could support this feature. -- 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] (MPMD-68) Add new CPD report for test source code
[ https://jira.codehaus.org/browse/MPMD-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MPMD-68. --- Resolution: Won't Fix I don't see any reason to have separate reports. If you turn on includeTests I imagine that you really want to check the test code as well. > Add new CPD report for test source code > --- > > Key: MPMD-68 > URL: https://jira.codehaus.org/browse/MPMD-68 > Project: Maven 2.x PMD Plugin > Issue Type: Wish > Components: CPD >Affects Versions: 2.2 >Reporter: Antoine Véret > > In order to keep clean the test source code, and maximize the application > maintainability, a additionnal CPD report should be added, this could help to > avoid any test code duplication. > The current situation does not provide a clear separation between production > source code and test source code (when adding "includeTests" parameter) -- 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] (MPMD-130) excludeRoot doesn't work in site build on multi-module projects
[
https://jira.codehaus.org/browse/MPMD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289684#comment-289684
]
Dennis Lundberg commented on MPMD-130:
--
Can someone please provide a sample project that shows this issue?
> excludeRoot doesn't work in site build on multi-module projects
> ---
>
> Key: MPMD-130
> URL: https://jira.codehaus.org/browse/MPMD-130
> Project: Maven 2.x PMD Plugin
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Marcel Stör
>
> The parent POM of my multi-module setup says
>
> 1.6
>
> target/generated-sources
>
>
> If I run {{mvn pmd:cpd}} or {{mvn site}} directly on the module that actually
> has generated code the report is as expected. The files in
> {{target/generated-sources}} are ignored. Also, if I run {{mvn pmd:cpd}} at
> root level outside all the modules the report is fine.
> However, if I run {{mvn site}} at root level outside all the modules the
> excludeRoot is ignored.
--
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] (MPMD-140) Require Maven 2.2.1
Dennis Lundberg created MPMD-140: Summary: Require Maven 2.2.1 Key: MPMD-140 URL: https://jira.codehaus.org/browse/MPMD-140 Project: Maven 2.x PMD Plugin Issue Type: Task Reporter: Dennis Lundberg To avoid Doxia-problems when generating reports we need to update the Maven prerequisite to version 2.2.1. -- 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] (MPIR-239) Brazillian Portuguese translation
Daniel Teleginski Camargo created MPIR-239: -- Summary: Brazillian Portuguese translation Key: MPIR-239 URL: https://jira.codehaus.org/browse/MPIR-239 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Daniel Teleginski Camargo Priority: Minor Attachments: project-info-report_pt_BR.properties Missing parts for the new version. -- 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] (MEAR-146) Expose parameter to not write library-directory element in application.xml
[ https://jira.codehaus.org/browse/MEAR-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289710#comment-289710 ] Alex Halovanic commented on MEAR-146: - Well, fair enough, I'm not too happy about an option just for working around a bug. But you did bring up the point that library-directory would only get written if defaultLibDirectory is set. Can I ask, is there a reason why JARs are written to the root by default? From http://java.sun.com/xml/ns/javaee/application_5.xsd: "If this element [library-directory] isn't specified, the directory named "lib" is searched." Should jars be written to lib/ by default instead of the root? It seems to be the expected location according to the spec and would seem to eliminate the need for defining defaultLibDirectory in most cases. > Expose parameter to not write library-directory element in application.xml > -- > > Key: MEAR-146 > URL: https://jira.codehaus.org/browse/MEAR-146 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.8 > Environment: Oracle WebLogic >Reporter: Alex Halovanic >Priority: Minor > Attachments: ear-remove-librarydirectory-IT.patch, > ear-remove-librarydirectory.patch > > > The current handling of defaultLibBundleDir leads to some issues on Oracle > Weblogic 10+. The Ear plugin currently sets library-directory to the value > of defaultLibBundleDir in the application.xml for EARs v5+. Some of Oracle's > classloading features break (specifically "Generic File Loading") when this > element is set. defaultLibBundleDir has to be set to APP-INF/lib since this > is the magic library folder for WebLogic. > The patch adds a parameter to prevent setting library-directory for cases > like this. -- 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] (MEJB-56) Add Maven version used to Created-By entry in manifest
[ https://jira.codehaus.org/browse/MEJB-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=289721#comment-289721 ] Anders Hammar commented on MEJB-56: --- Yes, verified that it all looks good. You may close the ticket. > Add Maven version used to Created-By entry in manifest > -- > > Key: MEJB-56 > URL: https://jira.codehaus.org/browse/MEJB-56 > Project: Maven 2.x EJB Plugin > Issue Type: Improvement >Affects Versions: 2.3 > Environment: n/a >Reporter: Anders Hammar > Attachments: MEJB-56_onlymaincode.patch, MEJB-56.patch > > > Upgrade the dependency to org.apache.maven:maven-archiver to newer version > (when released) to get the version of Maven Core used for building included > in the Created-By manifest entry. The call to MavenArchiver also needs to be > slightly updated to pass along the MavenSession. -- 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
