Re: Java 8 update status
I figured we could use the wiki page to eventually document for end users which versions need to be used to solve known problems etc. While we're still fixing them and we're still ea it's probably a good place for just sharing knowledge, since general stuff will tend to get hidden in jira. jMNG-5551 is good for keeping tabs on what's actually known :) Kristian 2013/12/19 Kristian Rosenvold kristian.rosenv...@zenior.no I just created https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to track the status of java 8 migration problems. This includes the bug number for the bugs.sun.com bug report I just filed yesterday that makes verifier break. Kristian
Re: Java 8 update status
On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: I figured we could use the wiki page to eventually document for end users which versions need to be used to solve known problems etc. While we're still fixing them and we're still ea it's probably a good place for just sharing knowledge, since general stuff will tend to get hidden in jira. jMNG-5551 is good for keeping tabs on what's actually known :) Just wondering about the comment Current ASM-5 beta not usable” - in what way is it not usable and has it been reported upstream? Kristian 2013/12/19 Kristian Rosenvold kristian.rosenv...@zenior.no I just created https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to track the status of java 8 migration problems. This includes the bug number for the bugs.sun.com bug report I just filed yesterday that makes verifier break. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java 8 update status
That's me being imprecise based on something I picked off google; i changed the wiki. It would appear to me that the ASM based plugins are in for a decent bit of work (at least shade seems to be). Some of them are using fairly old versions of asm too, and I considered porting shade to 4.2 to minimize diff up to 5.0. Do you know anything about the differences between asm 4.2 and 5.0 are significant in terms of api breakage ? Kristian 2013/12/19 Stuart McCulloch mccu...@gmail.com On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: I figured we could use the wiki page to eventually document for end users which versions need to be used to solve known problems etc. While we're still fixing them and we're still ea it's probably a good place for just sharing knowledge, since general stuff will tend to get hidden in jira. jMNG-5551 is good for keeping tabs on what's actually known :) Just wondering about the comment Current ASM-5 beta not usable” - in what way is it not usable and has it been reported upstream? Kristian 2013/12/19 Kristian Rosenvold kristian.rosenv...@zenior.no I just created https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to track the status of java 8 migration problems. This includes the bug number for the bugs.sun.com bug report I just filed yesterday that makes verifier break. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Java 8 update status
On 19 Dec 2013, at 09:50, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: That's me being imprecise based on something I picked off google; i changed the wiki. It would appear to me that the ASM based plugins are in for a decent bit of work (at least shade seems to be). Some of them are using fairly old versions of asm too, and I considered porting shade to 4.2 to minimize diff up to 5.0. Do you know anything about the differences between asm 4.2 and 5.0 are significant in terms of api breakage ? One of the key goals in ASM 4 was to improve backwards (binary) compatibility of releases going forwards: http://asm.ow2.org/history.html So far I’ve found ASM 5 beta to be a drop-in replacement for ASM 4 from a client perspective, so +1 on moving those plugins up to 4.2 to begin with. ( then people can always try out ASM 5 beta by adding it as a dependency to the plugin declaration in the pom.xml ) Kristian 2013/12/19 Stuart McCulloch mccu...@gmail.com On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: I figured we could use the wiki page to eventually document for end users which versions need to be used to solve known problems etc. While we're still fixing them and we're still ea it's probably a good place for just sharing knowledge, since general stuff will tend to get hidden in jira. jMNG-5551 is good for keeping tabs on what's actually known :) Just wondering about the comment Current ASM-5 beta not usable” - in what way is it not usable and has it been reported upstream? Kristian 2013/12/19 Kristian Rosenvold kristian.rosenv...@zenior.no I just created https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to track the status of java 8 migration problems. This includes the bug number for the bugs.sun.com bug report I just filed yesterday that makes verifier break. Kristian - 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: Java 8 update status
Btw, one of the ASM core committers is also an expert group member of the JSR335 (java8/lambdas). So I suppose that if ASM isn't able to support java8 bytecode yet, that should be fixable quite quickly. 2013/12/19 Stuart McCulloch mccu...@gmail.com On 19 Dec 2013, at 09:50, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: That's me being imprecise based on something I picked off google; i changed the wiki. It would appear to me that the ASM based plugins are in for a decent bit of work (at least shade seems to be). Some of them are using fairly old versions of asm too, and I considered porting shade to 4.2 to minimize diff up to 5.0. Do you know anything about the differences between asm 4.2 and 5.0 are significant in terms of api breakage ? One of the key goals in ASM 4 was to improve backwards (binary) compatibility of releases going forwards: http://asm.ow2.org/history.html So far I’ve found ASM 5 beta to be a drop-in replacement for ASM 4 from a client perspective, so +1 on moving those plugins up to 4.2 to begin with. ( then people can always try out ASM 5 beta by adding it as a dependency to the plugin declaration in the pom.xml ) Kristian 2013/12/19 Stuart McCulloch mccu...@gmail.com On 19 Dec 2013, at 08:08, Kristian Rosenvold kristian.rosenv...@zenior.no wrote: I figured we could use the wiki page to eventually document for end users which versions need to be used to solve known problems etc. While we're still fixing them and we're still ea it's probably a good place for just sharing knowledge, since general stuff will tend to get hidden in jira. jMNG-5551 is good for keeping tabs on what's actually known :) Just wondering about the comment Current ASM-5 beta not usable” - in what way is it not usable and has it been reported upstream? Kristian 2013/12/19 Kristian Rosenvold kristian.rosenv...@zenior.no I just created https://cwiki.apache.org/confluence/display/MAVEN/Java+8+Upgrade to track the status of java 8 migration problems. This includes the bug number for the bugs.sun.com bug report I just filed yesterday that makes verifier break. Kristian - 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 -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: New logo?
the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png On 18 December 2013 16:22, Paul Benedict pbened...@apache.org wrote: I think the logo should emphasis what the name maven means: someone who is an expert or connoisseur. Actually, I think the glasses on that animal brings out that imagery -- although I would like to see it emphasized more. The expertise could be also include blocks since modules/projects are the building blocks of maven. On Wed, Dec 18, 2013 at 10:17 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: For Benson... and just to put another one in the hat... http://people.apache.org/~stephenc/maven-logo-contest/maven-4.png http://people.apache.org/~stephenc/maven-logo-contest/maven-4-big.png On 18 December 2013 15:38, Jason van Zyl ja...@tesla.io wrote: On Dec 18, 2013, at 10:20 AM, Benson Margulies bimargul...@gmail.com wrote: Personally, I think we need a new POM version to drive us forward. I agree. If no one else gets to it I'll write up something over the holidays to distill what Stephen has written and try and formalize some minimal requirements and desires. As a visual goes, I'd look for something like a beaver (who builds things) wearing geek eye-glasses (indicating 'it's a maven'). For the love of god (if that happens to be your thing) please do not use a beaver. Go ask your closest English speaking North American why that's not a good choice. No one wants to see the maven-beaver-plugin. On Wed, Dec 18, 2013 at 10:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Tomcat... well they have a cat... fair enough Hadoop... has an elephant Hama has a hippo Solr has a sunrise Jackrabbit has a rabbit Chemistry has a test tube Openoffice has some abstract flying birds on a blue sky Karaf has a beaker with a feather on top ODE has a conductor with a feather instead of a batton Ant has the ant Flex has some strange abstract flexy thing Marmotta has a gopher Hive has an elephant-bee hybrid ... There is a limit to how many visually distinct animals you can render for a 75px tall image placeholder... But seriously, we just want something that is more than just our name in a fancy font. I think we need a mascot to help drive us onwards... -Stephen On 18 December 2013 13:27, Benson Margulies bimargul...@gmail.com wrote: A large, not very bright, species of deer that wears giant antlers and attacks what it doesn't understand. If that's what strikes you all as a great metaphor for us, Maven, or both, go right ahead. - 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - -- Cheers, Paul
Re: [1/2] git commit: MNG-5549 introduced MojoExecutionListener and ProjectExecutionListener
On 12/18/2013, 16:42, Olivier Lamy wrote:
if you need to add new parameters in the future, you won't have to add
this new MojoExecutionListener2 extends MojoExecutionListener (IMHO
it's just ugly but that's my POV) just add those new fields in
MojoExecutionEvent etc...
Anyway I only talk by experience and you are the guy who write the
code so do as you want.
This API can be here for a while so if it's easy to enhance it it's better.
BTW I just wonder why you don't want to use this pattern with a bean
rather than a method with a lot of parameters.
API clarity and consistency are the reasons I have slight preference to
explicitly pass parameters to callback methods.
MojoExecutionListener2 will still be required to introduce new callback
methods, and I like having single/consistent API evolution approach that
covers all scenarios.
When parameters are passed in explicitly, clients do not have to guess
what is available to them. It also makes it little easier to reason what
API version a client expects just by looking at implements
MojoExecutionListener vs MojoExecutionListener2.
At any rate, I don't think this matter much in this particular case, so
I'll introduce event objects in next couple of days.
--
Regards,
Igor
On 19 December 2013 07:32, Igor Fedorenko i...@ifedorenko.com wrote:
Olivier, Robert,
Do you insist on event objects or can live with my initial implementation?
I am not sure if I explained this clearly enough, but I never suggested
changing existing method signatures in the future. If we need to add
new parameters or new callback methods in the future, we can introduce
new listener interface
MojoExecutionListener2 extends MojoExecutionListener
and add new method to the new interface. Clients that implement
original MojoExecutionListener will continue to work as is.
--
Regards,
Igor
On 12/16/2013, 17:04, Robert Scholte wrote:
There are 2 issues here:
- What if one of the current methods require an extra Object/argument?
- What if we need an extra method.
The first one can be solved with the suggestion of Olivier. The method
signature will stay we same, we just extend the Event object passed.
For the latter you need to introduce a new interface of require Java8,
which will support default interface implementations.
Keeping a stable method signature if much more worth to me then the not
directly visible parameters of the event object.
If the current methods require different arguments, I would consider
different Events.
Robert
Op Mon, 16 Dec 2013 16:45:14 +0100 schreef Igor Fedorenko
i...@ifedorenko.com:
On 12/16/2013, 7:39, Olivier Lamy wrote:
On Dec 16, 2013 11:27 PM, Igor Fedorenko i...@ifedorenko.com wrote:
On 12/16/2013, 5:27, Olivier Lamy wrote:
+/**
+ * Extension point that allows build extensions observe and
possibly
veto mojo executions.
+ *
+ * @see WeakMojoExecutionListener
+ * @since 3.1.2
+ * @provisional This interface is part of work in progress and
can be
changed or removed without notice.
+ */
+public interface MojoExecutionListener
+{
+public void beforeMojoExecution( MavenSession session,
MavenProject project, MojoExecution execution, Mojo mojo )
+throws MojoExecutionException;
+
+public void afterMojoExecutionSuccess( MavenSession session,
MavenProject project, MojoExecution execution,
+ Mojo mojo )
+throws MojoExecutionException;
+
+public void afterExecutionFailure( MavenSession session,
MavenProject project, MojoExecution execution, Mojo mojo,
+ Throwable cause );
+}
I wonder if it will be easier for future enhancement to use a bean
with fields for those objects.
MojoExecutionListenerEvent with getMavenSession() etc...
Maybe will be simpler to add getter to this bean than changing the
signature of the interface.
?
Good idea. Any objections against MojoExecutionEvent and
ProjectExecutionEvent names?
Sounds good
So I tried this and I am not sure I like the result.
Event objects make it harder to see (at a glance) what parameters are
provided to the callbacks, especially because not all callbacks have the
same set of parameters. This muddies the API, I think.
Event objects make it possible to add new callback parameters but won't
help if we need to add new callbacks.
I think MojoExecutionListener2/3/4/etc provides reasonably good
evolution path for this API.
What do you think?
--
Regards,
Igor
-
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
-
To unsubscribe, e-mail:
Re: [1/2] git commit: MNG-5549 introduced MojoExecutionListener and ProjectExecutionListener
On 12/18/2013, 16:01, Robert Scholte wrote:
Just an example:
http://maven.apache.org/maven-release/maven-release-manager/apidocs/org/apache/maven/shared/release/ReleaseManager.html
I'm sure nobody suggested to change the method signatures in the
beginning, but at some moment one had to.
The result right now is a huge number of overloaded methods.
Using the Event object is just a way to ensure you won't end up with
something like this: an ultimate ugly API.
This is a different use case. Clients are not supposed to implement
ReleaseManager, so adding new methods to that interface is backwards
compatible change and is a reasonable way to evolve that API imho.
And, personally, I don't see anything ugly about deprecated overloaded
methods meant to provide backwards compatibility with older clients.
--
Regards,
Igor
Robert
Op Wed, 18 Dec 2013 21:32:11 +0100 schreef Igor Fedorenko
i...@ifedorenko.com:
Olivier, Robert,
Do you insist on event objects or can live with my initial
implementation?
I am not sure if I explained this clearly enough, but I never suggested
changing existing method signatures in the future. If we need to add
new parameters or new callback methods in the future, we can introduce
new listener interface
MojoExecutionListener2 extends MojoExecutionListener
and add new method to the new interface. Clients that implement
original MojoExecutionListener will continue to work as is.
--
Regards,
Igor
On 12/16/2013, 17:04, Robert Scholte wrote:
There are 2 issues here:
- What if one of the current methods require an extra Object/argument?
- What if we need an extra method.
The first one can be solved with the suggestion of Olivier. The method
signature will stay we same, we just extend the Event object passed.
For the latter you need to introduce a new interface of require Java8,
which will support default interface implementations.
Keeping a stable method signature if much more worth to me then the not
directly visible parameters of the event object.
If the current methods require different arguments, I would consider
different Events.
Robert
Op Mon, 16 Dec 2013 16:45:14 +0100 schreef Igor Fedorenko
i...@ifedorenko.com:
On 12/16/2013, 7:39, Olivier Lamy wrote:
On Dec 16, 2013 11:27 PM, Igor Fedorenko i...@ifedorenko.com
wrote:
On 12/16/2013, 5:27, Olivier Lamy wrote:
+/**
+ * Extension point that allows build extensions observe and
possibly
veto mojo executions.
+ *
+ * @see WeakMojoExecutionListener
+ * @since 3.1.2
+ * @provisional This interface is part of work in progress and
can be
changed or removed without notice.
+ */
+public interface MojoExecutionListener
+{
+public void beforeMojoExecution( MavenSession session,
MavenProject project, MojoExecution execution, Mojo mojo )
+throws MojoExecutionException;
+
+public void afterMojoExecutionSuccess( MavenSession session,
MavenProject project, MojoExecution execution,
+ Mojo mojo )
+throws MojoExecutionException;
+
+public void afterExecutionFailure( MavenSession session,
MavenProject project, MojoExecution execution, Mojo mojo,
+ Throwable cause );
+}
I wonder if it will be easier for future enhancement to use a bean
with fields for those objects.
MojoExecutionListenerEvent with getMavenSession() etc...
Maybe will be simpler to add getter to this bean than changing the
signature of the interface.
?
Good idea. Any objections against MojoExecutionEvent and
ProjectExecutionEvent names?
Sounds good
So I tried this and I am not sure I like the result.
Event objects make it harder to see (at a glance) what parameters are
provided to the callbacks, especially because not all callbacks have
the
same set of parameters. This muddies the API, I think.
Event objects make it possible to add new callback parameters but won't
help if we need to add new callbacks.
I think MojoExecutionListener2/3/4/etc provides reasonably good
evolution path for this API.
What do you think?
--
Regards,
Igor
-
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
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands,
Re: New logo?
It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven SCM 1.9 (take 2)
Thanks Oliver, its a bit disappointing, as this at the end (at least for me) also means the other scm components are not maintainable anymore… Taking this into account, then its probably a better idea to not have this under the apache umbrella anyway. Where do you think we should release it from? Or should I just make a release with my own gav and publish it via Sonatype? regards Domi On 16.12.2013, at 00:15, Olivier Lamy ol...@apache.org wrote: So that's 2 weeks now. I presume I can say the vote failed. I will delete the tag and the staging repo. If someone else want to act RM let's go. perso I'm tired @Domi I'm sorry I believed if was a good idea to have the module jgit here (but cvs looks to me more important :P ). Anyway we can release that separately somewhere else. Cheers, Olivier On 5 December 2013 04:24, Dominik Bartholdi d...@fortysix.ch wrote: OK, then you have my +1 /Domi On 03.12.2013, at 08:20, Olivier Lamy ol...@apache.org wrote: No worries. IMHO it's not the problem. Issue is cvs-commons module. -- Olivier On Dec 3, 2013 3:34 PM, Dominik Bartholdi d...@fortysix.ch wrote: Sorry guys, during the week I’m usually a bit short in time… But is ist possible, that my commit d1f102e5223e5fe0f852e1a5becb497f0e860d6a is actually causing this issue? Its an exclude of some CVS stuff I had in my untracked list all the time when doing a full build... regards Domi On 03.12.2013, at 02:57, Olivier Lamy ol...@apache.org wrote: On 3 December 2013 12:52, Bernd Eckenfels e...@zusammenkunft.net wrote: Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy ol...@apache.org: For some reasons I don't understand yet why defaultExclude=false doesn't work for CVS directories. Uh, isnt that supposed to be yes to enable the exclusion of default patterns? no because in this case we want some cvs directories included in the assembly. That's why we need to use defaultExclude=false to prevent some default pattern exclusion (or I really understand nothing :-)) Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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: New logo?
What a splendid idea! This is by far my favourite. Trailed by the Moose maybe. We could use a symbolized interpretation of a Raven along the lines of https://www.google.ca/search?q=raven+pacific+northwest+artespv=210es_sm=119tbm=ischtbo=usource=univsa=Xei=ATezUofzI4jyoASBnIAoved=0CC4QsAQbiw=1229bih=1083 Manfred It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - 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: New logo?
I like the Raven idea -- especially if you can color the bird with the Apache feathers look. On Thu, Dec 19, 2013 at 12:13 PM, Manfred Moser manf...@simpligility.comwrote: What a splendid idea! This is by far my favourite. Trailed by the Moose maybe. We could use a symbolized interpretation of a Raven along the lines of https://www.google.ca/search?q=raven+pacific+northwest+artespv=210es_sm=119tbm=ischtbo=usource=univsa=Xei=ATezUofzI4jyoASBnIAoved=0CC4QsAQbiw=1229bih=1083 Manfred It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - 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 -- Cheers, Paul
Re: [VOTE] Apache Maven SCM 1.9 (take 2)
Stephens remarks are valid, let me try to pick this up in the next couple of weeks. Robert Op Thu, 19 Dec 2013 18:31:13 +0100 schreef Dominik Bartholdi d...@fortysix.ch: Thanks Oliver, its a bit disappointing, as this at the end (at least for me) also means the other scm components are not maintainable anymore… Taking this into account, then its probably a better idea to not have this under the apache umbrella anyway. Where do you think we should release it from? Or should I just make a release with my own gav and publish it via Sonatype? regards Domi On 16.12.2013, at 00:15, Olivier Lamy ol...@apache.org wrote: So that's 2 weeks now. I presume I can say the vote failed. I will delete the tag and the staging repo. If someone else want to act RM let's go. perso I'm tired @Domi I'm sorry I believed if was a good idea to have the module jgit here (but cvs looks to me more important :P ). Anyway we can release that separately somewhere else. Cheers, Olivier On 5 December 2013 04:24, Dominik Bartholdi d...@fortysix.ch wrote: OK, then you have my +1 /Domi On 03.12.2013, at 08:20, Olivier Lamy ol...@apache.org wrote: No worries. IMHO it's not the problem. Issue is cvs-commons module. -- Olivier On Dec 3, 2013 3:34 PM, Dominik Bartholdi d...@fortysix.ch wrote: Sorry guys, during the week I’m usually a bit short in time… But is ist possible, that my commit d1f102e5223e5fe0f852e1a5becb497f0e860d6a is actually causing this issue? Its an exclude of some CVS stuff I had in my untracked list all the time when doing a full build... regards Domi On 03.12.2013, at 02:57, Olivier Lamy ol...@apache.org wrote: On 3 December 2013 12:52, Bernd Eckenfels e...@zusammenkunft.net wrote: Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy ol...@apache.org: For some reasons I don't understand yet why defaultExclude=false doesn't work for CVS directories. Uh, isnt that supposed to be yes to enable the exclusion of default patterns? no because in this case we want some cvs directories included in the assembly. That's why we need to use defaultExclude=false to prevent some default pattern exclusion (or I really understand nothing :-)) Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven SCM 1.9 (take 2)
I think all the crap/trolling in the release threads has gone way too far, it's just not fun any more. I can only request that PMC members chip in *before* the the vote to /improve/ technical problems with a release rather than spending a ton of energy documenting their -1 *after* the release is staged. Kristian 2013/12/19 Robert Scholte rfscho...@apache.org Stephens remarks are valid, let me try to pick this up in the next couple of weeks. Robert Op Thu, 19 Dec 2013 18:31:13 +0100 schreef Dominik Bartholdi d...@fortysix.ch: Thanks Oliver, its a bit disappointing, as this at the end (at least for me) also means the other scm components are not maintainable anymore… Taking this into account, then its probably a better idea to not have this under the apache umbrella anyway. Where do you think we should release it from? Or should I just make a release with my own gav and publish it via Sonatype? regards Domi On 16.12.2013, at 00:15, Olivier Lamy ol...@apache.org wrote: So that's 2 weeks now. I presume I can say the vote failed. I will delete the tag and the staging repo. If someone else want to act RM let's go. perso I'm tired @Domi I'm sorry I believed if was a good idea to have the module jgit here (but cvs looks to me more important :P ). Anyway we can release that separately somewhere else. Cheers, Olivier On 5 December 2013 04:24, Dominik Bartholdi d...@fortysix.ch wrote: OK, then you have my +1 /Domi On 03.12.2013, at 08:20, Olivier Lamy ol...@apache.org wrote: No worries. IMHO it's not the problem. Issue is cvs-commons module. -- Olivier On Dec 3, 2013 3:34 PM, Dominik Bartholdi d...@fortysix.ch wrote: Sorry guys, during the week I’m usually a bit short in time… But is ist possible, that my commit d1f102e5223e5fe0f852e1a5becb497f0e860d6a is actually causing this issue? Its an exclude of some CVS stuff I had in my untracked list all the time when doing a full build... regards Domi On 03.12.2013, at 02:57, Olivier Lamy ol...@apache.org wrote: On 3 December 2013 12:52, Bernd Eckenfels e...@zusammenkunft.net wrote: Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy ol...@apache.org: For some reasons I don't understand yet why defaultExclude=false doesn't work for CVS directories. Uh, isnt that supposed to be yes to enable the exclusion of default patterns? no because in this case we want some cvs directories included in the assembly. That's why we need to use defaultExclude=false to prevent some default pattern exclusion (or I really understand nothing :-)) Gruss Bernd - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New logo?
Likely that would be overly complex at small resolutions, but a monochrome all black stencil version might work for small versions with the full colour at 200px+ On Thursday, 19 December 2013, Paul Benedict wrote: I like the Raven idea -- especially if you can color the bird with the Apache feathers look. On Thu, Dec 19, 2013 at 12:13 PM, Manfred Moser manf...@simpligility.comjavascript:; wrote: What a splendid idea! This is by far my favourite. Trailed by the Moose maybe. We could use a symbolized interpretation of a Raven along the lines of https://www.google.ca/search?q=raven+pacific+northwest+artespv=210es_sm=119tbm=ischtbo=usource=univsa=Xei=ATezUofzI4jyoASBnIAoved=0CC4QsAQbiw=1229bih=1083 Manfred It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- Cheers, Paul -- Sent from my phone
Re: New logo?
Thats what I had in mind. Just a stylized version that is simplified and with not too many details. Even maybe just a head or upper body of the Maven Raven ... I just had to write that.. I like it ;-) manfred Likely that would be overly complex at small resolutions, but a monochrome all black stencil version might work for small versions with the full colour at 200px+ On Thursday, 19 December 2013, Paul Benedict wrote: I like the Raven idea -- especially if you can color the bird with the Apache feathers look. On Thu, Dec 19, 2013 at 12:13 PM, Manfred Moser manf...@simpligility.comjavascript:; wrote: What a splendid idea! This is by far my favourite. Trailed by the Moose maybe. We could use a symbolized interpretation of a Raven along the lines of https://www.google.ca/search?q=raven+pacific+northwest+artespv=210es_sm=119tbm=ischtbo=usource=univsa=Xei=ATezUofzI4jyoASBnIAoved=0CC4QsAQbiw=1229bih=1083 Manfred It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- Cheers, Paul -- Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: New logo?
http://people.apache.org/~stephenc/maven-logo-contest/maven-6.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7a.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7b.png All based on this: http://people.apache.org/~stephenc/maven-logo-contest/maven-7b-big.pngwhich I traced from one of the raven totems The -7 set all echo the gradient used in the Apache feather, though I think the solid colour might have more strength. I'll see if I can find another one to try tracing On 19 December 2013 20:35, Manfred Moser manf...@simpligility.com wrote: Thats what I had in mind. Just a stylized version that is simplified and with not too many details. Even maybe just a head or upper body of the Maven Raven ... I just had to write that.. I like it ;-) manfred Likely that would be overly complex at small resolutions, but a monochrome all black stencil version might work for small versions with the full colour at 200px+ On Thursday, 19 December 2013, Paul Benedict wrote: I like the Raven idea -- especially if you can color the bird with the Apache feathers look. On Thu, Dec 19, 2013 at 12:13 PM, Manfred Moser manf...@simpligility.comjavascript:; wrote: What a splendid idea! This is by far my favourite. Trailed by the Moose maybe. We could use a symbolized interpretation of a Raven along the lines of https://www.google.ca/search?q=raven+pacific+northwest+artespv=210es_sm=119tbm=ischtbo=usource=univsa=Xei=ATezUofzI4jyoASBnIAoved=0CC4QsAQbiw=1229bih=1083 Manfred It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- Cheers, Paul -- Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven SCM 1.9 (take 2)
On Thursday, 19 December 2013, Kristian Rosenvold wrote: I think all the crap/trolling in the release threads has gone way too far, it's just not fun any more. I can only request that PMC members chip in *before* the the vote to /improve/ technical problems with a release rather than spending a ton of energy documenting their -1 *after* the release is staged. I did my testing, I found an issue which, in good conscience I feel means I cannot vote +1. I stated my vote was not a veto and I would not stand in the way of a release. This only needed one more +1 from a PMC member... I don't see that as trolling... Where was your vote? Kristian 2013/12/19 Robert Scholte rfscho...@apache.org Stephens remarks are valid, let me try to pick this up in the next couple of weeks. Robert Op Thu, 19 Dec 2013 18:31:13 +0100 schreef Dominik Bartholdi d...@fortysix.ch: Thanks Oliver, its a bit disappointing, as this at the end (at least for me) also means the other scm components are not maintainable anymore… Taking this into account, then its probably a better idea to not have this under the apache umbrella anyway. Where do you think we should release it from? Or should I just make a release with my own gav and publish it via Sonatype? regards Domi On 16.12.2013, at 00:15, Olivier Lamy ol...@apache.org wrote: So that's 2 weeks now. I presume I can say the vote failed. I will delete the tag and the staging repo. If someone else want to act RM let's go. perso I'm tired @Domi I'm sorry I believed if was a good idea to have the module jgit here (but cvs looks to me more important :P ). Anyway we can release that separately somewhere else. Cheers, Olivier On 5 December 2013 04:24, Dominik Bartholdi d...@fortysix.ch wrote: OK, then you have my +1 /Domi On 03.12.2013, at 08:20, Olivier Lamy ol...@apache.org wrote: No worries. IMHO it's not the problem. Issue is cvs-commons module. -- Olivier On Dec 3, 2013 3:34 PM, Dominik Bartholdi d...@fortysix.ch wrote: Sorry guys, during the week I’m usually a bit short in time… But is ist possible, that my commit d1f102e5223e5fe0f852e1a5becb497f0e860d6a is actually causing this issue? Its an exclude of some CVS stuff I had in my untracked list all the time when doing a full build... regards Domi On 03.12.2013, at 02:57, Olivier Lamy ol...@apache.org wrote: On 3 December 2013 12:52, Bernd Eckenfels e...@zusammenkunft.net wrote: Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy ol...@apache.org: For some reasons I don't understand yet why defaultExclude=false doesn't work for CVS directories. Uh, isnt that supposed to be yes to enable the exclusion of default patterns? no because in this case we want some cvs directories included in the assembly. That's why we need to use defaultExclude=false to prevent some default pattern exclusion (or I really understand nothing :-)) -- Sent from my phone
RE: New logo?
Apache? Totems? When my ancestors arrived at Ellis they were reminded ..there are native-americans http://indianspictures.blogspot.com/2012/01/american-native-american-photos-of.html Worth a gander? Martin __ Date: Thu, 19 Dec 2013 23:44:00 + Subject: Re: New logo? From: stephen.alan.conno...@gmail.com To: dev@maven.apache.org; manf...@simpligility.com http://people.apache.org/~stephenc/maven-logo-contest/maven-6.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7a.png http://people.apache.org/~stephenc/maven-logo-contest/maven-7b.png All based on this: http://people.apache.org/~stephenc/maven-logo-contest/maven-7b-big.pngwhich I traced from one of the raven totems The -7 set all echo the gradient used in the Apache feather, though I think the solid colour might have more strength. I'll see if I can find another one to try tracing On 19 December 2013 20:35, Manfred Moser manf...@simpligility.com wrote: Thats what I had in mind. Just a stylized version that is simplified and with not too many details. Even maybe just a head or upper body of the Maven Raven ... I just had to write that.. I like it ;-) manfred Likely that would be overly complex at small resolutions, but a monochrome all black stencil version might work for small versions with the full colour at 200px+ On Thursday, 19 December 2013, Paul Benedict wrote: I like the Raven idea -- especially if you can color the bird with the Apache feathers look. On Thu, Dec 19, 2013 at 12:13 PM, Manfred Moser manf...@simpligility.comjavascript:; wrote: What a splendid idea! This is by far my favourite. Trailed by the Moose maybe. We could use a symbolized interpretation of a Raven along the lines of https://www.google.ca/search?q=raven+pacific+northwest+artespv=210es_sm=119tbm=ischtbo=usource=univsa=Xei=ATezUofzI4jyoASBnIAoved=0CC4QsAQbiw=1229bih=1083 Manfred It seems that a Raven would be better. It even rhymes with Maven, in English. They have a lot of significance to many different cultures, with themes ranging from wisdom, to good luck, to even blood thirsty birds of battle preferred by warriors. And given this cultural history, there exists a large corpus of artistic material to inspire or choose. https://www.google.com/search?tbm=ischq=raven http://en.wikipedia.org/wiki/Cultural_depictions_of_ravens On Thu, Dec 19, 2013 at 5:36 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: the wise owl? http://people.apache.org/~stephenc/maven-logo-contest/maven-5.png - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.orgjavascript:; -- Cheers, Paul -- Sent from my phone - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Maven Shared Utils 0.5 and Maven JarSigner 1.2 (take 2)
+1 Regards, Hervé Le mercredi 18 décembre 2013 02:00:18 Tony Chemit a écrit : Hi, maven-jarsigner site is now ok :) Maven shared Utils 0.5 -- The version 0.5 offers a new simple API to execute java tool via commandline builder. This API offers also toolchain support (which makes sense while executing java tools from jdk). This api is now used in maven jarsigner shared component and keytool-api (from keytool-maven-plugin @codehaus). We solved 1 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=19 180 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761sta tus=1component=15606 Staging repo: https://repository.apache.org/content/repositories/maven-064/ https://repository.apache.org/content/repositories/maven-064/org/apache/mave n/shared/maven-shared-utils/0.5/maven-shared-utils-0.5-source-release.zip Source release checksum(s): maven-shared-utils-0.5-source-release.zip sha1: 00aec332db87f6549a31395eded80159efc88de3 Staging site: http://maven.apache.org/shared-archives/maven-shared-utils-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 my +1 Maven shared JarSigner 1.2 -- The version 1.2 uses the new maven-shared-utils JavaTool API, java 5 and plexus java 5 annotations, and much much more... We solved 5 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761version=19 721 There is no more issues in JIRA left :) Staging repo: https://repository.apache.org/content/repositories/maven-064/ https://repository.apache.org/content/repositories/maven-064/org/apache/mave n/shared/maven-jarsigner/1.2/maven-jarsigner-1.2-source-release.zip Source release checksum(s): maven-jarsigner-1.2-source-release.zip sha1: 573fa9d50cc08bd65a2bf0d077e6c1b08d70046b Staging site: http://maven.apache.org/shared-archives/maven-jarsigner-LATEST/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 my +1 tony. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [1/2] git commit: MNG-5549 introduced MojoExecutionListener and ProjectExecutionListener
IIUC, numbered interfaces + abstract implementations are roughly Eclipse way
of solving this requirement about API evolution, isn't it?
Regards,
Hervé
Le jeudi 19 décembre 2013 07:43:03 Igor Fedorenko a écrit :
On 12/18/2013, 16:42, Olivier Lamy wrote:
if you need to add new parameters in the future, you won't have to add
this new MojoExecutionListener2 extends MojoExecutionListener (IMHO
it's just ugly but that's my POV) just add those new fields in
MojoExecutionEvent etc...
Anyway I only talk by experience and you are the guy who write the
code so do as you want.
This API can be here for a while so if it's easy to enhance it it's
better.
BTW I just wonder why you don't want to use this pattern with a bean
rather than a method with a lot of parameters.
API clarity and consistency are the reasons I have slight preference to
explicitly pass parameters to callback methods.
MojoExecutionListener2 will still be required to introduce new callback
methods, and I like having single/consistent API evolution approach that
covers all scenarios.
When parameters are passed in explicitly, clients do not have to guess
what is available to them. It also makes it little easier to reason what
API version a client expects just by looking at implements
MojoExecutionListener vs MojoExecutionListener2.
At any rate, I don't think this matter much in this particular case, so
I'll introduce event objects in next couple of days.
--
Regards,
Igor
On 19 December 2013 07:32, Igor Fedorenko i...@ifedorenko.com wrote:
Olivier, Robert,
Do you insist on event objects or can live with my initial
implementation?
I am not sure if I explained this clearly enough, but I never suggested
changing existing method signatures in the future. If we need to add
new parameters or new callback methods in the future, we can introduce
new listener interface
MojoExecutionListener2 extends MojoExecutionListener
and add new method to the new interface. Clients that implement
original MojoExecutionListener will continue to work as is.
--
Regards,
Igor
On 12/16/2013, 17:04, Robert Scholte wrote:
There are 2 issues here:
- What if one of the current methods require an extra Object/argument?
- What if we need an extra method.
The first one can be solved with the suggestion of Olivier. The method
signature will stay we same, we just extend the Event object passed.
For the latter you need to introduce a new interface of require Java8,
which will support default interface implementations.
Keeping a stable method signature if much more worth to me then the not
directly visible parameters of the event object.
If the current methods require different arguments, I would consider
different Events.
Robert
Op Mon, 16 Dec 2013 16:45:14 +0100 schreef Igor Fedorenko
i...@ifedorenko.com:
On 12/16/2013, 7:39, Olivier Lamy wrote:
On Dec 16, 2013 11:27 PM, Igor Fedorenko i...@ifedorenko.com
wrote:
On 12/16/2013, 5:27, Olivier Lamy wrote:
+/**
+ * Extension point that allows build extensions observe and
possibly
veto mojo executions.
+ *
+ * @see WeakMojoExecutionListener
+ * @since 3.1.2
+ * @provisional This interface is part of work in progress and
can be
changed or removed without notice.
+ */
+public interface MojoExecutionListener
+{
+public void beforeMojoExecution( MavenSession session,
MavenProject project, MojoExecution execution, Mojo mojo )
+throws MojoExecutionException;
+
+public void afterMojoExecutionSuccess( MavenSession session,
MavenProject project, MojoExecution execution,
+ Mojo mojo )
+throws MojoExecutionException;
+
+public void afterExecutionFailure( MavenSession session,
MavenProject project, MojoExecution execution, Mojo mojo,
+ Throwable cause );
+}
I wonder if it will be easier for future enhancement to use a bean
with fields for those objects.
MojoExecutionListenerEvent with getMavenSession() etc...
Maybe will be simpler to add getter to this bean than changing the
signature of the interface.
?
Good idea. Any objections against MojoExecutionEvent and
ProjectExecutionEvent names?
Sounds good
So I tried this and I am not sure I like the result.
Event objects make it harder to see (at a glance) what parameters are
provided to the callbacks, especially because not all callbacks have
the
same set of parameters. This muddies the API, I think.
Event objects make it possible to add new callback parameters but won't
help if we need to add new callbacks.
I think MojoExecutionListener2/3/4/etc provides reasonably good
evolution path for this API.
What do you think?
--
Regards,
Igor
Re: [VOTE] Apache Maven SCM 1.9 (take 2)
I usually ignore threads when they degenerate into procedural discussions and I'll guarantee supress any voting thread where the first thing that comes out is a -1; I've got coding to do. Sorry for being an idiot, I'm usually quite good at keeping my foot out of my mouth. Can't always get it right. Kristian 2013/12/20 Stephen Connolly stephen.alan.conno...@gmail.com On Thursday, 19 December 2013, Kristian Rosenvold wrote: I think all the crap/trolling in the release threads has gone way too far, it's just not fun any more. I can only request that PMC members chip in *before* the the vote to /improve/ technical problems with a release rather than spending a ton of energy documenting their -1 *after* the release is staged. I did my testing, I found an issue which, in good conscience I feel means I cannot vote +1. I stated my vote was not a veto and I would not stand in the way of a release. This only needed one more +1 from a PMC member... I don't see that as trolling... Where was your vote? Kristian 2013/12/19 Robert Scholte rfscho...@apache.org Stephens remarks are valid, let me try to pick this up in the next couple of weeks. Robert Op Thu, 19 Dec 2013 18:31:13 +0100 schreef Dominik Bartholdi d...@fortysix.ch: Thanks Oliver, its a bit disappointing, as this at the end (at least for me) also means the other scm components are not maintainable anymore… Taking this into account, then its probably a better idea to not have this under the apache umbrella anyway. Where do you think we should release it from? Or should I just make a release with my own gav and publish it via Sonatype? regards Domi On 16.12.2013, at 00:15, Olivier Lamy ol...@apache.org wrote: So that's 2 weeks now. I presume I can say the vote failed. I will delete the tag and the staging repo. If someone else want to act RM let's go. perso I'm tired @Domi I'm sorry I believed if was a good idea to have the module jgit here (but cvs looks to me more important :P ). Anyway we can release that separately somewhere else. Cheers, Olivier On 5 December 2013 04:24, Dominik Bartholdi d...@fortysix.ch wrote: OK, then you have my +1 /Domi On 03.12.2013, at 08:20, Olivier Lamy ol...@apache.org wrote: No worries. IMHO it's not the problem. Issue is cvs-commons module. -- Olivier On Dec 3, 2013 3:34 PM, Dominik Bartholdi d...@fortysix.ch wrote: Sorry guys, during the week I’m usually a bit short in time… But is ist possible, that my commit d1f102e5223e5fe0f852e1a5becb497f0e860d6a is actually causing this issue? Its an exclude of some CVS stuff I had in my untracked list all the time when doing a full build... regards Domi On 03.12.2013, at 02:57, Olivier Lamy ol...@apache.org wrote: On 3 December 2013 12:52, Bernd Eckenfels e...@zusammenkunft.net wrote: Am 03.12.2013, 02:47 Uhr, schrieb Olivier Lamy ol...@apache.org : For some reasons I don't understand yet why defaultExclude=false doesn't work for CVS directories. Uh, isnt that supposed to be yes to enable the exclusion of default patterns? no because in this case we want some cvs directories included in the assembly. That's why we need to use defaultExclude=false to prevent some default pattern exclusion (or I really understand nothing :-)) -- Sent from my phone
