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?
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
