You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Stephen Connolly <st...@gmail.com> on 2015/06/05 11:42:32 UTC

[MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

https://issues.apache.org/jira/browse/MNG-5840

Can some other people see if this test case I attached to this issue is
replicated in their environments?

I've been badly bitten by this a couple of times (and worse for me, I have
a project that needs 3.3.1+ to build due to bugs that were only fixed in
the 3.3 series)

I only now had the time to try and create a minimal test case

-Stephen

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

Posted by Stephen Connolly <st...@gmail.com>.
I expect it to pass because the local repository has the correct version.

Consider the case where you have separate GIT roots for your different
modules (because they have a separate release lifecycle)

Your parent project will have version 4-SNAPSHOT
The sibling child project will reference parent version 3, expecting
resolution from the repository

Normally you won't see much of a problem because you will be updating to
the latest parent after each release... hence why this is subtle.

Where I found this was when I switched the child branch to a previous
stable branch to work on a bug fix... and because the wrong parent was
being resolved my project would not build.

Work-around has been to then switch the parent back to the matching branch.

On 5 June 2015 at 11:05, Fred Cooke <fr...@gmail.com> wrote:

> Your tar file is polluted with ._ stuff that ends up laying around the
> place. Aside from that:
>
> 3.1.1 succeeds.
> 3.3.3 fails
>
> The description of what is wrong/your expectation could be better.
>
> I guess I would expect it to fail, but fail because relative path POM
> version doesn't match that specified.
>
>
> On Fri, Jun 5, 2015 at 9:42 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > https://issues.apache.org/jira/browse/MNG-5840
> >
> > Can some other people see if this test case I attached to this issue is
> > replicated in their environments?
> >
> > I've been badly bitten by this a couple of times (and worse for me, I
> have
> > a project that needs 3.3.1+ to build due to bugs that were only fixed in
> > the 3.3 series)
> >
> > I only now had the time to try and create a minimal test case
> >
> > -Stephen
> >
>

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

Posted by Stephen Connolly <st...@gmail.com>.
On 5 June 2015 at 13:04, Fred Cooke <fr...@gmail.com> wrote:

> It still seems correct as per the quote provided above, even if it didn't
> used to work this way. Is there anywhere else where it specifies the
> behaviour that you've come to expect?
>
> I see a few cases:
>
> gid + aid = error or at least warning for no version, unless ../pom.xml
> exists
> gid + aid + ver = success if ver available, though according to docs
> ../pom.xml should make it succeed.
> gid + aid + relpath = success if relpath available
> gid + aid + ver + relpath = ?
>
> during build, vs during release
> specified version is snapshot or not
> relpath version is snapshot or not
> versions match or don't
> path specified exists, or not
>
> I agree that if it's using some snapshot (even if resolved through the
> relative path) during a release, that's wrong/bad/evil. But the rest of the
> time?
>
> The language seems pretty clear "Maven looks for the parent POM first in
> this location on the filesystem, then the local repository, and lastly in
> the remote repo."
>

And if any of the GAV is different then it isn't the parent pom, so Maven
needs to keep looking


>
> On Fri, Jun 5, 2015 at 10:56 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > Fred: does
> >
> >
> https://issues.apache.org/jira/browse/MNG-5840?focusedCommentId=14574303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14574303
> > explain the issue better?
> >
> > On 5 June 2015 at 11:05, Fred Cooke <fr...@gmail.com> wrote:
> >
> > > Your tar file is polluted with ._ stuff that ends up laying around the
> > > place. Aside from that:
> > >
> > > 3.1.1 succeeds.
> > > 3.3.3 fails
> > >
> > > The description of what is wrong/your expectation could be better.
> > >
> > > I guess I would expect it to fail, but fail because relative path POM
> > > version doesn't match that specified.
> > >
> > >
> > > On Fri, Jun 5, 2015 at 9:42 PM, Stephen Connolly <
> > > stephen.alan.connolly@gmail.com> wrote:
> > >
> > > > https://issues.apache.org/jira/browse/MNG-5840
> > > >
> > > > Can some other people see if this test case I attached to this issue
> is
> > > > replicated in their environments?
> > > >
> > > > I've been badly bitten by this a couple of times (and worse for me, I
> > > have
> > > > a project that needs 3.3.1+ to build due to bugs that were only fixed
> > in
> > > > the 3.3 series)
> > > >
> > > > I only now had the time to try and create a minimal test case
> > > >
> > > > -Stephen
> > > >
> > >
> >
>

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

Posted by Fred Cooke <fr...@gmail.com>.
It still seems correct as per the quote provided above, even if it didn't
used to work this way. Is there anywhere else where it specifies the
behaviour that you've come to expect?

I see a few cases:

gid + aid = error or at least warning for no version, unless ../pom.xml
exists
gid + aid + ver = success if ver available, though according to docs
../pom.xml should make it succeed.
gid + aid + relpath = success if relpath available
gid + aid + ver + relpath = ?

during build, vs during release
specified version is snapshot or not
relpath version is snapshot or not
versions match or don't
path specified exists, or not

I agree that if it's using some snapshot (even if resolved through the
relative path) during a release, that's wrong/bad/evil. But the rest of the
time?

The language seems pretty clear "Maven looks for the parent POM first in
this location on the filesystem, then the local repository, and lastly in
the remote repo."

On Fri, Jun 5, 2015 at 10:56 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> Fred: does
>
> https://issues.apache.org/jira/browse/MNG-5840?focusedCommentId=14574303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14574303
> explain the issue better?
>
> On 5 June 2015 at 11:05, Fred Cooke <fr...@gmail.com> wrote:
>
> > Your tar file is polluted with ._ stuff that ends up laying around the
> > place. Aside from that:
> >
> > 3.1.1 succeeds.
> > 3.3.3 fails
> >
> > The description of what is wrong/your expectation could be better.
> >
> > I guess I would expect it to fail, but fail because relative path POM
> > version doesn't match that specified.
> >
> >
> > On Fri, Jun 5, 2015 at 9:42 PM, Stephen Connolly <
> > stephen.alan.connolly@gmail.com> wrote:
> >
> > > https://issues.apache.org/jira/browse/MNG-5840
> > >
> > > Can some other people see if this test case I attached to this issue is
> > > replicated in their environments?
> > >
> > > I've been badly bitten by this a couple of times (and worse for me, I
> > have
> > > a project that needs 3.3.1+ to build due to bugs that were only fixed
> in
> > > the 3.3 series)
> > >
> > > I only now had the time to try and create a minimal test case
> > >
> > > -Stephen
> > >
> >
>

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

Posted by Stephen Connolly <st...@gmail.com>.
Fred: does
https://issues.apache.org/jira/browse/MNG-5840?focusedCommentId=14574303&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14574303
explain the issue better?

On 5 June 2015 at 11:05, Fred Cooke <fr...@gmail.com> wrote:

> Your tar file is polluted with ._ stuff that ends up laying around the
> place. Aside from that:
>
> 3.1.1 succeeds.
> 3.3.3 fails
>
> The description of what is wrong/your expectation could be better.
>
> I guess I would expect it to fail, but fail because relative path POM
> version doesn't match that specified.
>
>
> On Fri, Jun 5, 2015 at 9:42 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > https://issues.apache.org/jira/browse/MNG-5840
> >
> > Can some other people see if this test case I attached to this issue is
> > replicated in their environments?
> >
> > I've been badly bitten by this a couple of times (and worse for me, I
> have
> > a project that needs 3.3.1+ to build due to bugs that were only fixed in
> > the 3.3 series)
> >
> > I only now had the time to try and create a minimal test case
> >
> > -Stephen
> >
>

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

Posted by Fred Cooke <fr...@gmail.com>.
Your tar file is polluted with ._ stuff that ends up laying around the
place. Aside from that:

3.1.1 succeeds.
3.3.3 fails

The description of what is wrong/your expectation could be better.

I guess I would expect it to fail, but fail because relative path POM
version doesn't match that specified.


On Fri, Jun 5, 2015 at 9:42 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

> https://issues.apache.org/jira/browse/MNG-5840
>
> Can some other people see if this test case I attached to this issue is
> replicated in their environments?
>
> I've been badly bitten by this a couple of times (and worse for me, I have
> a project that needs 3.3.1+ to build due to bugs that were only fixed in
> the 3.3 series)
>
> I only now had the time to try and create a minimal test case
>
> -Stephen
>

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

Posted by Stephen Connolly <st...@gmail.com>.
On 5 June 2015 at 10:58, Tamas Cservenak <ta...@cservenak.net> wrote:

> Same here, testcase does same as for you:
> https://gist.github.com/cstamas/dd6a000e97b2c5333f01
>
> But isn’t this the intended way?
> If parent found on relative path, it takes precendence over one coming
> from local/remote repo?
>

only if the GAV matches

If the project omits the project.parent.version then we should take
whatever version is at that path, but if we specify a different GAV then
maven should resolve from the repo... currently 3.3.1&3.3.3 resolve from
the repo if the GA differs. 3.2.5 also resolved from the repo when the
versions differ.

In any case I believe I have fixed this with
https://github.com/apache/maven/commit/40d5087b6b134842e2b61a567dbb4bfbcfab7ae6


>
> As per http://maven.apache.org/pom.html#Inheritance
>
> "Notice the relativePath element. It is not required, but may be used as a
> signifier to Maven to first search the path given for this project's
> parent, before searching the local and then remote repositories."
>
> --
> Thanks,
> ~t~
>
> On 5 Jun 2015 at 11:42:42, Stephen Connolly (
> stephen.alan.connolly@gmail.com) wrote:
>
> https://issues.apache.org/jira/browse/MNG-5840
>
> Can some other people see if this test case I attached to this issue is
> replicated in their environments?
>
> I've been badly bitten by this a couple of times (and worse for me, I have
> a project that needs 3.3.1+ to build due to bugs that were only fixed in
> the 3.3 series)
>
> I only now had the time to try and create a minimal test case
>
> -Stephen
>

Re: [MNG-5840] IMHO critical regression in Maven 3.3.1 & 3.3.3

Posted by Tamas Cservenak <ta...@cservenak.net>.
Same here, testcase does same as for you:
https://gist.github.com/cstamas/dd6a000e97b2c5333f01

But isn’t this the intended way? 
If parent found on relative path, it takes precendence over one coming from local/remote repo?

As per http://maven.apache.org/pom.html#Inheritance

"Notice the relativePath element. It is not required, but may be used as a signifier to Maven to first search the path given for this project's parent, before searching the local and then remote repositories."

-- 
Thanks,
~t~

On 5 Jun 2015 at 11:42:42, Stephen Connolly (stephen.alan.connolly@gmail.com) wrote:

https://issues.apache.org/jira/browse/MNG-5840  

Can some other people see if this test case I attached to this issue is  
replicated in their environments?  

I've been badly bitten by this a couple of times (and worse for me, I have  
a project that needs 3.3.1+ to build due to bugs that were only fixed in  
the 3.3 series)  

I only now had the time to try and create a minimal test case  

-Stephen