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
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
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
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
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:
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
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
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
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
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)
```
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
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
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
13 matches
Mail list logo
