Hi Robert,
On 6/27/15 2:40 PM, [email protected] wrote:
I have only tried to interact a few times myself (others in my team have tried
as well).
> The first time, my team and I get a patch we submitted
>to enhance the wagon-http for SSO-protected repositories adopted
thanks to Olivier Lamy.
Successful...done.
The second time, I tried to interact around someone else's problem with
mvnDebug.cmd. No one ever responded.
Ok...Nr. 1.
My current problem, that I posted to the new versions plugin Google group
yesterday,
> is one that someone from JBoss posted about a year ago
> but seems to have never been addressed.
> That is, being able to update dependency versions where the scope
> is set to import using the use-latest-releases goal.
> You can sort of workaround it using update-properties but that
> goal lacks the ability to constrain the segment of the
> version number that gets updated. (i.e., use-latest-releases
> goal's allowMajorUpdates, allowMinorUpdates, allowIncrementalUpdates).
This is MojoHaus versions maven plugin and i saw it.....
My team created a number of custom plugins where we
> used code and modified it for our purposes to
> function like we wanted.
Ok...
Had there be any suggestions to the original plugins (JIRA issues etc)
to improve the funcitonality according to what you or you team members
suggested ?
> I don't think enumerating those are particularly important...
That's weird, cause you don't think it's important.
Hm..I have explicitly asked for exactly that kind of information...
But this is the point. So how could i do anything if i don't have any
kind of information which i explictly asked for?
I don't want to cause trouble or get into some huge debate.
You don't cause trouble...a discussion might make sense...debate is an
other story...
I am giving you my perception. You can choose to take it as feedback
or not, that is your choice.
Robert Patrick <[email protected]>
VP, Oracle Corporation
Mobile: +1.469.556.9450
Sent from my iDevice
On Jun 27, 2015, at 6:36 PM, Karl Heinz Marbaise <[email protected]> wrote:
Hi Robert,
On 6/27/15 12:51 PM, [email protected] 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 <[email protected]>
VP, Oracle Corporation
Mobile: +1.469.556.9450
Sent from my iDevice
On Jun 27, 2015, at 5:36 PM, Tibor Digana <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
