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]
