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.
The second time, I tried to interact around someone else's problem with mvnDebug.cmd. No one ever responded. 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). My team created a number of custom plugins where we used code and modified it for our purposes to function like we wanted. I don't think enumerating those are particularly important... I don't want to cause trouble or get into some huge debate. 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
