2012/7/3 Milos Kleint <mkle...@gmail.com>: > 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 <ol...@apache.org> wrote: >> sounds good (at least for me :-) ). >> >> 2012/7/3 Milos Kleint <mkle...@gmail.com>: >>> done >>> https://github.com/mkleint/maven-3/commit/2ca8e13135e34f5df7cde0a86e37b533de3be676 >>> >>> Milos >>> >>> On Mon, Jul 2, 2012 at 12:19 AM, Olivier Lamy <ol...@apache.org> wrote: >>>> 2012/7/1 Milos Kleint <mkle...@gmail.com>: >>>>> On Sun, Jul 1, 2012 at 9:30 AM, Olivier Lamy <ol...@apache.org> wrote: >>>>>> 2012/6/29 Milos Kleint <mkle...@gmail.com>: >>>>>>> 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 <ol...@apache.org> 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 <mkle...@gmail.com>: >>>>>>>>> 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 <ol...@apache.org> >>>>>>>>> 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 <mkle...@gmail.com>: >>>>>>>>>>> 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: dev-unsubscr...@maven.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Olivier Lamy >>>>>>>>>> Talend: http://coders.talend.com >>>>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Olivier Lamy >>>>>>>> Talend: http://coders.talend.com >>>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Olivier Lamy >>>>>> Talend: http://coders.talend.com >>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Olivier Lamy >>>> Talend: http://coders.talend.com >>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
