[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross closed SUREFIRE-952. -- Resolution: Not A Bug > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > Attachments: surefire-952.zip > > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318489#comment-318489 ] Henning Gross commented on MINSTALL-94: --- Actually I dont get the behaviour with the pom-packaging because the pom needs to be interpreted anyway. Feels like a bug to me. But has nothing to do with mvn-install. You have been a great help. Thank you. > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross >Assignee: Robert Scholte > Attachments: MINSTALL-94.patch, MINSTALL-94.zip, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross updated MINSTALL-94: -- Attachment: MINSTALL-94.zip > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch, MINSTALL-94.zip, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318482#comment-318482 ] Henning Gross commented on MINSTALL-94: --- Someone at some point thought that the build should break on test failure as well. Someone did have a valid use-case and that when the option to not fail the build on test failure was added. Some time later (not long ago) surefire introduced another parameter to not fail if not tests werde found for a specified filter. Just to proof thath making behaviour configurable is not that uncommon. What you say about package seems to be true. I thought so before, then did a test run which succeeded and I did not question why. Maybe I simply forgot to run clean (me idiot). I just set up a test project and it was as expected and stated by you. The maven3-Feature you named does only work with direct dependencies I guess. I added a zip to demonstrate the issue. It will fail when running mvn clean test. Anyway. I was mistaken and you may close this issue. We need to find another way. Either by making sure that there are only direct inner-module-dependencies or by making sure that those libs are built independently. > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross updated MINSTALL-94: -- Attachment: MINSTALL-94.zip > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch, MINSTALL-94.zip > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318427#comment-318427 ] Henning Gross commented on SUREFIRE-952: Hi! I am sorry. I got confused while putting together the example. Of course I wanted to do that with 2.13 not 2.3. That may also be the reason why I couldnt reproduce the issue. Your information solves all my confusion: "Surefire will ignore that only if no "target/test-classes" directory was created by the build" I am not sure and will not be able to check soon but this could be the reason why sometimes it would fail and in other modules not. I am really sorry for all the confusion but I just could not get it together. I has some example project and a real-life multi-module-project and simply did not get the behaviour. I dont know if that explains everything but I would suggest we close this issue and if I really come across a bug i can reproduce I will open a new issue w/o all this confusion. Regards! > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > Attachments: surefire-952.zip > > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318426#comment-318426
]
Henning Gross edited comment on MINSTALL-94 at 1/31/13 5:24 PM:
Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run "mvn test" on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question ("what is wrong with the skip-parameter?"): Of course we
could configure the skip-parameter in every single consumer-module wrapped in a
profile but that feels like a hack to me and is a lot of overhead compared to
just one line in the parent. Dont you think so? Thank you anyway for that idea.
I will probably implement it as fast is more important than nice. But fast and
nice would be even better ;)
Can I ask you the other way around? What is wrong with making this behaviour
configurable? Other plugins also expose switches for fail-behaviour.
was (Author: gaffa):
Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run "mvn test" on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question ("what is wrong with the skip-parameter?"): as I stated
and hopefully now explained: its not about skipping anything really. Its about
being able to install stuff w/o running all phases before install (which causes
eg wars to not being build). Of course we could configure the skip-parameter in
every single consumer-module wrapped in a profile but that feels like a hack to
me. Dont you think so? Also I do not have the source available right now. Is
the skip-param evaluated before the check for the artifact is done? That would
be necessary for this approach. Can I ask you the other way around? What is
wrong with making this behaviour configurable? Other plugins also expose
switches for fail-behaviour.
> Optional: limit install to packaging x and or make install plugin not fail if
> no artifacts were created for some modules.
> -
>
> Key: MINSTALL-94
> URL: https://jira.codehaus.org/browse/MINSTALL-94
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
>Reporter: Henning Gross
> Attachments: MINSTALL-94.patch
>
>
> Background: I am working in a huge project with a lot of modules having a lot
> of javascript-optimization and stuff happening in lifecycle-steps after
> compile. This
[jira] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[
https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318426#comment-318426
]
Henning Gross commented on MINSTALL-94:
---
Hi Robert!
I think you did not get my use-case. Its in the nature of a
multi-module-project that there are dependencies between modules. For instance
lets say you have 3 or 4 libraries, a core-lib and maybe like 10 to 20
consumers. You cannot run "mvn test" on the parent as the dependencies will be
missing (or old if already deployed before). You would have to run mvn install
to make sure those artifacts are deployed. When running the install-goal there
are some other phases in the default lifecycle that are passed before. As we
have a rather large amount of war-files with overlays and a lot of javascript
and less-foo configured those phases like packaging take forever. With no
benefit at all. I think the test-install jar thing that I have in mind is a
pretty valid requirement and a lot of projects do need it. In huge projects it
is essential to save as much time as possible in the basic jenkins-Jobs to
allow feedback early.
The approach of running two jenkins-jobs (one that installs the libs and the
other one that runs the tests on the consumers) brings a lot of configuration
overhead. Modules need to be wrapped in profiles and a build-pipeline on
Jenkins is necessary to make sure you are getting exactly the jars that were
just build and not something deployed from anywhere.
To your last question ("what is wrong with the skip-parameter?"): as I stated
and hopefully now explained: its not about skipping anything really. Its about
being able to install stuff w/o running all phases before install (which causes
eg wars to not being build). Of course we could configure the skip-parameter in
every single consumer-module wrapped in a profile but that feels like a hack to
me. Dont you think so? Also I do not have the source available right now. Is
the skip-param evaluated before the check for the artifact is done? That would
be necessary for this approach. Can I ask you the other way around? What is
wrong with making this behaviour configurable? Other plugins also expose
switches for fail-behaviour.
> Optional: limit install to packaging x and or make install plugin not fail if
> no artifacts were created for some modules.
> -
>
> Key: MINSTALL-94
> URL: https://jira.codehaus.org/browse/MINSTALL-94
> Project: Maven 2.x Install Plugin
> Issue Type: Improvement
>Reporter: Henning Gross
> Attachments: MINSTALL-94.patch
>
>
> Background: I am working in a huge project with a lot of modules having a lot
> of javascript-optimization and stuff happening in lifecycle-steps after
> compile. This results in bad performance on jenkins. I would like to run
> mvn compile install:install as I only need the jars/libs to be installed and
> not the wars (and more important I do not need them to be built).
> Please introduce Parameters like
> war
> or
> false<...
--
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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318376#comment-318376 ] Henning Gross edited comment on MINSTALL-94 at 1/31/13 9:36 AM: I attached a patch. It is really drop-dead-simple, works like a charm and we would really benefit from this. Is there any hope to get it into the next release? Do you already have an idea when you will release? We already use a junit 4.12-SNAPSHOT in our build and I do not want to make that a regular habit :D was (Author: gaffa): I attached a patch. It works like a charm and we would really benefit from this. > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross updated MINSTALL-94: -- Attachment: MINSTALL-94.patch > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318376#comment-318376 ] Henning Gross edited comment on MINSTALL-94 at 1/31/13 9:24 AM: I attached a patch. It works like a charm and we would really benefit from this. was (Author: gaffa): We might submit a Patch if theres a fair chance of getting it merged in soon. > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > Attachments: MINSTALL-94.patch > > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
[ https://jira.codehaus.org/browse/MINSTALL-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318376#comment-318376 ] Henning Gross commented on MINSTALL-94: --- We might submit a Patch if theres a fair chance of getting it merged in soon. > Optional: limit install to packaging x and or make install plugin not fail if > no artifacts were created for some modules. > - > > Key: MINSTALL-94 > URL: https://jira.codehaus.org/browse/MINSTALL-94 > Project: Maven 2.x Install Plugin > Issue Type: Improvement >Reporter: Henning Gross > > Background: I am working in a huge project with a lot of modules having a lot > of javascript-optimization and stuff happening in lifecycle-steps after > compile. This results in bad performance on jenkins. I would like to run > mvn compile install:install as I only need the jars/libs to be installed and > not the wars (and more important I do not need them to be built). > Please introduce Parameters like > war > or > false<... -- 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] (MINSTALL-94) Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules.
Henning Gross created MINSTALL-94: - Summary: Optional: limit install to packaging x and or make install plugin not fail if no artifacts were created for some modules. Key: MINSTALL-94 URL: https://jira.codehaus.org/browse/MINSTALL-94 Project: Maven 2.x Install Plugin Issue Type: Improvement Reporter: Henning Gross Background: I am working in a huge project with a lot of modules having a lot of javascript-optimization and stuff happening in lifecycle-steps after compile. This results in bad performance on jenkins. I would like to run mvn compile install:install as I only need the jars/libs to be installed and not the wars (and more important I do not need them to be built). Please introduce Parameters like war or false<... -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross updated SUREFIRE-952: --- Attachment: surefire-952.zip > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > Attachments: surefire-952.zip > > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318370#comment-318370 ] Henning Gross commented on SUREFIRE-952: First the feature. Pretty easy. You just run mvn test on the project I attached. You will see that with 4.12-SNAPSHOT (you need to provide that under our groupId/artifactId to reproduce the bug. Just install the latest SS from https://oss.sonatype.org/content/repositories/snapshots/ to your repo with foo.platform:junit:4.12_24t_1) the test is ran. Its not annotated but inherits its Category from the abstract test. That is because @Category now is @inherited. The bug(s?) is/are not easy to reproduce/nail down. I dont seem to be able to reproduce the issue we have in our productive project with modules not having a junit-dep failing to "testng or junit>4.7 is required in classpath" but maybe you will find it. The reason why I cant do that can be oberserved when you run mvn -Psf2.3 (which uses surefire 2.3 instead of 2.12.2). It results in a NPE with the following Stacktrace: at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) 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:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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.PluginExecutionException: Execution default-test of goal org.apache.maven.plugins:mav en-surefire-plugin:2.3:test failed. at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more Caused by: java.lang.NullPointerException at org.apache.maven.plugin.surefire.SurefirePlugin.constructSurefireBooter(SurefirePlugin.java:594) at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:391) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) Also I noticed that you do not use the Categories-Runner of Junit but instead copy the behaviour. If that is only because of the fact that excludecategory and includecategory did not accept more than one group before: this feature will be introduced in 4.12, too. > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- This message is automatically generated by JIRA. I
[jira] (SUREFIRE-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318366#comment-318366 ] Henning Gross edited comment on SUREFIRE-952 at 1/31/13 6:32 AM: - As I already stated this issue has the wrong title. I got the wrong idea of the cause of the problem before I found it. I will try to create and attach a sample project with profiles for the issue and also the new junit-feature as requested. was (Author: gaffa): As I already stated this issue has the wrong title. I got the wrong idea of the cause of the problem before I found it. I will attach a sample project with profiles for the issue and also the new junit-feature as requested. > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318366#comment-318366 ] Henning Gross commented on SUREFIRE-952: As I already stated this issue has the wrong title. I got the wrong idea of the cause of the problem before I found it. I will attach a sample project with profiles for the issue and also the new junit-feature as requested. > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318323#comment-318323 ] Henning Gross commented on SUREFIRE-952: 18:59:36 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.13:test (default-test) on project tds-util-lib: groups/excludedGroups require TestNG or JUnit48+ on project test classpath Happened to me in a module that does not have any tests and therefore does not include junit. The check should not be performed when there are not test classes at all, dont you think? I now need to include the dependency in every module in my multi-module-project. > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross reopened SUREFIRE-952: Does fail with snapshots. > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
[ https://jira.codehaus.org/browse/SUREFIRE-952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henning Gross closed SUREFIRE-952. -- Resolution: Not A Bug Sorry. I do not know what was wrong but it seems to work now. > Incompatibility with future release 4.12 of junit (Categories) > -- > > Key: SUREFIRE-952 > URL: https://jira.codehaus.org/browse/SUREFIRE-952 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.x support >Affects Versions: 2.12.2, 2.12.4 >Reporter: Henning Gross >Priority: Blocker > > Junit is introducing some interesting new features on Categories in 4.12. > @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will > accept a class-array instead of just a single class. As we need these > urgently we are currently testing with the current snapshot of junit > (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). > Unfortuneately the version seems to be incompatible. > All tests are executed always. Regardless of the settings in or > . Using 4.11 works fine. I do not know why this happens and > therefore cannot provide a patch but I would love to see it fixed. If someone > points me at the cause I will happily find a solution. -- 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-952) Incompatibility with future release 4.12 of junit (Categories)
Henning Gross created SUREFIRE-952: -- Summary: Incompatibility with future release 4.12 of junit (Categories) Key: SUREFIRE-952 URL: https://jira.codehaus.org/browse/SUREFIRE-952 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.12.4, 2.12.2 Reporter: Henning Gross Priority: Blocker Junit is introducing some interesting new features on Categories in 4.12. @Category will become @Inherited and @ExcludeCategory/@IncludeCategory will accept a class-array instead of just a single class. As we need these urgently we are currently testing with the current snapshot of junit (https://oss.sonatype.org/content/repositories/snapshots/junit/junit/4.12-SNAPSHOT/). Unfortuneately the version seems to be incompatible. All tests are executed always. Regardless of the settings in or . Using 4.11 works fine. I do not know why this happens and therefore cannot provide a patch but I would love to see it fixed. If someone points me at the cause I will happily find a solution. -- 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-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=293550#comment-293550 ] Henning Gross commented on SUREFIRE-811: We have decided not to write a patch for surefire as this would have meant to much effort / cost. Instead we have build a separate plugin to achieve our goals. It may be interesting for people coming here searching for a solution for a similar problem. You can find documentation, anonymous access to code and binaries/public maven repo here: https://evolvis.org/plugins/mediawiki/wiki/mvn-remote-test/index.php/Main_Page. If you want to add/change something, feel free to submit patches/join as a committer. > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- 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-811) remote-testing
[ https://jira.codehaus.org/browse/SUREFIRE-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287248#comment-287248 ] Henning Gross commented on SUREFIRE-811: Well. In our case we have an onboard-unit. The target system has a variety of diffs to the build server. Jenkins is running on a 64 bit machine, the target system is 32 bit. This can be solved via maven but then again... the binary under test is not the one which gets released. Also we would need jenkins support firing some x as we want to test out SWT - Gui. Finally we interoperate with a lot of low-level stuff as dbus which requires native/system libs. Or even GPS, Cameras, devices connected via LIN-Bus. We could mock most of it but some automated real-life-tests would be good. Also some requirements to the build server would remain and this system is building a lot of projects which are supposed to be portable as our admins do not know about the specific per-project-requirements. We tend to rather make our projects build whereever and i do not see a better fit for integration-system-tests as the one suggested. Do you? I would appreciate your ideas... > remote-testing > -- > > Key: SUREFIRE-811 > URL: https://jira.codehaus.org/browse/SUREFIRE-811 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Failsafe Plugin >Reporter: Henning Gross > > Add the possibility to copy the target folder to remote machine and run > integration-tests there. Copy back the results and handle them as if they > would have been ran locally. > I would volounteer to submit a patch for this feature if theres a chance it > would be accepted. -- 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-811) remote-testing
Henning Gross created SUREFIRE-811: -- Summary: remote-testing Key: SUREFIRE-811 URL: https://jira.codehaus.org/browse/SUREFIRE-811 Project: Maven Surefire Issue Type: New Feature Components: Maven Failsafe Plugin Reporter: Henning Gross Add the possibility to copy the target folder to remote machine and run integration-tests there. Copy back the results and handle them as if they would have been ran locally. I would volounteer to submit a patch for this feature if theres a chance it would be accepted. -- 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
