2012/7/3 Milos Kleint <[email protected]>: > Can I proceed in usual github way and request a pull? or I just create > a diff file and apply to the svn source base myself? As you prefer. Perso I use: git svn dcommit. Did you setup your local clone to use git svn ?
> > Milos > > On Tue, Jul 3, 2012 at 5:00 PM, Olivier Lamy <[email protected]> wrote: >> sounds good (at least for me :-) ). >> >> 2012/7/3 Milos Kleint <[email protected]>: >>> done >>> https://github.com/mkleint/maven-3/commit/2ca8e13135e34f5df7cde0a86e37b533de3be676 >>> >>> Milos >>> >>> On Mon, Jul 2, 2012 at 12:19 AM, Olivier Lamy <[email protected]> wrote: >>>> 2012/7/1 Milos Kleint <[email protected]>: >>>>> On Sun, Jul 1, 2012 at 9:30 AM, Olivier Lamy <[email protected]> wrote: >>>>>> 2012/6/29 Milos Kleint <[email protected]>: >>>>>>> I forgot to mention in previous reply that one important constraint is >>>>>>> that Every single addition needs to fill out the Version value. The >>>>>>> default maven processing makes no use of it and proceeds as before. >>>>>>> Only in the IDE's subclass we will use it to throw exception or not. >>>>>>> If a request or parameter bean can ensure that every new addition in >>>>>>> the future contains the version value, then I'm fine with it. Having >>>>>>> a new mandatory parameter seems like the safest way to go ahead.. >>>>>> >>>>>> At least having such data structure: >>>>>> >>>>>> private final Version version; >>>>>> >>>>>> public ModelProblemCollectorRequest(Version version) >>>>>> { >>>>>> this.version = version; >>>>>> } >>>>> >>>>> I don't really have a strong preference here. I just went with as >>>>> little change as possible. If a request style code is better, I'm fine >>>>> with it.. >>>> Code style always a subjective problem :-). >>>> Perso, I prefer this way as it's more easy to improve/enhance the data >>>> structure later >>>>> >>>>> >>>>>> >>>>>> BTW nothing prevents to pass null here :-). >>>>> >>>>> Like throwing an exception? >>>> Why not for an IllegalArgumentException >>>>> >>>>> Milos >>>>> >>>>>> >>>>>>> >>>>>>> That's why I also renamed some of the private member methods in the >>>>>>> validator implementation to make it more obvious what version is >>>>>>> applicable within the method.. >>>>>>> >>>>>>> Milos >>>>>>> >>>>>>> On Fri, Jun 29, 2012 at 12:31 PM, Olivier Lamy <[email protected]> wrote: >>>>>>>> Agree it's hard to inject that. So that reduce possible backward comp >>>>>>>> issues. >>>>>>>> >>>>>>>> BTW what about using this bean/data structure rather than adding new >>>>>>>> parameters ? >>>>>>>> >>>>>>>> 2012/6/29 Milos Kleint <[email protected]>: >>>>>>>>> Is ModelProblemCollector intended for use outside of maven codebase? >>>>>>>>> MavenModelBuilder is hardcoding reference on DefaultMPC and there's a >>>>>>>>> few other implementations in tests or compat module only.. >>>>>>>>> >>>>>>>>> Milos >>>>>>>>> >>>>>>>>> On Fri, Jun 29, 2012 at 11:49 AM, Olivier Lamy <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Hi, >>>>>>>>>> The main issue I see is non backward comp for tools implementing >>>>>>>>>> their >>>>>>>>>> own ModelProblemCollector. >>>>>>>>>> I don't have issue to change signature but for future enhancement if >>>>>>>>>> needed here, I would prefer to see something more easy to change and >>>>>>>>>> don't break again backward comp in the future. >>>>>>>>>> So instead more parameters >>>>>>>>>> >>>>>>>>>> - void add( ModelProblem.Severity severity, String message, >>>>>>>>>> InputLocation location, Exception cause ); >>>>>>>>>> >>>>>>>>>> + void add( ModelProblem.Severity severity, ModelProblem.Version >>>>>>>>>> version, String message, InputLocation location, Exception cause ); >>>>>>>>>> >>>>>>>>>> I would prefer we use a bean which contains the needed informations. >>>>>>>>>> something like: void add( ModelProblemCollector >>>>>>>>>> modelProblemCollectorRequest ); (or an other name :-) ). >>>>>>>>>> >>>>>>>>>> Makes sense ? >>>>>>>>>> >>>>>>>>>> 2012/6/29 Milos Kleint <[email protected]>: >>>>>>>>>>> hello, >>>>>>>>>>> >>>>>>>>>>> I've prepared a patch for MavenModelBuilder and related code that >>>>>>>>>>> hopefully will improve the performance of NetBeans >>>>>>>>>>> integration/embedding. The basic idea is to have all validation >>>>>>>>>>> problems collected but only fail to build the Mavenproject instance >>>>>>>>>>> when serious base problems are found (validation level minimal). >>>>>>>>>>> >>>>>>>>>>> See http://jira.codehaus.org/browse/MNG-5306 for details and links >>>>>>>>>>> to >>>>>>>>>>> patch. I haven't submitted to maven codebase for a while so I'd like >>>>>>>>>>> to have a review before integrating, Thanks. >>>>>>>>>>> >>>>>>>>>>> Milos Kleint >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>>>>>> For additional commands, e-mail: [email protected] >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Olivier Lamy >>>>>>>>>> Talend: http://coders.talend.com >>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> 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] >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Olivier Lamy >>>>>>>> Talend: http://coders.talend.com >>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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] >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olivier Lamy >>>>>> Talend: http://coders.talend.com >>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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] >>>>> >>>> >>>> >>>> >>>> -- >>>> Olivier Lamy >>>> Talend: http://coders.talend.com >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>> >>>> --------------------------------------------------------------------- >>>> 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] >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> 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] > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
