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;
}
BTW nothing prevents to pass null here :-).
>
> 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
