maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <>
Subject User Community was (Re: number of bugs in maven-release-plugin)
Date Sat, 27 Jun 2015 11:36:03 GMT
Hi Robert,

On 6/27/15 12:51 PM, wrote:
> Sorry for butting in but as someone who is a staunch supporter of
 > Maven within my company and its user community,
 > I have to agree that the difficulty in engaging
 > the Maven developers to even discuss issues
 > is too high.

First i would be interested in examples of this kind, cause
unfortunately i have to say i never saw your name on the dev/users 
list...nor can i remember about your name in jira issue (I have admit 
that i'm not that long part of the Maven team but i'm reading the list a 
longer time)..may be just i oversight or mistaken something....

 > I often find myself fixing plugins by forking
 > my own private versions since doing
 > anything else is too slow/painful.

Can you give some examples (or a list of them) of those fixes and for 
which plugins you have to do so? And how often in number is ?

> Sorry for the intrusion...

No excuse needed and that's no intrusion.......

It is very important that someone raises his hand that there is 
something which need to pay attention to....

> Robert Patrick <>
> VP, Oracle Corporation
> Mobile: +1.469.556.9450
> Sent from my iDevice
> On Jun 27, 2015, at 5:36 PM, Tibor Digana <> wrote:
>>>> And without the ability to verify both the bug and
>> the fix *I* won't apply those patches (unless the code clearly exposes the
>> issue).
>> This is the problem. My colleague told me to have a look in ASF JIRA and see
>> how many people provided patches. He said that he dislikes Maven community
>> because of this reason they ignore their patches.

The problem of many patches is simply they lack of tests, i often write 
to them they should produce tests...but i often get the feedback: I 
don't have time to write test just fix it...or i don't get any feedback 
at all...

Furthermore as Robert Scholte mentioned people often see only their 
limited scope which often conflicts with the whole idea's, concept of 
Maven / Plugins in general...which results in not acceptiong patches...

>> So we should not be wondering that competitors are preferable because they
>> can apply Groovy and patch directly in the script without asking us.

Which would exactly results in coded builds which is in the end much 
more complicated and worse maintainable than any Maven build every be....

 > Unless
>> we understand this situation, the Maven will loose the reputation and most
>> probably existing users.
>> And back to your experiences with applying patches.
>> I would at least try to install SCM, like Perforce server, and try to play
>> with that. If not possible, I would make a branch and deploy the plugin as
>> SNAPSHOT and let the person in Jira to retest it.
>> The trick is that the status cannot be worse then it is now. Because if it
>> is a good fix then our plugin has one bug less. If the fix is candidate to
>> open another bug, then the number of bugs shortly decreased but is not worse
>> than it was before.
>> Example, what happened in surefire project. User reported bug in 2.18 with
>> race condition in parallel tests. I could not reproduce the bug however
>> understood the root cause. So we made an agreement that I will fix it in
>> master and let the user test the SNAPSHOT version. He proved good fix.
>> Otherwise I would revert the fix from HEAD.
>> Sounds this works, hm?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message