So I hit the original MNG-5840 with non-version range parents doing
something like the following.
git clone {parent,client,server}
Note that client and server both have
<relativePath>../parent/pom.xml</relativePath>
Working away on server I spot a critical bug that needs fixing.
cd server
git stash # so that I can switch branches easily
git checkout stable
git stash pop # recover my WIP
git add -p # add only the fix from the large set of unrelated changes
git commit -m "critical fix"
git stash # so that I can take the remaining WIP back to master
git checkout master
git merge stable # we always merge from stable up to master
git checkout stable
mvn release:prepare release:perform
git checkout master
git merge -s ours stable # mark the pom changes for release as merged
git push origin stable master
git stash pop # recover the WIP and clear the stash list
cd ..
and continue working
I expect that the `mvn release:prepare release:perform` will be ok... but
the release:prepare blew up because parent's stable branch doesn't have the
same findbugs sensitivity and as a result when using the newer release of
parent the build fails due to the findbugs complaining about potential null
pointers that are not actual null pointers.
Now I'd be ok if we got as far as release:perform as that would be in
stable/target/checkout and thus that would be forced to resolve the
referenced pom... but that is just luck.
There are all sorts of changes that I might have made in the master branch
of parent... I may have changed the dependency management... and thus I
could be using methods that are not available in the stable branch so that
release:prepare will work but release:perform will fail to compile.
It is not reasonable to expect me to have to set up a separate clone of the
project just for maintenance porting.
Now we could make the change for MNG-5840 just check if the parent version
contains one of the following characters [ ( or , since if any of those
three characters are missing it must be a single version. That would avoid
needing maven-artifact's version range parser... BUT now I cannot use
parent version ranges with my workflow above... and having been burned
multiple times by this issue I would not be happy to ship a release that
let any MNG-5840 style failures fall through.
On 29 July 2015 at 01:11, Jason van Zyl <ja...@takari.io> wrote:
> At first blush this change seems like a bad idea to me. I consider the
> reactor/multi-module project an atomic unit and this change runs counter to
> that. Why do you want a parent installed instead of everything working
> cohesively within the reactor?
>
> Are you trying to build part of the tree for some reason and cannot build
> it all together? Or are you stepping into a module and trying to build it
> by itself? I understand that there are limitations and there needs to be a
> way to build within the context of a reactor regardless of where you are
> but I’m not sure I want us to have to support this feature forever.
>
> Can you provide a little more background please.
>
> > On Jul 23, 2015, at 2:06 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> >
> > It's not completely ugly, but it does entangle dependencies further
> which I
> > view as ugly.
> >
> > There is an existing todo above this code to move the validation to a
> > different module, so I believe this will all get removed at that time
> >
> > On Thursday, July 23, 2015, Benson Margulies <bimargul...@gmail.com>
> wrote:
> >
> >> If this change is so ugly, why are there no comments explaining the
> ugly?
> >> On Jul 23, 2015 10:48 AM, "jvanzyl" <g...@git.apache.org <javascript:;>>
> >> wrote:
> >>
> >>> Github user jvanzyl commented on the pull request:
> >>>
> >>> https://github.com/apache/maven/pull/60#issuecomment-124129817
> >>>
> >>> I'm out in the middle of nowhere, but i'll cancel the vote, test and
> >>> re-roll once I'm back to civilization.
> >>>
> >>>
> >>> ---
> >>> 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 <javascript:;> or
> >> file a JIRA ticket
> >>> with INFRA.
> >>> ---
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> <javascript:;>
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >> <javascript:;>
> >>>
> >>>
> >>
> >
> >
> > --
> > Sent from my phone
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> ---------------------------------------------------------
>
> happiness is like a butterfly: the more you chase it, the more it will
> elude you, but if you turn your attention to other things, it will come
> and sit softly on your shoulder ...
>
> -- Thoreau
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
