Re: patch for review
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
Re: patch for review
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
Re: patch for review
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:
Re: patch for review
2012/7/3 Milos Kleint mkle...@gmail.com:
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?
As you prefer.
Perso I use: git svn dcommit.
Did you setup your local clone to use git svn ?
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:
Re: patch for review
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
Re: patch for review
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
Re: patch for review
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
--
Re: patch for review
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
Re: patch for review
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
Re: patch for review
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
Re: patch for review
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.. 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
