Re: Preventing unnecessary JIRA version managing
No, but that would be even easier. Cheers, Paul On Wed, Jul 22, 2015 at 10:55 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Do we not just rename the version number? On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote: All, I noticed that the next set of unresolved tickets are always assigned a version number. This leads to unnecessary maintenance when we have to burn a point release (i.e., you have to re-assign them to the next release) or it's just time for a new point release. There's really no point in having unresolved issues queued up. I kind of feel bad for Jason as he has to keep pushing them forward. I think we should just put all unresolved tickets in the 3.x backlog, and, as they are resolved, assign them an official version number. WDYT? Cheers, Paul
Re: Preventing unnecessary JIRA version managing
Do we not just rename the version number? On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote: All, I noticed that the next set of unresolved tickets are always assigned a version number. This leads to unnecessary maintenance when we have to burn a point release (i.e., you have to re-assign them to the next release) or it's just time for a new point release. There's really no point in having unresolved issues queued up. I kind of feel bad for Jason as he has to keep pushing them forward. I think we should just put all unresolved tickets in the 3.x backlog, and, as they are resolved, assign them an official version number. WDYT? Cheers, Paul
[GitHub] maven pull request: [MNG-5816] Empy maven.config cause Maven to ex...
Github user tssp commented on the pull request: https://github.com/apache/maven/pull/47#issuecomment-123809124 You're welcome. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-5816] Empy maven.config cause Maven to ex...
Github user tssp closed the pull request at: https://github.com/apache/maven/pull/47 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven 3.3.5
OK so MNG-2199 introduced the regression MNG-5840 There was a claim in the introduction of MNG-2199 that there was some validation in the workspace resolver: https://github.com/apache/maven/blob/25f5143169d39075cee67d9f4d11649cce0fafa0/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L938 The tests I have added in https://github.com/apache/maven-integration-testing/commit/f2d3d7a0244a6401514662a5f2cfcca7eca706e4 show that the claim was incorrect. With my change in https://github.com/apache/maven/blob/25f5143169d39075cee67d9f4d11649cce0fafa0 we keep MNG-5840 fixed for non version range parents (which is good) but those that have a version range will fall foul to MNG-5840 (which IMHO is very very bad) Short of pulling the version range parsing code up into model builder or introducing a dependency on maven-artifact to model-builder I cannot see any simple way to fix the issue of the parent version range. If somebody wants to take a stab at figuring out the workspace resolver version, they are welcome to try. https://github.com/apache/maven/pull/60 Is one potential (ugly IMHO) fix. It might suffice for an interim release, as I view MNG-5840 as very evil and a blocker to anyone using 3.3.x, until such time as the workspace resolver actually has the validation code On 22 July 2015 at 08:49, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Igor, Seems that we are missing integration tests for that feature. I suspect that this is a regression introduced in fixing the MNG-5840 regression. I have committed a partial fix (i.e. fixes MNG-5840 for non-version ranges) and I have some integration tests for with version ranges to see if the claimed workspace validation actually takes place with a version range. On 22 July 2015 at 00:57, Igor Fedorenko i...@ifedorenko.com wrote: -1 FWIW There is a regression with parent pom version range support (see MNG-2199 [1]) when locating locally-available parent pom. I've pushed MavenITmng2199ParentVersionRangeTest#testValidLocalParentVersionRange regression test [2] to demonstrate the issue. The test works with Maven 3.3.3 but fails with current master. Staged 3.3.5 does not work for our internal build, however. [1] https://issues.apache.org/jira/browse/MNG-2199 [2] https://git1-us-west.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=b015e1cf9860fa9f3725a4393d7a0dc8a0868b2f -- Regards, Igor On Tue, Jul 21, 2015, at 01:12 PM, Tibor Digana wrote: +1 non-binding from me. Now my IDEA works fine with 3.3.5. On Tue, Jul 21, 2015 at 4:58 PM, stephenconnolly [via Maven] ml-node+s40175n5840520...@n5.nabble.com wrote: FYI Tibor, that is not a regression against 3.3.3 from my understanding On 21 July 2015 at 14:30, Tibor Digana [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=0 wrote: +0 (non-binding) The IntelliJ IDEA does not launch Maven build. It looks like the reason is that we changed file name from bin/mvn.bat to bin/mvn.cmd. Is it only me who has this problem in IDEA, can you check it out as well? On Mon, Jul 20, 2015 at 9:23 PM, Jason van Zyl [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=1 wrote: Hi, Time to release Maven 3.3.5! Here is a link to the issues resolved: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12333058 Staging repo: https://repository.apache.org/content/repositories/maven-1200/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.zip https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.tar.gz https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.zip https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.tar.gz Source release checksum(s): apache-maven-3.3.5-src.zip sha1: f2b28783fbf9a4fda47d2924a29aa99b9dc7b898 Staging site: http://people.apache.org/~jvanzyl/maven-3.3.5/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, The Maven Team - To unsubscribe, e-mail: [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=2 For
Re: [VOTE] Maven 3.3.5
Igor, Seems that we are missing integration tests for that feature. I suspect that this is a regression introduced in fixing the MNG-5840 regression. I have committed a partial fix (i.e. fixes MNG-5840 for non-version ranges) and I have some integration tests for with version ranges to see if the claimed workspace validation actually takes place with a version range. On 22 July 2015 at 00:57, Igor Fedorenko i...@ifedorenko.com wrote: -1 FWIW There is a regression with parent pom version range support (see MNG-2199 [1]) when locating locally-available parent pom. I've pushed MavenITmng2199ParentVersionRangeTest#testValidLocalParentVersionRange regression test [2] to demonstrate the issue. The test works with Maven 3.3.3 but fails with current master. Staged 3.3.5 does not work for our internal build, however. [1] https://issues.apache.org/jira/browse/MNG-2199 [2] https://git1-us-west.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=b015e1cf9860fa9f3725a4393d7a0dc8a0868b2f -- Regards, Igor On Tue, Jul 21, 2015, at 01:12 PM, Tibor Digana wrote: +1 non-binding from me. Now my IDEA works fine with 3.3.5. On Tue, Jul 21, 2015 at 4:58 PM, stephenconnolly [via Maven] ml-node+s40175n5840520...@n5.nabble.com wrote: FYI Tibor, that is not a regression against 3.3.3 from my understanding On 21 July 2015 at 14:30, Tibor Digana [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=0 wrote: +0 (non-binding) The IntelliJ IDEA does not launch Maven build. It looks like the reason is that we changed file name from bin/mvn.bat to bin/mvn.cmd. Is it only me who has this problem in IDEA, can you check it out as well? On Mon, Jul 20, 2015 at 9:23 PM, Jason van Zyl [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=1 wrote: Hi, Time to release Maven 3.3.5! Here is a link to the issues resolved: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922version=12333058 Staging repo: https://repository.apache.org/content/repositories/maven-1200/ The distributable binaries and sources for testing can be found here: https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/ Specifically the zip, tarball, and source archives can be found here: https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.zip https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-bin.tar.gz https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.zip https://repository.apache.org/content/repositories/maven-1200/org/apache/maven/apache-maven/3.3.5/apache-maven-3.3.5-src.tar.gz Source release checksum(s): apache-maven-3.3.5-src.zip sha1: f2b28783fbf9a4fda47d2924a29aa99b9dc7b898 Staging site: http://people.apache.org/~jvanzyl/maven-3.3.5/ Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, The Maven Team - To unsubscribe, e-mail: [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=2 For additional commands, e-mail: [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=3 - To unsubscribe, e-mail: [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=4 For additional commands, e-mail: [hidden email] http:///user/SendEmail.jtp?type=nodenode=5840520i=5 -- If you reply to this email, your message will be added to the discussion below: http://maven.40175.n5.nabble.com/VOTE-Maven-3-3-5-tp5840486p5840520.html To start a new topic under Maven Developers, email ml-node+s40175n142166...@n5.nabble.com To unsubscribe from Maven Developers, click here http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=142166code=dGlib3JkaWdhbmFAYXBhY2hlLm9yZ3wxNDIxNjZ8LTI4OTQ5MjEwMg== . NAML http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context:
Re: [VOTE] Maven 3.3.5
On 22 Jul 2015, at 11:57, Igor Fedorenko wrote: There is a regression with parent pom version range support (see MNG-2199 [1]) when locating locally-available parent pom. I've pushed MavenITmng2199ParentVersionRangeTest#testValidLocalParentVersionRange regression test [2] to demonstrate the issue. The test works with Maven 3.3.3 but fails with current master. Staged 3.3.5 does not work for our internal build, however. Hem - this might explain some weird issues we had reported with the tiles-maven-plugin not finding local-snapshot tiles ( tiles get injected as parents ). -- Mark Derricutt http://www.theoryinpractice.net http://www.chaliceofblood.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt signature.asc Description: OpenPGP digital signature
[GitHub] maven pull request: [MNG-5840] Parent version is a range hack
Github user stephenc commented on the pull request: https://github.com/apache/maven/pull/60#issuecomment-123696060 @ifedorenko I've simplified this per your comments... still feel that adding the dependency on maven-artifact is not the correct thing... but it is a semi-reasonable fix --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request: [MNG-5840] Parent version is a range hack
Github user ifedorenko commented on the pull request: https://github.com/apache/maven/pull/60#issuecomment-123711202 What other options do we have? I guess we can create new `maven-versioning` module, move `org.apache.maven.artifact.versioning` implementation there and change maven-artifact to delegate to the new code. This is the only clean solution I can think of, but I do not have time to do this now and not sure new module with only a handful of classes is justifiable. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-integration-testing git commit: [MNG-5840] Add tests for when the parent version is a range.
I screwed up the expected failing tests here for 3.3.0 through 3.3.3:
Maven 3.3.0 through 3.3.3 are expected to have the following tests fail:
```
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)
mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)
```
-Stephen
On 22 July 2015 at 09:26, steph...@apache.org wrote:
Repository: maven-integration-testing
Updated Branches:
refs/heads/master b015e1cf9 - f2d3d7a02
[MNG-5840] Add tests for when the parent version is a range.
Maven 3.3.0 through 3.3.3 are expected to have the following tests fail:
```
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)
mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)
```
Maven 3.3.4 through 3.3.5 are expected to have the following tests fail:
```
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)
```
As of 25f5143169d39075cee67d9f4d11649cce0fafa0 in the Maven core repo the
following
test results are expected and observed:
```
mng2199ParentVersionRange(ValidParentVersionRangeWithInclusiveUpperBound)OK
(3.3 s)
mng2199ParentVersionRange(ValidParentVersionRangeWithExclusiveUpperBound)OK
(1.7 s)
mng2199ParentVersionRange(InvalidParentVersionRange)OK (0.7 s)
mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionExpression)OK
(0.4 s)
mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionInheritance)OK
(0.5 s)
mng2199ParentVersionRange(ValidLocalParentVersionRange).OK (0.4 s)
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)FAILURE
(0.4 s)
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK
(0.4 s)
mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)OK
(0.4 s)
```
With the one failure:
mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)
expected
as the rumoured [validation in the workspace resolver](
https://github.com/apache/maven/blob/25f5143169d39075cee67d9f4d11649cce0fafa0/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilder.java#L938)
does not actually exist.
Project:
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/repo
Commit:
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/commit/f2d3d7a0
Tree:
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/tree/f2d3d7a0
Diff:
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/diff/f2d3d7a0
Branch: refs/heads/master
Commit: f2d3d7a0244a6401514662a5f2cfcca7eca706e4
Parents: b015e1c
Author: Stephen Connolly stephen.alan.conno...@gmail.com
Authored: Wed Jul 22 09:26:40 2015 +0100
Committer: Stephen Connolly stephen.alan.conno...@gmail.com
Committed: Wed Jul 22 09:26:40 2015 +0100
--
.../it/MavenITmng5840ParentVersionRanges.java | 47
...venITmng5840RelativePathReactorMatching.java | 3 +-
.../child/pom.xml | 39
.../parent-1/pom.xml| 14 ++
.../parent/pom.xml | 14 ++
.../child/pom.xml | 39
.../parent-1/pom.xml| 14 ++
.../parent/pom.xml | 14 ++
8 files changed, 182 insertions(+), 2 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/maven-integration-testing/blob/f2d3d7a0/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5840ParentVersionRanges.java
--
diff --git
a/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5840ParentVersionRanges.java
b/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5840ParentVersionRanges.java
new file mode 100644
index 000..281b71b
--- /dev/null
+++
b/core-it-suite/src/test/java/org/apache/maven/it/MavenITmng5840ParentVersionRanges.java
@@ -0,0 +1,47 @@
+package org.apache.maven.it;
+
+import org.apache.maven.it.util.ResourceExtractor;
+
+import java.io.File;
+
+public class MavenITmng5840ParentVersionRanges
+extends AbstractMavenIntegrationTestCase
+{
+public MavenITmng5840ParentVersionRanges()
+{
+super( [3.3,) );
+}
+
+public void testParentRangeRelativePathPointsToWrongVersion()
+throws Exception
+{
+File testDir = ResourceExtractor.simpleExtractResources(
getClass(), /mng-5840-relative-path-range-negative );
+
+Verifier verifier = newVerifier( new File( testDir, parent-1
).getAbsolutePath(), remote );
+verifier.executeGoal( install );
+
[GitHub] maven pull request: [MNG-5840] Parent version is a range hack
GitHub user stephenc opened a pull request: https://github.com/apache/maven/pull/60 [MNG-5840] Parent version is a range hack - I don't like this, but it does let all the integration tests pass: ``` Running org.apache.maven.it.MavenITmng2199ParentVersionRangeTest mng2199ParentVersionRange(ValidParentVersionRangeWithInclusiveUpperBound)OK (3.7 s) mng2199ParentVersionRange(ValidParentVersionRangeWithExclusiveUpperBound)OK (1.7 s) mng2199ParentVersionRange(InvalidParentVersionRange)OK (0.7 s) mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionExpression)OK (0.5 s) mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionInheritance)OK (0.4 s) mng2199ParentVersionRange(ValidLocalParentVersionRange).OK (0.4 s) Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.509 sec - in org.apache.maven.it.MavenITmng2199ParentVersionRangeTest Running org.apache.maven.it.MavenITmng5840ParentVersionRanges mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)OK (0.4 s) mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK (0.4 s) Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.784 sec - in org.apache.maven.it.MavenITmng5840ParentVersionRanges Running org.apache.maven.it.MavenITmng5840RelativePathReactorMatching mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)OK (0.4 s) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.374 sec - in org.apache.maven.it.MavenITmng5840RelativePathReactorMatching ``` I have created this as a pull request because I do not like the dependency change it requires. You can merge this pull request into a Git repository by running: $ git pull https://github.com/stephenc/maven mng-5840-version-range-hack Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/60.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #60 commit fc4e341322d708225724363c757012b405cff99e Author: Stephen Connolly stephen.alan.conno...@gmail.com Date: 2015-07-22T08:52:01Z [MNG-5840] Parent version is a range hack - I don't like this, but it does let all the integration tests pass: Running org.apache.maven.it.MavenITmng2199ParentVersionRangeTest mng2199ParentVersionRange(ValidParentVersionRangeWithInclusiveUpperBound)OK (3.7 s) mng2199ParentVersionRange(ValidParentVersionRangeWithExclusiveUpperBound)OK (1.7 s) mng2199ParentVersionRange(InvalidParentVersionRange)OK (0.7 s) mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionExpression)OK (0.5 s) mng2199ParentVersionRange(ValidParentVersionRangeInvalidVersionInheritance)OK (0.4 s) mng2199ParentVersionRange(ValidLocalParentVersionRange).OK (0.4 s) Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 7.509 sec - in org.apache.maven.it.MavenITmng2199ParentVersionRangeTest Running org.apache.maven.it.MavenITmng5840ParentVersionRanges mng5840ParentVersionRanges(ParentRangeRelativePathPointsToWrongVersion)OK (0.4 s) mng5840ParentVersionRanges(ParentRangeRelativePathPointsToCorrectVersion)OK (0.4 s) Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.784 sec - in org.apache.maven.it.MavenITmng5840ParentVersionRanges Running org.apache.maven.it.MavenITmng5840RelativePathReactorMatching mng5840RelativePathReactorMatching(RelativePathPointsToWrongVersion)OK (0.4 s) Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.374 sec - in org.apache.maven.it.MavenITmng5840RelativePathReactorMatching --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-surefire pull request: Add missing slash in closing tag of '...
GitHub user acanda opened a pull request: https://github.com/apache/maven-surefire/pull/100 Add missing slash in closing tag of 'use argLine' error message When you try to set `java.library.path` as a system property in the configuration the plugin emits the warning `java.library.path cannot be set as system property, use argLine-Djava.library.path=...argLine instead`. This change adds the missing slash in the closing tag which is `argLine` but should be `/argLine`. You can merge this pull request into a Git repository by running: $ git pull https://github.com/acanda/maven-surefire argLine Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-surefire/pull/100.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #100 commit cf64b1137ad6a941f157face8991b9e24774b716 Author: Philip Graf g...@acanda.ch Date: 2015-07-22T21:51:16Z Add missing slash in closing tag of 'use argLine' error message --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Preventing unnecessary JIRA version managing
All, I noticed that the next set of unresolved tickets are always assigned a version number. This leads to unnecessary maintenance when we have to burn a point release (i.e., you have to re-assign them to the next release) or it's just time for a new point release. There's really no point in having unresolved issues queued up. I kind of feel bad for Jason as he has to keep pushing them forward. I think we should just put all unresolved tickets in the 3.x backlog, and, as they are resolved, assign them an official version number. WDYT? Cheers, Paul
