maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: patch for review
Date Sun, 01 Jul 2012 22:19:24 GMT
2012/7/1 Milos Kleint <mkleint@gmail.com>:
> On Sun, Jul 1, 2012 at 9:30 AM, Olivier Lamy <olamy@apache.org> wrote:
>> 2012/6/29 Milos Kleint <mkleint@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 <olamy@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 <mkleint@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 <olamy@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 <mkleint@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Olivier Lamy
>>>>>> Talend: http://coders.talend.com
>>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Olivier Lamy
>>>> Talend: http://coders.talend.com
>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> Talend: http://coders.talend.com
>> http://twitter.com/olamy | http://linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message