[jira] (MDEPLOY-157) Add deployAtEnd option for multimodule projects
Robert Scholte created MDEPLOY-157: -- Summary: Add deployAtEnd option for multimodule projects Key: MDEPLOY-157 URL: https://jira.codehaus.org/browse/MDEPLOY-157 Project: Maven 2.x and 3.x Deploy Plugin Issue Type: New Feature Components: deploy:deploy Affects Versions: 2.7 Reporter: Robert Scholte With this option it will be possible to only deploy artifacts if all have been succesfully installed. See MRELEASE-664 for further details. -- 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-157) Add deployAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MDEPLOY-157: -- Assignee: Robert Scholte > Add deployAtEnd option for multimodule projects > --- > > Key: MDEPLOY-157 > URL: https://jira.codehaus.org/browse/MDEPLOY-157 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.7 >Reporter: Robert Scholte >Assignee: Robert Scholte > > With this option it will be possible to only deploy artifacts if all have > been succesfully installed. > See MRELEASE-664 for further details. -- 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-157) Add deployAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MDEPLOY-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MDEPLOY-157. -- Resolution: Fixed Fix Version/s: 2.8 Fixed in [r1422245|http://svn.apache.org/viewvc?rev=1422245&view=rev] > Add deployAtEnd option for multimodule projects > --- > > Key: MDEPLOY-157 > URL: https://jira.codehaus.org/browse/MDEPLOY-157 > Project: Maven 2.x and 3.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy >Affects Versions: 2.7 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 2.8 > > > With this option it will be possible to only deploy artifacts if all have > been succesfully installed. > See MRELEASE-664 for further details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-664) [maven release plugin] release:perform wait until build completes before uploading artifacts
[ https://jira.codehaus.org/browse/MRELEASE-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MRELEASE-664. --- Resolution: Won't Fix Assignee: Robert Scholte Solution has been added to the maven-deploy-plugin with MDEPLOY-157 > [maven release plugin] release:perform wait until build completes before > uploading artifacts > > > Key: MRELEASE-664 > URL: https://jira.codehaus.org/browse/MRELEASE-664 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: perform >Reporter: Josh >Assignee: Robert Scholte > > Release plugin checks out from the tag, then performs a clean deploy to > verify that the code in the tag is builds successfully and uploads each > artifact individually. However, there may be errors. At which point a > rollback needs to occur. It's very painful especially for large projects if a > rollback has to occur. Also, from a strict point of view it doesn't make > sense to upload any artifact until the entire build completes successfully. > Additionally, trying to resume can be difficult, especially let's say for a > large project there is a timeout uploading the artifact (for whatever reason) > the build fails, all the artifacts should be deleted from the artifact > repository. > Please allow a feature to upload all artifacts AFTER the build successfully > completes. -- 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] (MCHANGES-46) There is no link to the RSS feed of changes in the changes report
[ https://jira.codehaus.org/browse/MCHANGES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315761#comment-315761 ] Melloware commented on MCHANGES-46: --- It has been years for this and it used to be in the old Maven 1 reports and it was useful. Someone please implement this patch! > There is no link to the RSS feed of changes in the changes report > - > > Key: MCHANGES-46 > URL: https://jira.codehaus.org/browse/MCHANGES-46 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: changes.xml >Reporter: Dennis Lundberg > Attachments: MCHANGES-46-maven-changes-plugin.patch, MCHANGES-46.patch > > -- 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-93) Add installAtEnd option for multimodule projects
Robert Scholte created MINSTALL-93: -- Summary: Add installAtEnd option for multimodule projects Key: MINSTALL-93 URL: https://jira.codehaus.org/browse/MINSTALL-93 Project: Maven 2.x Install Plugin Issue Type: Bug Components: install:install Affects Versions: 2.4 Reporter: Robert Scholte With this option it will be possible to only install artifacts if all have been succesfully verified. -- 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-93) Add installAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MINSTALL-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte reassigned MINSTALL-93: -- Assignee: Robert Scholte > Add installAtEnd option for multimodule projects > > > Key: MINSTALL-93 > URL: https://jira.codehaus.org/browse/MINSTALL-93 > Project: Maven 2.x Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.4 >Reporter: Robert Scholte >Assignee: Robert Scholte > > With this option it will be possible to only install artifacts if all have > been succesfully verified. -- 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-93) Add installAtEnd option for multimodule projects
[ https://jira.codehaus.org/browse/MINSTALL-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MINSTALL-93. -- Resolution: Fixed Fix Version/s: 2.5 Fixed in [r1422291|http://svn.apache.org/viewvc?rev=1422291&view=rev] > Add installAtEnd option for multimodule projects > > > Key: MINSTALL-93 > URL: https://jira.codehaus.org/browse/MINSTALL-93 > Project: Maven 2.x Install Plugin > Issue Type: Bug > Components: install:install >Affects Versions: 2.4 >Reporter: Robert Scholte >Assignee: Robert Scholte > Fix For: 2.5 > > > With this option it will be possible to only install artifacts if all have > been succesfully verified. -- 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-933) forkMode onceperthread broken after fix for JUnit category filter with empty result
[
https://jira.codehaus.org/browse/SUREFIRE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315767#comment-315767
]
Andreas Gudian commented on SUREFIRE-933:
-
Totally. Please try https://github.com/apache/maven-surefire/pull/15
> forkMode onceperthread broken after fix for JUnit category filter with empty
> result
> ---
>
> Key: SUREFIRE-933
> URL: https://jira.codehaus.org/browse/SUREFIRE-933
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
>
> In forkMode {{onceperthread}} (reusable fork), the {{TestsToRun}} object will
> always be a {{LazyTestsToRun}} instance, which throws an excetpion if
> {{getLocatedClasses()}} is called. The fix for SUREFIRE-839 changed
> {{JUnitCoreWrapper}} and {{JUnitCoreProvider}} to call exactly that method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2802) Concurrent-safe access to local Maven repository
[ https://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315768#comment-315768 ] luke call commented on MNG-2802: Thanks Jason!! > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: https://jira.codehaus.org/browse/MNG-2802 > Project: Maven 2 & 3 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: Issues to be reviewed for 3.x > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- 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
[
https://jira.codehaus.org/browse/MDEPLOY-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MDEPLOY-143:
---
Description:
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?
{code:xml}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/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
install-javadocs-debug
install
install-file
[jira] (MSHARED-267) Change visibilioty of methods to restore compatibility
[ https://jira.codehaus.org/browse/MSHARED-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold closed MSHARED-267. -- Resolution: Fixed Fix Version/s: maven-shared-utils-0.2 Assignee: Kristian Rosenvold > Change visibilioty of methods to restore compatibility > -- > > Key: MSHARED-267 > URL: https://jira.codehaus.org/browse/MSHARED-267 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.1 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: maven-shared-utils-0.2 > > > Some methods were made private for 0.1 that need to have higher visibility, > these are: > AbstractStremHandler#setDone needs to be protected > CommandLineUtils#executeCommandLine overload with 4 params > StreamPumper class must be public -- 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] (MSHARED-267) Change visibilioty of methods to restore compatibility
Kristian Rosenvold created MSHARED-267: -- Summary: Change visibilioty of methods to restore compatibility Key: MSHARED-267 URL: https://jira.codehaus.org/browse/MSHARED-267 Project: Maven Shared Components Issue Type: Bug Components: maven-shared-utils Affects Versions: maven-shared-utils-0.1 Reporter: Kristian Rosenvold Some methods were made private for 0.1 that need to have higher visibility, these are: AbstractStremHandler#setDone needs to be protected CommandLineUtils#executeCommandLine overload with 4 params StreamPumper class must be public -- 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] (MSHARED-267) Change visibility of methods to restore compatibility
[ https://jira.codehaus.org/browse/MSHARED-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Rosenvold updated MSHARED-267: --- Summary: Change visibility of methods to restore compatibility (was: Change visibilioty of methods to restore compatibility) > Change visibility of methods to restore compatibility > - > > Key: MSHARED-267 > URL: https://jira.codehaus.org/browse/MSHARED-267 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-shared-utils >Affects Versions: maven-shared-utils-0.1 >Reporter: Kristian Rosenvold >Assignee: Kristian Rosenvold > Fix For: maven-shared-utils-0.2 > > > Some methods were made private for 0.1 that need to have higher visibility, > these are: > AbstractStremHandler#setDone needs to be protected > CommandLineUtils#executeCommandLine overload with 4 params > StreamPumper class must be public -- 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-933) forkMode onceperthread broken after fix for JUnit category filter with empty result
[
https://jira.codehaus.org/browse/SUREFIRE-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315769#comment-315769
]
Kristian Rosenvold commented on SUREFIRE-933:
-
Nice, patch! Far better than the one I cooked up while on the plane. Are
planning to take my job ? :) Release train has started with maven-shared-utils
> forkMode onceperthread broken after fix for JUnit category filter with empty
> result
> ---
>
> Key: SUREFIRE-933
> URL: https://jira.codehaus.org/browse/SUREFIRE-933
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.13
>Reporter: Andreas Gudian
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
>
> In forkMode {{onceperthread}} (reusable fork), the {{TestsToRun}} object will
> always be a {{LazyTestsToRun}} instance, which throws an excetpion if
> {{getLocatedClasses()}} is called. The fix for SUREFIRE-839 changed
> {{JUnitCoreWrapper}} and {{JUnitCoreProvider}} to call exactly that method.
--
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-800) redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider
[
https://jira.codehaus.org/browse/SUREFIRE-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold reopened SUREFIRE-800:
-
This is currently breaking ITs on CI and is blocking release. This is due to
different run-order of tests on jdk5, and the problem is 'real'
> redirectTestOutputToFile is not taken into account in all cases with JUnit47
> provider
> -
>
> Key: SUREFIRE-800
> URL: https://jira.codehaus.org/browse/SUREFIRE-800
> Project: Maven Surefire
> Issue Type: Bug
> Components: Junit 4.7+ (parallel) support
>Affects Versions: 2.10
> Environment: all
>Reporter: nkeywal
>Assignee: Kristian Rosenvold
> Fix For: 2.13
>
> Attachments: 800.v1.patch
>
>
> With the following class:
> {noformat}
> public class Test0 {
> public Test0(){
> System.out.println("Constructor");
> }
> @Test
> public void testT0() throws Exception {
> System.out.println("testT0");
> }
> @Test
> public void testT1() throws Exception {
> System.out.println("testT1");
> }
> @BeforeClass
> public static void setUpBeforeClass() throws Exception {
> System.out.println("setUpBeforeClass");
> }
> @AfterClass
> public static void tearDownAfterClass() throws Exception {
> System.out.println("tearDownAfterClass");
> }
> @Before
> public void setUp() throws Exception {
> System.out.println("setUp");
> }
> @After
> public void tearDown() throws Exception {
> System.out.println("tearDown");
> }
> }
> {noformat}
> Some elements of the output are not redirected with JUNit47.
> {noformat}
> Concurrency config is parallel='none', perCoreThreadCount=true,
> threadCount=2, useUnlimitedThreads=false
> setUpBeforeClass
> Constructor
> Constructor
> tearDownAfterClass
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec
> {noformat}
> While it's ok with with JUNit4:
> {noformat}
> ---
> T E S T S
> ---
> Running Test0
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.09 sec
> {noformat}
--
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
