[jira] (SUREFIRE-813) Randomly wrong tests count and empty summary files with JUnitProvider47 when forking the tests.
[
https://jira.codehaus.org/browse/SUREFIRE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-813.
---
Resolution: Fixed
Fixed with unit test in r1225784, thanks for the test class !
> Randomly wrong tests count and empty summary files with JUnitProvider47 when
> forking the tests.
> ---
>
> Key: SUREFIRE-813
> URL: https://jira.codehaus.org/browse/SUREFIRE-813
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10, 2.11
> Environment: test case checked on windows 7 64 bits; issues on Linux.
> jdk1.6.0_24
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Attachments: pom.xml, Test6.java
>
>
> When running the test suite, with forkMode set and junit provider 47, we can
> have some test results missing. The test class is executed, but:
> - the summary file is empty (exists, but as a zero length file)
> - the global test count is not increased.
> It's random, and does not occurs all the time. The occurrence seems increased
> when the machine is loaded, but it's more an impression. In our case, with
> ~250 test classes, it occurs on average once per run (so it's a real
> problem). It seems to occur more if we activate 'perthread' parallelization.
>
> I added some log lines, and it seems that ForkClient does not receive all the
> test events when the problem occurs. It receives:
> - ForkingRunListener.BOOTERCODE_TESTSET_STARTING
> - ForkingRunListener.BOOTERCODE_TEST_STARTING
>
> But not the final:
> - ForkingRunListener.BOOTERCODE_TEST_SUCCEEDED
> - ForkingRunListener.BOOTERCODE_TESTSET_COMPLETED
>
> The original issue is on Linux, java 1.6, with a lot of tests running. I
> wrote a test case, hopefully reproducing the real issue with surefire 2.10
> and 2.11. It's still random, but fails 50% of the time on my machine (laptop
> 2 cores, Windows 7, 64 bits, jdk1.6.0_24).
> In this example, we create a thread writing 1000 lines of
> 'AA" in stdout in the tear down method.
> That's an example of success with surefire 2.11. You see that exactly two
> lines of 'AA' has been written to the console. On
> some other successes it can be zero lines or more.
> {noformat}
> ---
> T E S T S
> ---
> Concurrency config is parallel='classes', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> Running Test6
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> 658:AA
> 659:AA
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 2.724s
> [INFO] Finished at: Tue Dec 27 11:46:03 CET 2011
> [INFO] Final Memory: 10M/109M
> [INFO]
>
> {noformat}
> Error case, with surefire 2.11. In this one there is no
> 'AA' in the output, but you can have errors with
> multiple such lines.
> You see that the number of tests run is zero.
> {noformat}
> ---
> T E S T S
> ---
> Concurrency config is parallel='classes', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> Running Test6
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.820s
> [INFO] Finished at: Tue Dec 27 11:48:02 CET 2011
> [INFO] Final Memory: 10M/109M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.11:test (default-test) on
> project surefireparametizedbug: No tests were executed! (Set
> -DfailIfNoTests=false to ignore this error.) -> [Help 1]
> [ERROR]
> {noformat}
> With junit4 instead of junit47 it seems it never fails, but you can still
> have some AAA lines in the final output:
> {noformat}
> ---
> T E S T S
> ---
> Running Test6
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec
> 18:
[jira] (SUREFIRE-813) Randomly wrong tests count and empty summary files with JUnitProvider47 when forking the tests.
[
https://jira.codehaus.org/browse/SUREFIRE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold updated SUREFIRE-813:
Affects Version/s: (was: 2.12)
Fix Version/s: 2.12
> Randomly wrong tests count and empty summary files with JUnitProvider47 when
> forking the tests.
> ---
>
> Key: SUREFIRE-813
> URL: https://jira.codehaus.org/browse/SUREFIRE-813
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10, 2.11
> Environment: test case checked on windows 7 64 bits; issues on Linux.
> jdk1.6.0_24
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.12
>
> Attachments: pom.xml, Test6.java
>
>
> When running the test suite, with forkMode set and junit provider 47, we can
> have some test results missing. The test class is executed, but:
> - the summary file is empty (exists, but as a zero length file)
> - the global test count is not increased.
> It's random, and does not occurs all the time. The occurrence seems increased
> when the machine is loaded, but it's more an impression. In our case, with
> ~250 test classes, it occurs on average once per run (so it's a real
> problem). It seems to occur more if we activate 'perthread' parallelization.
>
> I added some log lines, and it seems that ForkClient does not receive all the
> test events when the problem occurs. It receives:
> - ForkingRunListener.BOOTERCODE_TESTSET_STARTING
> - ForkingRunListener.BOOTERCODE_TEST_STARTING
>
> But not the final:
> - ForkingRunListener.BOOTERCODE_TEST_SUCCEEDED
> - ForkingRunListener.BOOTERCODE_TESTSET_COMPLETED
>
> The original issue is on Linux, java 1.6, with a lot of tests running. I
> wrote a test case, hopefully reproducing the real issue with surefire 2.10
> and 2.11. It's still random, but fails 50% of the time on my machine (laptop
> 2 cores, Windows 7, 64 bits, jdk1.6.0_24).
> In this example, we create a thread writing 1000 lines of
> 'AA" in stdout in the tear down method.
> That's an example of success with surefire 2.11. You see that exactly two
> lines of 'AA' has been written to the console. On
> some other successes it can be zero lines or more.
> {noformat}
> ---
> T E S T S
> ---
> Concurrency config is parallel='classes', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> Running Test6
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
> 658:AA
> 659:AA
> Results :
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 2.724s
> [INFO] Finished at: Tue Dec 27 11:46:03 CET 2011
> [INFO] Final Memory: 10M/109M
> [INFO]
>
> {noformat}
> Error case, with surefire 2.11. In this one there is no
> 'AA' in the output, but you can have errors with
> multiple such lines.
> You see that the number of tests run is zero.
> {noformat}
> ---
> T E S T S
> ---
> Concurrency config is parallel='classes', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> Running Test6
> Results :
> Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 2.820s
> [INFO] Finished at: Tue Dec 27 11:48:02 CET 2011
> [INFO] Final Memory: 10M/109M
> [INFO]
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.11:test (default-test) on
> project surefireparametizedbug: No tests were executed! (Set
> -DfailIfNoTests=false to ignore this error.) -> [Help 1]
> [ERROR]
> {noformat}
> With junit4 instead of junit47 it seems it never fails, but you can still
> have some AAA lines in the final output:
> {noformat}
> ---
> T E S T S
> ---
> Running Test6
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.07 sec
> 18:AA
[jira] (SUREFIRE-814) Parallel "both" setting does not execute classes in parallel
[ https://jira.codehaus.org/browse/SUREFIRE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287124#comment-287124 ] Kristian Rosenvold commented on SUREFIRE-814: - Due to the difficulties involved in handling console output for "both", we may consider deprecating "both" support entirely. > Parallel "both" setting does not execute classes in parallel > > > Key: SUREFIRE-814 > URL: https://jira.codehaus.org/browse/SUREFIRE-814 > Project: Maven Surefire > Issue Type: Bug > Components: Junit 4.7+ (parallel) support >Affects Versions: 2.11 >Reporter: Quantum Mechanics > > jdk 1.6.0_22, windows XP -- 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-812) log4j classloader problem in 2.11 that is not there in 2.10
[ https://jira.codehaus.org/browse/SUREFIRE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-812: Comment: was deleted (was: Can you also check if there's a stack trace of any value if you run with mvn -e. Additionally, I assume this "works" if you run forkMode=once ?) > log4j classloader problem in 2.11 that is not there in 2.10 > --- > > Key: SUREFIRE-812 > URL: https://jira.codehaus.org/browse/SUREFIRE-812 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.11 >Reporter: Gregor N. Purdy, Sr. > > Unit test does not fail with 2.10 but does fail with 2.11 > Output from failing unit test > log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable > to a "org.apache.log4j.spi.Configurator" variable. > log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by > log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of > type > log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by > [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. > log4j:ERROR Could not instantiate configurator > [org.apache.log4j.xml.DOMConfigurator]. > $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Plugin config > > maven-surefire-plugin > 2.11 > > > default-test > test > > test > > > -Xmx2048m -Xms1024m > true > false > always > > 600 > true > > true > > > > > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > > reporting plugin configuration > > maven-surefire-report-plugin > 2.11 > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > 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] (SUREFIRE-812) log4j classloader problem in 2.11 that is not there in 2.10
[ https://jira.codehaus.org/browse/SUREFIRE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated SUREFIRE-812: Comment: was deleted (was: Is there any chance you could produce a small test project that reproduces this issue ?) > log4j classloader problem in 2.11 that is not there in 2.10 > --- > > Key: SUREFIRE-812 > URL: https://jira.codehaus.org/browse/SUREFIRE-812 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.11 >Reporter: Gregor N. Purdy, Sr. > > Unit test does not fail with 2.10 but does fail with 2.11 > Output from failing unit test > log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable > to a "org.apache.log4j.spi.Configurator" variable. > log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by > log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of > type > log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by > [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. > log4j:ERROR Could not instantiate configurator > [org.apache.log4j.xml.DOMConfigurator]. > $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Plugin config > > maven-surefire-plugin > 2.11 > > > default-test > test > > test > > > -Xmx2048m -Xms1024m > true > false > always > > 600 > true > > true > > > > > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > > reporting plugin configuration > > maven-surefire-report-plugin > 2.11 > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > 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] (SUREFIRE-812) log4j classloader problem in 2.11 that is not there in 2.10
[ https://jira.codehaus.org/browse/SUREFIRE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=286694#comment-286694 ] Kristian Rosenvold edited comment on SUREFIRE-812 at 12/30/11 4:29 AM: --- Could you verify that the problem is still present on 2.12-SNAPSHOT, we have fixed another issue with similar symptoms for 2.12. If not, is there any chance you could produce a small test project that reproduces this issue ? Can you also check if there's a stack trace of any value if you run with mvn -e. Additionally, I assume this "works" if you run forkMode=once ? was (Author: krosenvold): Could you also verify that the problem is still present on 2.12-SNAPSHOT? > log4j classloader problem in 2.11 that is not there in 2.10 > --- > > Key: SUREFIRE-812 > URL: https://jira.codehaus.org/browse/SUREFIRE-812 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.11 >Reporter: Gregor N. Purdy, Sr. > > Unit test does not fail with 2.10 but does fail with 2.11 > Output from failing unit test > log4j:ERROR A "org.apache.log4j.xml.DOMConfigurator" object is not assignable > to a "org.apache.log4j.spi.Configurator" variable. > log4j:ERROR The class "org.apache.log4j.spi.Configurator" was loaded by > log4j:ERROR [sun.misc.Launcher$AppClassLoader@37b90b39] whereas object of > type > log4j:ERROR "org.apache.log4j.xml.DOMConfigurator" was loaded by > [org.apache.maven.surefire.booter.IsolatedClassLoader@7bd63e39]. > log4j:ERROR Could not instantiate configurator > [org.apache.log4j.xml.DOMConfigurator]. > $ mvn -version > Apache Maven 3.0.3 (r1075438; 2011-02-28 09:31:09-0800) > Plugin config > > maven-surefire-plugin > 2.11 > > > default-test > test > > test > > > -Xmx2048m -Xms1024m > true > false > always > > 600 > true > > true > > > > > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > true > > > > reporting plugin configuration > > maven-surefire-report-plugin > 2.11 > > -Xmx2048m -Xms1024m > true > false > always > 600 > true > > 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] (MDEP-128) Support ability to specify multiple "includeScope" parameters
[ https://jira.codehaus.org/browse/MDEP-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287130#comment-287130 ] Rafal Figas commented on MDEP-128: -- Wooow, this is REALLY counterintuitive. I found this, while I was trying to exclude test dependencies, exactly the same way as Bryan Stopp did. I think it would be VERY helpful if written at goal documentation in here: http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html > Support ability to specify multiple "includeScope" parameters > - > > Key: MDEP-128 > URL: https://jira.codehaus.org/browse/MDEP-128 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement >Affects Versions: 2.0-alpha-4 >Reporter: Bryan Stopp >Assignee: Brian Fox > > You can only configure the plugin with either one includeScope or one > excludeScope. When executing the plugin to copy dependencies with the > following configuration: > >org.apache.maven.plugins >maven-dependency-plugin > > > copy-dependencies > validate > > copy-dependencies > > > > > /src/main/webapp/WEB-INF/lib > false > true > true > provided > > > It does exclude the provided scope, but it includes the test scope [easymock, > dbunit, and junit appear in the output directory]. I tried to correct this > problem by replacing the excludeScope parameter with two includeScope > parameters, one for compile one for runtime, but only the first parameter was > actually used. > I also tried to exclude test but got an error, something like, "Can't exclude > tests as that would exclude everything!". > The goal is to be able to recreate the default copy functionality that is > accomplished when executing a "mvn package" command, but be able to specify a > maven-dependency-plugin configuration. When specifying this configuration, it > overrides the default settings throughout the entire build life-cycle (as it > should). But it is impossible to configure the plugin in the exact same was > as the default settings. > This is needed to support copying dependencies into the WEB-INF/lib folder > within Eclipse workspaces, to support embedded application-server deployment. -- 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] (MANTRUN-161) antrun does not resolve build.xml from classpath
[
https://jira.codehaus.org/browse/MANTRUN-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287136#comment-287136
]
Jordi Gerona commented on MANTRUN-161:
--
This is happening to me too with maven 3.0.3 and antrun 1.7
I'm trying to achieve the same behavior as [Checkstyle plugin multimodule
configuration|http://goo.gl/jmykx].
As a workaround, you can use {{dependency:unpack}} plugin to unpack the project
resources and then use
{{$\{project.build.directory\}/dependencies/subscripts/build.xml}} in your ant
definition. Example [here|http://goo.gl/xfzzx]. It's kinda annoying 'cos your
pom will grow much bigger but it works.
hth,
jordi
> antrun does not resolve build.xml from classpath
>
>
> Key: MANTRUN-161
> URL: https://jira.codehaus.org/browse/MANTRUN-161
> Project: Maven 2.x Antrun Plugin
> Issue Type: Bug
>Affects Versions: 1.6
> Environment: maven-3.0.3
>Reporter: Frank Jakop
>
> I am referencing an ant-file in the configuration of antrun-plugin.
> {noformat}
>
>
>
>
>
>
>
> {noformat}
> The file "subscripts/build.xml" is included in the "src/main/resources"
> folder of a dependency of the antrun-plugin.
> {noformat}
>
> my.ant
> subscripts
> 0.0.1-SNAPSHOT
>
> {noformat}
> Layout of "my.ant.subscripts" is
> {noformat}
> src
> \main
>\resources
> \subscripts
>\build.xml
> {noformat}
> which is correctly packaged.
> Given the basedir name "basedir", the antrun tells me on execution that the
> file "basedir/subscripts/build.xml" is not found.
> My use-case includes about 30 projects, which execute the same ant target in
> their build lifecycle. I could solve the problem by putting a copy of
> "subscripts/build.xml" in every project's directory, but that is a very bad
> way.
--
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] (MSKINS-23) Provide backgrounds for MOJOs status
Simone Tripodi created MSKINS-23: Summary: Provide backgrounds for MOJOs status Key: MSKINS-23 URL: https://jira.codehaus.org/browse/MSKINS-23 Project: Maven Skins Issue Type: New Feature Components: Fluido Skin Affects Versions: fluido-1.1 Reporter: Simone Tripodi As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins lifecycle is characterized by different status/stages: * Production * Pre-release * Sandbox * Graveyard We would like to add different backgrounds depending on the plugin status (except the production) to warrant users they are not using a production ready plugin. We thought taking inspiration from the [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] sprite to repeat as background, maybe with different colors (yellow for Pre-release, red for Sandbox and grey for Graveyard). Any contribution is very well appreciated! -- 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] (MSKINS-23) Provide backgrounds for MOJOs status
[ https://jira.codehaus.org/browse/MSKINS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MSKINS-23: - Priority: Minor (was: Major) Changing it to minor, it's a nice to have. > Provide backgrounds for MOJOs status > > > Key: MSKINS-23 > URL: https://jira.codehaus.org/browse/MSKINS-23 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.1 >Reporter: Simone Tripodi >Priority: Minor > > As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins > lifecycle is characterized by different status/stages: > * Production > * Pre-release > * Sandbox > * Graveyard > We would like to add different backgrounds depending on the plugin status > (except the production) to warrant users they are not using a production > ready plugin. > We thought taking inspiration from the > [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] > sprite to repeat as background, maybe with different colors (yellow for > Pre-release, red for Sandbox and grey for Graveyard). > Any contribution is very well appreciated! -- 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] (MSKINS-23) Provide backgrounds for MOJOs status
[ https://jira.codehaus.org/browse/MSKINS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287148#comment-287148 ] Carlos Villaronga commented on MSKINS-23: - I'm not sure if these files are useful: http://www.image-share.com/ipng-1172-283.html http://www.image-share.com/ipng-1172-284.html http://www.image-share.com/ipng-1172-285.html http://www.image-share.com/ipng-1172-286.html > Provide backgrounds for MOJOs status > > > Key: MSKINS-23 > URL: https://jira.codehaus.org/browse/MSKINS-23 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.1 >Reporter: Simone Tripodi >Priority: Minor > > As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins > lifecycle is characterized by different status/stages: > * Production > * Pre-release > * Sandbox > * Graveyard > We would like to add different backgrounds depending on the plugin status > (except the production) to warrant users they are not using a production > ready plugin. > We thought taking inspiration from the > [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] > sprite to repeat as background, maybe with different colors (yellow for > Pre-release, red for Sandbox and grey for Graveyard). > Any contribution is very well appreciated! -- 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] (MSKINS-23) Provide backgrounds for MOJOs status
[ https://jira.codehaus.org/browse/MSKINS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287149#comment-287149 ] Simone Tripodi commented on MSKINS-23: -- this is priceless Carlos, thanks a lot!!! maybe it is needed just a lower alpha level, to put them in the background. can you attach please the sources? many thanks in advance for the prompt help, I don't have the words to say thank you! > Provide backgrounds for MOJOs status > > > Key: MSKINS-23 > URL: https://jira.codehaus.org/browse/MSKINS-23 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.1 >Reporter: Simone Tripodi >Priority: Minor > > As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins > lifecycle is characterized by different status/stages: > * Production > * Pre-release > * Sandbox > * Graveyard > We would like to add different backgrounds depending on the plugin status > (except the production) to warrant users they are not using a production > ready plugin. > We thought taking inspiration from the > [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] > sprite to repeat as background, maybe with different colors (yellow for > Pre-release, red for Sandbox and grey for Graveyard). > Any contribution is very well appreciated! -- 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] (MSKINS-23) Provide backgrounds for MOJOs status
[ https://jira.codehaus.org/browse/MSKINS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287151#comment-287151 ] Carlos Villaronga commented on MSKINS-23: - it's only a small contribution... > Provide backgrounds for MOJOs status > > > Key: MSKINS-23 > URL: https://jira.codehaus.org/browse/MSKINS-23 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.1 >Reporter: Simone Tripodi >Priority: Minor > > As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins > lifecycle is characterized by different status/stages: > * Production > * Pre-release > * Sandbox > * Graveyard > We would like to add different backgrounds depending on the plugin status > (except the production) to warrant users they are not using a production > ready plugin. > We thought taking inspiration from the > [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] > sprite to repeat as background, maybe with different colors (yellow for > Pre-release, red for Sandbox and grey for Graveyard). > Any contribution is very well appreciated! -- 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] (MSKINS-23) Provide backgrounds for MOJOs status
[ https://jira.codehaus.org/browse/MSKINS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Villaronga updated MSKINS-23: Attachment: src-svg-alpha70.zip There're 4 files in the. Zip is a pleasure to contribute. > Provide backgrounds for MOJOs status > > > Key: MSKINS-23 > URL: https://jira.codehaus.org/browse/MSKINS-23 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.1 >Reporter: Simone Tripodi >Priority: Minor > Attachments: src-svg-alpha70.zip > > > As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins > lifecycle is characterized by different status/stages: > * Production > * Pre-release > * Sandbox > * Graveyard > We would like to add different backgrounds depending on the plugin status > (except the production) to warrant users they are not using a production > ready plugin. > We thought taking inspiration from the > [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] > sprite to repeat as background, maybe with different colors (yellow for > Pre-release, red for Sandbox and grey for Graveyard). > Any contribution is very well appreciated! -- 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] (MSKINS-23) Provide backgrounds for MOJOs status
[ https://jira.codehaus.org/browse/MSKINS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287153#comment-287153 ] Simone Tripodi commented on MSKINS-23: -- I've not been able to do them myself, so what for you is 'just' a contribution, for me is a nice contribution!!! Thanks a lot for the help once again! > Provide backgrounds for MOJOs status > > > Key: MSKINS-23 > URL: https://jira.codehaus.org/browse/MSKINS-23 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.1 >Reporter: Simone Tripodi >Priority: Minor > Attachments: src-svg-alpha70.zip > > > As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins > lifecycle is characterized by different status/stages: > * Production > * Pre-release > * Sandbox > * Graveyard > We would like to add different backgrounds depending on the plugin status > (except the production) to warrant users they are not using a production > ready plugin. > We thought taking inspiration from the > [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] > sprite to repeat as background, maybe with different colors (yellow for > Pre-release, red for Sandbox and grey for Graveyard). > Any contribution is very well appreciated! -- 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] (MSITE-626) Iternazionalization element just uses the language part of specified locales
Simone Tripodi created MSITE-626:
Summary: Iternazionalization element just uses the language part
of specified locales
Key: MSITE-626
URL: https://jira.codehaus.org/browse/MSITE-626
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: internationalization
Reporter: Simone Tripodi
It seems the plugin can not handle multiple countries with the same language,
i.e. given the setting
{code}
zh_CN,zh_TW.
{code}
When the site is built, both zh_CN and zh_TW content goes into the zh directory.
--
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] [Created] (MPOM-35) Apache POM 10 does not allow -Darguments
Apache POM 10 does not allow -Darguments Key: MPOM-35 URL: https://issues.apache.org/jira/browse/MPOM-35 Project: Maven POMs Issue Type: Bug Components: asf Affects Versions: ASF-10 Reporter: David Blevins The usage of -Darguments as noted in the release plugin documentation doesn't work due to an issue with the apache parent pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MPOM-35) Apache POM 10 does not allow -Darguments
[ https://issues.apache.org/jira/browse/MPOM-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Blevins updated MPOM-35: -- Attachment: MPOM-35.diff > Apache POM 10 does not allow -Darguments > > > Key: MPOM-35 > URL: https://issues.apache.org/jira/browse/MPOM-35 > Project: Maven POMs > Issue Type: Bug > Components: asf >Affects Versions: ASF-10 >Reporter: David Blevins > Attachments: MPOM-35.diff > > > The usage of -Darguments as noted in the release plugin documentation doesn't > work due to an issue with the apache parent pom. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSKINS-23) Provide backgrounds for MOJOs status
[ https://jira.codehaus.org/browse/MSKINS-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi closed MSKINS-23. Resolution: Fixed Assignee: Simone Tripodi fixed on [r1225958|https://svn.apache.org/viewvc?view=revision&revision=1225958] > Provide backgrounds for MOJOs status > > > Key: MSKINS-23 > URL: https://jira.codehaus.org/browse/MSKINS-23 > Project: Maven Skins > Issue Type: New Feature > Components: Fluido Skin >Affects Versions: fluido-1.1 >Reporter: Simone Tripodi >Assignee: Simone Tripodi >Priority: Minor > Attachments: src-svg-alpha70.zip > > > As shown in the MOJOs [list|http://mojo.codehaus.org/plugins.html], plugins > lifecycle is characterized by different status/stages: > * Production > * Pre-release > * Sandbox > * Graveyard > We would like to add different backgrounds depending on the plugin status > (except the production) to warrant users they are not using a production > ready plugin. > We thought taking inspiration from the > [confidential|http://imageshack.us/photo/my-images/209/confidential.png/] > sprite to repeat as background, maybe with different colors (yellow for > Pre-release, red for Sandbox and grey for Graveyard). > Any contribution is very well appreciated! -- 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
