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..
>
> BTW nothing prevents to pass null here :-).
Like throwing an exception?
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
