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.pa
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
ena
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
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 wrote:
>
> > All,
> >
> > I noticed that the next set of unresolv
Do we not just rename the version number?
On 22 July 2015 at 15:55, Paul Benedict 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
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 havin
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-ar
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
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 th
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/
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
mng
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)
```
-Ste
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
13 matches
Mail list logo
