On 29 July 2015 at 13:10, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:
> 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.
>
In case somebody asks, the reason I cannot just do
cd ../parent && git checkout stable && cd ..
is that in my case there are about 30 modules inter-related like this and
they all have different degrees of WIP which would need to be stashed
before switching branches... and in any case I would actually have to check
out the corresponding release version tags and not the stable branch as
that will have -SNAPSHOT versions and may have unreleased changes
>
> 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
>>
>>
>
