maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: number of bugs in maven-release-plugin
Date Sun, 28 Jun 2015 13:22:46 GMT
On Sat, Jun 27, 2015 at 5:34 PM, Fred Cooke <fred.cooke@gmail.com> wrote:
> Benson, I'm curious as to what you did, and also how it broke both for Git
> users and other users. Any links/refs/bugs/emails/etc to read?

It's been a while, but here's the narrative as I recall it.

(background: before 2.5, the m-r-p completely broke for git, and it
took some fixing. I don't think I was involved.)

Several people reported that you couldn't make the m-r-p work when the
maven project you were releasing was not at the root of the repo. This
was/is a documented feature, facilitated by a specific parameter in
the pom, that informs the release plugin of the relative location of
the pom in the project. (You might ask yourself: why can't the plugin
figure this out for itself?)

I tracked down an explanation for this with the version of git I was
using, and I made a fix. As I recall, the git people had changed the
format of some information produced in supposed porcelain mode (which
is supposed to produce a robust API.) Or, maybe the m-r-p wasn't
properly using porcelain. I can't recall. Anyhow, I added an
integration test (a task made truly awful by the fact that the plugins
are trapped supporting Maven 2, and the test support classes for this
sort of thing in Maven 2 are poorly documented and understood), it
passed, I committed, we released.

And promptly, some people reported some combination of 'the fix
doesn't fix for me' and perhaps also 'it used to work for me and now
it does not.'

I don't think that I _ever_ got it to work for all the users who complained.


>
> Was it just a case of leveraging features only available in very new
> versions? A data point if so:
>
> This sid laptop 2.1.3
> My wheezy server 1.7.10.4
> Work ucuntu 14.10 box 2.1.0
> Current win git default 1.9.5
>
> However I believe I've been using it since 1.5 or 1.6 or maybe earlier and
> the core functionality is virtually unchanged since then, no? I remember
> the porcelain stuff changing, so perhaps it was this?
>
> egit/jgit has some serious flaws that render certain projects unusable with
> it (Java limitation on symlinks)
>
> It also seems/seemed to completely ignore ~/.ssh/config and other similar
> things. I forget the details as I'm pretty sure I use real git in my parent
> pom setup.
>
> Regards,
>
> Fred.
>
> On Sun, Jun 28, 2015 at 5:01 AM, Benson Margulies <bimargulies@gmail.com>
> wrote:
>
>> Tibor,
>>
>> Well, we'll see. Let's parse this situation into some smaller ones. We
>> don't need any votes. We need initiative coupled with enough time,
>> knowledge, and energy to make progress.
>>
>> There's the maven core and the pom. Quite a while ago, I tried to push
>> this; but I don't have the necessary intellectual investment in the maven
>> core to lead here. The community needn't / shouldn't wait for Jason, but
>> the problem of 'we can't change the pom, all those other tools will bust'
>> is a hard problem.
>>
>> Then we have plugins. In my entirely personal opinion, there are too many
>> plugins inside the Apache Maven project. We would be more successful, I
>> submit, if the formal project owned a very minimal set of completely
>> essential plugins, and the others were maintained by communities of the
>> interested. Does the release plugin belong inside or outside?
>>
>> From a functional standpoint, I prefer the gitflow maven plugin to the
>> maven-release-plugin. Sadly, the gitflow plugin is much too buggy for
>> production use. It does actual merges, and sometimes they fail and leave a
>> less. So I try to fix problems in the release plugin when they bite me.
>>
>> Right now, the release plugin rides on top of the SCM plugin. The SCM
>> plugin tries to be completely general. The release plugin has very specific
>> needs: update versions in poms, check them in, create tags, check out at
>> tags. Maybe we'd have a happier release plugin if it had a tailored
>> abstraction. Maybe not.
>>
>> --benson
>>
>>
>>
>>
>>
>>
>> On Sat, Jun 27, 2015 at 10:14 AM, Tibor Digana <tibordigana@apache.org>
>> wrote:
>>
>> > @Benson
>> >
>> > Excellent!
>> >
>> > Since you have good inside of this problem you should post a Vote with
>> this
>> > list of activities and I hope that others will extend it.
>> >
>> > As you and Robert Scholte described, the situation around
>> > maven-release-plugin and SCM artifacts is pathetic. I hope Jason will
>> bring
>> > some inspiration to make us all more optimistic.
>> >
>> >
>> >
>> > --
>> > View this message in context:
>> >
>> http://maven.40175.n5.nabble.com/number-of-bugs-in-maven-release-plugin-tp5838696p5838800.html
>> > Sent from the Maven Developers mailing list archive at Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>> >
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message