You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Christian Schulte <cs...@schulte.it> on 2017/01/30 18:34:33 UTC
[IT] MNG-2199 for 3.5.0
Hi,
I'd like to merge the MNG-2199 branch to master for 3.5.0. I think this
should really go into 3.5.0 and not 3.5.1. Anyone second that? I tried
to explain things as much as possible in the commit messages. There also
is one IT which needs to be deprecated because it is testing an invalid
project to be supported which never should have worked. I copy the
commit messages here in case the links stop working sometime in the
future. When reviewing the deprecated IT
(testValidLocalParentVersionRange), keep in mind that this multi module
project
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=tree;f=core-it-suite/src/test/resources/mng-2199-parent-version-range/local-parent;h=54f8d7b92a1fbf1ed4837a5e79b48cf23ce2dc25;hb=HEAD>
more precisely this module/pom.xml file
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/resources/mng-2199-parent-version-range/local-parent/module/pom.xml;h=85769ce5af3a46f57ff4f15bb3faa366278d4cec;hb=HEAD>
cannot be build with any Maven version prior to 3.3.0 although the test
class declared [3.2.2,) as the range to test. You cannot build that
project using anything < 3.3.0 and it should not be possible to build
that project with anything > 3.3.9 again. So that there are only two
Maven releases out there supporting that project. That's why I think
this should be fixed in 3.5.0 (ASAP) so that the number of Maven
versions suporting that is kept as small as possible (2 - namely 3.3.0
and 3.3.9). When in doubt, just try this with various Maven versions <
3.3.0.
cd
maven-integration-testing/core-it-suite/src/test/resources/mng-2199-parent-version-range/local-parent/module
mvn verify
Maven:
------
<https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=85e96e3f386b6097750e74f3a07327ca8dbb2b9b>
[MNG-2199] Support version ranges in parent elements
o Updated to fix parent version range resolution broken since 3.2.3 and
to remove parent version range resolution logic obsolete since Maven
3.2.3 which changed the initialization of MavenProject instances.
o Updated local parent resolution to behave the same way remote parent
resolution behaves. When referencing a parent using version ranges,
inheriting the version or using version expressions should not be
supported. It has been implemented that way for remote parent resolution
as it got introduced in Maven 3.2.2. For local parent resolution the
version in parent declarations had been ignored completely as of Maven
3.3.0 due to commit be3fb200326208ca4b8c41ebf16d5ae6b8049792 removing
all local parent version validation. Work on fixing this is tracked by
MNG-5840 released with Maven 3.3.9. This commit adds the final missing
bits to make local and remote parent resolution behave the same way as
much as possible. As an exception, remote parent resolution still is a
bit more strict than local parent resolution due to a different API in
use. When resolving a parent from a repository using version ranges, the
ModelBuilder verifies the range in use to declare an upper bound. When
resolving a parent locally using version ranges, those ranges are not
required to declare an upper bound because the API in use does not
support querying that. Authoring a POM relying on this difference should
be considered a bug.
o Added test cases to maven-core testing parent version range resolution
for local and remote parent models.
Integration tests:
------------------
<https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=commit;h=2348fbc31805560fdd6e1a68dbf7b52e00e0e992>
[MNG-2199] Support version ranges in parent elements
o Updated the ITs to correctly detect parent resolution failures. Maven
does not fail the build when it cannot resolve a parent but instead logs
a warning message. The ITs never checked the log to contain the warning
messages but instead asserted the build to fail when a parent cannot be
resolved. The only Maven version supporting parent version ranges is
Maven 3.2.2 due to this.
o Deprecated an incorrect test case for local parent resolution. Maven
ignored the '<version>' in '<parent>' elements for local parent
resolution. The core has been updated across various versions to
eliminate any differences between local and remote parent resolution.
When local parent resolution had been updated to match remote parent
resolution, an existing IT started to fail testing incorrect behaviour.
As soon as the '<parent>' is referenced using a version range, the
'<version>' element in the project becomes mandatory and does no longer
support using an expression any more. This has been that way for remote
parent resolution from day one. It has never been supported to inherit a
version from a parent when referencing that parent using a version range
intentionally.
o Updated to account for updated error messages.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IT] MNG-2199 for 3.5.0
Posted by Stephen Connolly <st...@gmail.com>.
(I am trying to confirm my understanding of the diff:
https://github.com/apache/maven-integration-testing/compare/master...MNG-2199
On 30 January 2017 at 22:19, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> I find it hard to follow your explanations as to what the change is, but I
> think I understand...
>
> could you try and rephrase what your change is because the current
> phrasing is rather more alarming than I suspect it is
>
> On 30 January 2017 at 18:34, Christian Schulte <cs...@schulte.it> wrote:
>
>> Hi,
>>
>> I'd like to merge the MNG-2199 branch to master for 3.5.0. I think this
>> should really go into 3.5.0 and not 3.5.1. Anyone second that? I tried
>> to explain things as much as possible in the commit messages. There also
>> is one IT which needs to be deprecated because it is testing an invalid
>> project to be supported which never should have worked. I copy the
>> commit messages here in case the links stop working sometime in the
>> future. When reviewing the deprecated IT
>> (testValidLocalParentVersionRange), keep in mind that this multi module
>> project
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-integration
>> -testing.git;a=tree;f=core-it-suite/src/test/resources/mng-
>> 2199-parent-version-range/local-parent;h=54f8d7b92a1fbf1
>> ed4837a5e79b48cf23ce2dc25;hb=HEAD>
>>
>> more precisely this module/pom.xml file
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-integration
>> -testing.git;a=blob;f=core-it-suite/src/test/resources/mng-
>> 2199-parent-version-range/local-parent/module/pom.xml;h=
>> 85769ce5af3a46f57ff4f15bb3faa366278d4cec;hb=HEAD>
>>
>> cannot be build with any Maven version prior to 3.3.0 although the test
>> class declared [3.2.2,) as the range to test. You cannot build that
>> project using anything < 3.3.0 and it should not be possible to build
>> that project with anything > 3.3.9 again. So that there are only two
>> Maven releases out there supporting that project. That's why I think
>> this should be fixed in 3.5.0 (ASAP) so that the number of Maven
>> versions suporting that is kept as small as possible (2 - namely 3.3.0
>> and 3.3.9). When in doubt, just try this with various Maven versions <
>> 3.3.0.
>>
>> cd
>> maven-integration-testing/core-it-suite/src/test/resources/
>> mng-2199-parent-version-range/local-parent/module
>>
>> mvn verify
>>
>>
>> Maven:
>> ------
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commi
>> t;h=85e96e3f386b6097750e74f3a07327ca8dbb2b9b>
>>
>> [MNG-2199] Support version ranges in parent elements
>>
>> o Updated to fix parent version range resolution broken since 3.2.3 and
>> to remove parent version range resolution logic obsolete since Maven
>> 3.2.3 which changed the initialization of MavenProject instances.
>> o Updated local parent resolution to behave the same way remote parent
>> resolution behaves. When referencing a parent using version ranges,
>> inheriting the version or using version expressions should not be
>> supported. It has been implemented that way for remote parent resolution
>> as it got introduced in Maven 3.2.2. For local parent resolution the
>> version in parent declarations had been ignored completely as of Maven
>> 3.3.0 due to commit be3fb200326208ca4b8c41ebf16d5ae6b8049792 removing
>> all local parent version validation. Work on fixing this is tracked by
>> MNG-5840 released with Maven 3.3.9. This commit adds the final missing
>> bits to make local and remote parent resolution behave the same way as
>> much as possible. As an exception, remote parent resolution still is a
>> bit more strict than local parent resolution due to a different API in
>> use. When resolving a parent from a repository using version ranges, the
>> ModelBuilder verifies the range in use to declare an upper bound. When
>> resolving a parent locally using version ranges, those ranges are not
>> required to declare an upper bound because the API in use does not
>> support querying that. Authoring a POM relying on this difference should
>> be considered a bug.
>> o Added test cases to maven-core testing parent version range resolution
>> for local and remote parent models.
>>
>> Integration tests:
>> ------------------
>>
>> <https://git-wip-us.apache.org/repos/asf?p=maven-integration
>> -testing.git;a=commit;h=2348fbc31805560fdd6e1a68dbf7b52e00e0e992>
>>
>> [MNG-2199] Support version ranges in parent elements
>>
>> o Updated the ITs to correctly detect parent resolution failures. Maven
>> does not fail the build when it cannot resolve a parent but instead logs
>> a warning message. The ITs never checked the log to contain the warning
>> messages but instead asserted the build to fail when a parent cannot be
>> resolved. The only Maven version supporting parent version ranges is
>> Maven 3.2.2 due to this.
>> o Deprecated an incorrect test case for local parent resolution. Maven
>> ignored the '<version>' in '<parent>' elements for local parent
>> resolution. The core has been updated across various versions to
>> eliminate any differences between local and remote parent resolution.
>> When local parent resolution had been updated to match remote parent
>> resolution, an existing IT started to fail testing incorrect behaviour.
>> As soon as the '<parent>' is referenced using a version range, the
>> '<version>' element in the project becomes mandatory and does no longer
>> support using an expression any more. This has been that way for remote
>> parent resolution from day one. It has never been supported to inherit a
>> version from a parent when referencing that parent using a version range
>> intentionally.
>> o Updated to account for updated error messages.
>>
>> Regards,
>> --
>> Christian
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
Re: [IT] MNG-2199 for 3.5.0
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/31/17 um 01:11 schrieb Stephen Connolly:
> So this sounds like the original tests are wrong.
Correct. They do not catch parent resolution failures although they
should have detected them.
>
> As such we shipped broken versions of Maven. It wasn't ever our intent that
> those projects work with 3.3.x rather a bug in the tests.
Correct.
>
> In that regard *my* personal pref is that all these tests have the range
> starting from [3.2.2,) which would mean that 3.3.9 no longer passes the
> integration tests.
Makes sense.
> Before merging or changing your branch we need to get agreement on how to
> handle bugs in the tests.
There is/was no real process behind the ITs. They were
added/tweaked/disabled without any discussion. +1 for establishing some
kind of process. RTC means there must be people doing the reviews.
> The previous IT fixes where where we were choosing to change the "spec"...
> here is more an errata in the "spec".
>
> I'll see if I can frame the question in a way that will allow for easier
> action going forward some time tomorrow, and then we can see what the
> consensus is.
>
> Wdyt?
Sounds reasonable.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IT] MNG-2199 for 3.5.0
Posted by Stephen Connolly <st...@gmail.com>.
So this sounds like the original tests are wrong.
As such we shipped broken versions of Maven. It wasn't ever our intent that
those projects work with 3.3.x rather a bug in the tests.
In that regard *my* personal pref is that all these tests have the range
starting from [3.2.2,) which would mean that 3.3.9 no longer passes the
integration tests.
Before merging or changing your branch we need to get agreement on how to
handle bugs in the tests.
The previous IT fixes where where we were choosing to change the "spec"...
here is more an errata in the "spec".
I'll see if I can frame the question in a way that will allow for easier
action going forward some time tomorrow, and then we can see what the
consensus is.
Wdyt?
On Mon 30 Jan 2017 at 22:49, Christian Schulte <cs...@schulte.it> wrote:
> Am 01/30/17 um 23:19 schrieb Stephen Connolly:
> > I find it hard to follow your explanations as to what the change is, but
> I
> > think I understand...
> >
> > could you try and rephrase what your change is because the current
> phrasing
> > is rather more alarming than I suspect it is
>
> 1. The commit to the core is fixing external parent version range
> resolution and adds missing version validation to local parent version
> range resolution. External parent version range resolution got
> introduced in 3.2.2 and was working there. When I wrote the initial ITs,
> I did not notice that Maven just logs a warning when it fails to build a
> parent MavenProject instead of failing the build. As a consequence, one
> of the first commits after the release of 3.2.2 broke external parent
> version ranges without the ITs starting to fail. I updated the ITs to
> check for that warning message so that they start to fail as expected.
> That means you cannot run the updated ITs with anything > 3.2.2 as they
> will start to fail (expected) due to external parent version ranges
> being broken. The changes to class
> 'MavenITmng2196ParentResolutionTest.java' are fixing the ITs to fail as
> expected.
>
> 2. When working on MNG-2199 for 3.2.2, I wasn't sure how the local
> parent resolution is to be performed and decided to not do anything
> about it. During development of 3.3.0, there is a commit removing
> version comparison so that what you put into a <parent>'s <version>
> element is more or less ignored. There must be a value but that value is
> not checked any further breaking local Maven parent coordinates in an
> unexpected way. You noticed something is wrong and filed MNG-5840 and
> fixed the issue. Noticing external parent version ranges are broken I
> started to work on it again for - back then - 3.4.0. Reading the local
> parent resolution code again, I noticed your changes and also noticed
> that the behaviour I wasn't sure about wasn't intention - you fixed it.
> Looking at your fixes I noticed that external parent version range
> resolution is more strict than local parent version range resolution and
> that the local parent version range resolution is lacking some
> validation performed for external parent version range resolution. The
> missing validation is this:
>
> If a parent is referenced using a version range, the project version
> must be a constant - that is - it cannot be inherited and it cannot use
> expressions.
>
> For the expression case, there already would have been a warning
> message. Reason for not supporting this was due to objections mentioned
> in the MNG-2199 JIRA issue. If you deploy a POM referencing it's parent
> using a version range, the POM version must not change in any way due to
> inheriting it from any of the parent's of the range or by using an
> expression, which may also be declared in those said parents. That
> validation is saving us from versions of deployed POMs changing due to
> parent version range resolution resolving to the highest available
> parent available. Shorter form: Deploy a new parent and all children
> referencing that parent like GID:AID:RANGE would inherit a different
> project version or different property value. Adding this lacking
> validation to local parent version range resolution, there was an IT
> testing that you can inherit a version from a parent referenced using a
> range. I moved that test out of class
> 'MavenITmng2196ParentResolutionTest.java' into a new class
> 'MavenITmng2199DeprecatedParentVersionRangeTest.java'. That new class is
> running the unchanged test but declares a different range of Maven
> versions. Initially it would have run against [3.2.2,) although the
> project cannot be build with any Maven version < 3.3.0. The only change
> to the IT is the range I updated to [3.3.0,3.3.9]. That's the only
> changes to ITs. The addition of class
> 'MavenITmng2199ParentVersionRange350Test.java' is just adding ITs for
> the local parent version range resolution.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone
Re: [IT] MNG-2199 for 3.5.0
Posted by Christian Schulte <cs...@schulte.it>.
Am 01/30/17 um 23:19 schrieb Stephen Connolly:
> I find it hard to follow your explanations as to what the change is, but I
> think I understand...
>
> could you try and rephrase what your change is because the current phrasing
> is rather more alarming than I suspect it is
1. The commit to the core is fixing external parent version range
resolution and adds missing version validation to local parent version
range resolution. External parent version range resolution got
introduced in 3.2.2 and was working there. When I wrote the initial ITs,
I did not notice that Maven just logs a warning when it fails to build a
parent MavenProject instead of failing the build. As a consequence, one
of the first commits after the release of 3.2.2 broke external parent
version ranges without the ITs starting to fail. I updated the ITs to
check for that warning message so that they start to fail as expected.
That means you cannot run the updated ITs with anything > 3.2.2 as they
will start to fail (expected) due to external parent version ranges
being broken. The changes to class
'MavenITmng2196ParentResolutionTest.java' are fixing the ITs to fail as
expected.
2. When working on MNG-2199 for 3.2.2, I wasn't sure how the local
parent resolution is to be performed and decided to not do anything
about it. During development of 3.3.0, there is a commit removing
version comparison so that what you put into a <parent>'s <version>
element is more or less ignored. There must be a value but that value is
not checked any further breaking local Maven parent coordinates in an
unexpected way. You noticed something is wrong and filed MNG-5840 and
fixed the issue. Noticing external parent version ranges are broken I
started to work on it again for - back then - 3.4.0. Reading the local
parent resolution code again, I noticed your changes and also noticed
that the behaviour I wasn't sure about wasn't intention - you fixed it.
Looking at your fixes I noticed that external parent version range
resolution is more strict than local parent version range resolution and
that the local parent version range resolution is lacking some
validation performed for external parent version range resolution. The
missing validation is this:
If a parent is referenced using a version range, the project version
must be a constant - that is - it cannot be inherited and it cannot use
expressions.
For the expression case, there already would have been a warning
message. Reason for not supporting this was due to objections mentioned
in the MNG-2199 JIRA issue. If you deploy a POM referencing it's parent
using a version range, the POM version must not change in any way due to
inheriting it from any of the parent's of the range or by using an
expression, which may also be declared in those said parents. That
validation is saving us from versions of deployed POMs changing due to
parent version range resolution resolving to the highest available
parent available. Shorter form: Deploy a new parent and all children
referencing that parent like GID:AID:RANGE would inherit a different
project version or different property value. Adding this lacking
validation to local parent version range resolution, there was an IT
testing that you can inherit a version from a parent referenced using a
range. I moved that test out of class
'MavenITmng2196ParentResolutionTest.java' into a new class
'MavenITmng2199DeprecatedParentVersionRangeTest.java'. That new class is
running the unchanged test but declares a different range of Maven
versions. Initially it would have run against [3.2.2,) although the
project cannot be build with any Maven version < 3.3.0. The only change
to the IT is the range I updated to [3.3.0,3.3.9]. That's the only
changes to ITs. The addition of class
'MavenITmng2199ParentVersionRange350Test.java' is just adding ITs for
the local parent version range resolution.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [IT] MNG-2199 for 3.5.0
Posted by Stephen Connolly <st...@gmail.com>.
I find it hard to follow your explanations as to what the change is, but I
think I understand...
could you try and rephrase what your change is because the current phrasing
is rather more alarming than I suspect it is
On 30 January 2017 at 18:34, Christian Schulte <cs...@schulte.it> wrote:
> Hi,
>
> I'd like to merge the MNG-2199 branch to master for 3.5.0. I think this
> should really go into 3.5.0 and not 3.5.1. Anyone second that? I tried
> to explain things as much as possible in the commit messages. There also
> is one IT which needs to be deprecated because it is testing an invalid
> project to be supported which never should have worked. I copy the
> commit messages here in case the links stop working sometime in the
> future. When reviewing the deprecated IT
> (testValidLocalParentVersionRange), keep in mind that this multi module
> project
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-
> integration-testing.git;a=tree;f=core-it-suite/src/test/
> resources/mng-2199-parent-version-range/local-parent;h=
> 54f8d7b92a1fbf1ed4837a5e79b48cf23ce2dc25;hb=HEAD>
>
> more precisely this module/pom.xml file
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-
> integration-testing.git;a=blob;f=core-it-suite/src/test/
> resources/mng-2199-parent-version-range/local-parent/module/pom.xml;h=
> 85769ce5af3a46f57ff4f15bb3faa366278d4cec;hb=HEAD>
>
> cannot be build with any Maven version prior to 3.3.0 although the test
> class declared [3.2.2,) as the range to test. You cannot build that
> project using anything < 3.3.0 and it should not be possible to build
> that project with anything > 3.3.9 again. So that there are only two
> Maven releases out there supporting that project. That's why I think
> this should be fixed in 3.5.0 (ASAP) so that the number of Maven
> versions suporting that is kept as small as possible (2 - namely 3.3.0
> and 3.3.9). When in doubt, just try this with various Maven versions <
> 3.3.0.
>
> cd
> maven-integration-testing/core-it-suite/src/test/
> resources/mng-2199-parent-version-range/local-parent/module
>
> mvn verify
>
>
> Maven:
> ------
>
> <https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=
> 85e96e3f386b6097750e74f3a07327ca8dbb2b9b>
>
> [MNG-2199] Support version ranges in parent elements
>
> o Updated to fix parent version range resolution broken since 3.2.3 and
> to remove parent version range resolution logic obsolete since Maven
> 3.2.3 which changed the initialization of MavenProject instances.
> o Updated local parent resolution to behave the same way remote parent
> resolution behaves. When referencing a parent using version ranges,
> inheriting the version or using version expressions should not be
> supported. It has been implemented that way for remote parent resolution
> as it got introduced in Maven 3.2.2. For local parent resolution the
> version in parent declarations had been ignored completely as of Maven
> 3.3.0 due to commit be3fb200326208ca4b8c41ebf16d5ae6b8049792 removing
> all local parent version validation. Work on fixing this is tracked by
> MNG-5840 released with Maven 3.3.9. This commit adds the final missing
> bits to make local and remote parent resolution behave the same way as
> much as possible. As an exception, remote parent resolution still is a
> bit more strict than local parent resolution due to a different API in
> use. When resolving a parent from a repository using version ranges, the
> ModelBuilder verifies the range in use to declare an upper bound. When
> resolving a parent locally using version ranges, those ranges are not
> required to declare an upper bound because the API in use does not
> support querying that. Authoring a POM relying on this difference should
> be considered a bug.
> o Added test cases to maven-core testing parent version range resolution
> for local and remote parent models.
>
> Integration tests:
> ------------------
>
> <https://git-wip-us.apache.org/repos/asf?p=maven-
> integration-testing.git;a=commit;h=2348fbc31805560fdd6e1a68dbf7b5
> 2e00e0e992>
>
> [MNG-2199] Support version ranges in parent elements
>
> o Updated the ITs to correctly detect parent resolution failures. Maven
> does not fail the build when it cannot resolve a parent but instead logs
> a warning message. The ITs never checked the log to contain the warning
> messages but instead asserted the build to fail when a parent cannot be
> resolved. The only Maven version supporting parent version ranges is
> Maven 3.2.2 due to this.
> o Deprecated an incorrect test case for local parent resolution. Maven
> ignored the '<version>' in '<parent>' elements for local parent
> resolution. The core has been updated across various versions to
> eliminate any differences between local and remote parent resolution.
> When local parent resolution had been updated to match remote parent
> resolution, an existing IT started to fail testing incorrect behaviour.
> As soon as the '<parent>' is referenced using a version range, the
> '<version>' element in the project becomes mandatory and does no longer
> support using an expression any more. This has been that way for remote
> parent resolution from day one. It has never been supported to inherit a
> version from a parent when referencing that parent using a version range
> intentionally.
> o Updated to account for updated error messages.
>
> Regards,
> --
> Christian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>