Re: New logo?
I'm a bit late to catch up with this, but had a few things to note as I read through the thread - sorry to top-top-reply. I agree we should definitely consider a logo competition to augment this set of contributions. We should be cautious about using images from Native American culture - there are some good guidelines in previous contests: http://wiki.apache.org/solr/LogoContest Please consider a logo that either looks good in a square graphic, or has a reasonable variant that can! Think what you'd want to see in a favicon, or github/twitter/facebook/gravatar for the project. I know in the past the m has been used, but never felt like it was a very strong association. And I'm glad to see the back of the guy from the stock photo on the website (pun intended). - Brett On 17 Dec 2013, at 9:35 am, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have been playing with reworking our front page... I think the fluido skin is a big improvement, I would like to switch to that... Only problem I see is that our current logo(s) are very tied to the old look and feel... So do we want to see about launching a logo competition. TomEE had good success with theirs. Also I'm looking at going with the top-menu version of fluido skin rather than the left menu... I have a solution to the hidden nature... but you'll just have to wait until I sync up with Hervé to find a way to get it pushed to staging from a branch without blowing up the production site to see my trickery! -Stephen
Re: Adding a classpath element within a Mojo
No, no tricks, as far as I know Plexus (and now Sisu/Guice) only inject fully configured components. so the behaviour you describe is rather odd. What version of Maven do you use? Is it official distribution from Apache or something you built locally? Not likely related, but I haven't used javadoc plexus annotations in ages. Any particular reason you don't want to use java 5 @Component? In any case, if you can provide small standalone example that shows the problem, I can try to see what's going on there. -- Regards, Igor On 1/23/2014, 0:54, William Ferguson wrote: Igor, I'm having some difficulty getting the LifecycleParticipant to resolve Maven components. In particular, the org.apache.maven.project.ProjectDependenciesResolver. While it gets resolved, none of it's internal attributes get resolved. So calls to projectDependenciesResolver.resolve crash with NPEs because DefaultProjectDependenciesResolver#logger or #repoSystem is not initialised. /** * @component * @readonly * @required */ protected ProjectDependenciesResolver projectDependenciesResolver; Is there some special trick to getting components fully initialised in a LifecycleParticipant? William On Tue, Jan 21, 2014 at 12:21 AM, Igor Fedorenko i...@ifedorenko.comwrote: Here is Tycho lifecycle participant [1] and here is the code that injects new dependencies in MavenProject instances [2]. [1] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/ TychoMavenLifecycleParticipant.java?h=tycho-0.19.x [2] http://git.eclipse.org/c/tycho/org.eclipse.tycho.git/ tree/tycho-core/src/main/java/org/eclipse/tycho/core/maven/ MavenDependencyInjector.java?h=tycho-0.19.x -- Regards, Igor On 1/20/2014, 8:21, William Ferguson wrote: Thanks Igor, could you give me a link to an example or some code that - Utilises AbstractMavenLifecycleParticipant#afterProjectsRead - How to manipulate the project dependencies from there. I found an example example by Brett Porter, but the doco is pretty thin and I can't see how I would go about inject extra elements into the classpath from there. William On Mon, Jan 20, 2014 at 10:47 PM, Igor Fedorenko i...@ifedorenko.com wrote: There is probably more ways to do this, but you can implement AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate project dependencies. This is what we do in Tycho, where we resolve project OSGi dependencies in AbstractMavenLifecycleParticipant and then inject that into Maven project model as system scoped maven dependencies. I also think your usecase highlights general deficiency with current dependency model. Since you have to add classpath elements dynamically, these elements are not visible to maven-based tools like m2e without additional effort on the tools part. I think it will be useful to extend dependency element syntax to allow references for nested archive entries, i.e. dependency on classes jar nested within this AAR archive. -- Regards, Igor On 1/20/2014, 7:00, William Ferguson wrote: Hi, I realise this question isn't exactly related to dev within the Maven components, but it is about developing a Mojo using components that have to be pretty central and don't appear to be obviously documented anywhere. And I ahve asked on maven-users without much luck. As part of the android-maven-plugin we have a Mojo which needs to add an element to the compile time classpath for future Mojos (specifically the maven-compiler-plugin). Project has dependencies on artifacts of type AAR (Android archive - an archive that contains several sub-artifacts including a classes jar). Our Mojo unpacks the AAR artifacts and makes the sub-artifacts available to other build components. One of those build components is the maven-compiler-plugin. We want to add the classes contained in the AAR dependencies to the compile classpath so that the maven-compiler-plugin can compile our classes against the classes from the AARs. How do we do that? William - 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: Maven 4.0.0
Here @ SAP, EventSpies are used as well. So they are not useless, but I would welcome a review of the convoluted and incomplete listener interfaces . Christophe -Original Message- From: Milos Kleint [mailto:mkle...@gmail.com] Sent: Donnerstag, 23. Januar 2014 08:19 To: Maven Developers List Subject: Re: Maven 4.0.0 EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 4.0.0
You either end up with a custom distribution and/or using system properties. Aside from the eventing mechanism being too convoluted, something where an extension can be specified in the POM and downloaded if required would be more consistent. The custom distribution route or having to invoke Maven using a system property IMO always ends up being more difficult than necessary. Additionally we have 4-5 different entities for eventing, I would just like one consistent one given everything we know now. On Jan 23, 2014, at 2:18 AM, Milos Kleint mkle...@gmail.com wrote: EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - 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 http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith
Re: Maven 4.0.0
On Thu, Jan 23, 2014 at 3:27 PM, Jason van Zyl ja...@takari.io wrote: You either end up with a custom distribution and/or using system properties. Aside from the eventing mechanism being too convoluted, something where an extension can be specified in the POM and downloaded if required would be more consistent. The custom distribution route or having to invoke Maven using a system property IMO always ends up being more difficult than necessary. Additionally we have 4-5 different entities for eventing, I would just like one consistent one given everything we know now. I'm not sure I follow, it's too abstract for me given that I'm not following the maven development closely. Here's the code for my event spy, it's something I can inject in any (even custom user distros) 3.0.x maven and get features in the IDE. http://hg.netbeans.org/core-main/file/93439856c344/maven/mavensrc/org/netbeans/modules/maven/event/NbEventSpy.java it basically collects the info I'm interested in on the IDE JVM side and prints it out in form of json. the IDE then parses the json content and populates the IDE data structures (like collapsing sections for the build, detailed info about what was executed, helpers for debugging maven plugin executions etc) I'm also injecting WorkspaceReader in the same way.. Milos On Jan 23, 2014, at 2:18 AM, Milos Kleint mkle...@gmail.com wrote: EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - 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 http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 4.0.0
I think there are two separate concerns/usecases here. Tools like m2e, netbeans or hudson need a way to push core components without changing maven distribution or project pom.xml files. I think system properties is the most straightforward way to do this. Existing event listener mechanisms are convoluted and inconsistent. I have to agree with this one, but I think we can offer clean(er) event listener interface(s) which will work the same way regardless how clients choose to contribute them to the system, via build extension, system property or custom distribution. -- Regards, Igor On 1/23/2014, 9:27, Jason van Zyl wrote: You either end up with a custom distribution and/or using system properties. Aside from the eventing mechanism being too convoluted, something where an extension can be specified in the POM and downloaded if required would be more consistent. The custom distribution route or having to invoke Maven using a system property IMO always ends up being more difficult than necessary. Additionally we have 4-5 different entities for eventing, I would just like one consistent one given everything we know now. On Jan 23, 2014, at 2:18 AM, Milos Kleint mkle...@gmail.com wrote: EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - 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 http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: Maven 4.0.0
FYI, the use-case for EventSpies @ SAP is exactly the one described by Igor : we use an event spy to instrument our Hudson/Jenkins instance to monitor the builds. This instrumentation MUST NOT require any pom.xml modification, so any maven project thrown into the Hudson/Jenkins can be monitored, nor any customization of the maven distribution (other than dropping files in lib/ext or setting maven.ext.class.path), so that maven is easy to upgrade. Regards Christophe -Original Message- From: Igor Fedorenko [mailto:i...@ifedorenko.com] Sent: Donnerstag, 23. Januar 2014 15:43 To: dev@maven.apache.org Subject: Re: Maven 4.0.0 I think there are two separate concerns/usecases here. Tools like m2e, netbeans or hudson need a way to push core components without changing maven distribution or project pom.xml files. I think system properties is the most straightforward way to do this. Existing event listener mechanisms are convoluted and inconsistent. I have to agree with this one, but I think we can offer clean(er) event listener interface(s) which will work the same way regardless how clients choose to contribute them to the system, via build extension, system property or custom distribution. -- Regards, Igor On 1/23/2014, 9:27, Jason van Zyl wrote: You either end up with a custom distribution and/or using system properties. Aside from the eventing mechanism being too convoluted, something where an extension can be specified in the POM and downloaded if required would be more consistent. The custom distribution route or having to invoke Maven using a system property IMO always ends up being more difficult than necessary. Additionally we have 4-5 different entities for eventing, I would just like one consistent one given everything we know now. On Jan 23, 2014, at 2:18 AM, Milos Kleint mkle...@gmail.com wrote: EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - 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 http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith - 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: Maven 4.0.0
Would it not be nice to be able to configure such stuff in the settings.xml? and other thing like this is described in this issue: https://jira.codehaus.org/browse/MNG-5356 (plus an extension is mention in the comments) Configuring this in the settings.xml would allow to have a single configuration for a e.g. a build slave Domi On 23.01.2014, at 19:50, Thiebaud, Christophe christophe.thieb...@sap.com wrote: FYI, the use-case for EventSpies @ SAP is exactly the one described by Igor : we use an event spy to instrument our Hudson/Jenkins instance to monitor the builds. This instrumentation MUST NOT require any pom.xml modification, so any maven project thrown into the Hudson/Jenkins can be monitored, nor any customization of the maven distribution (other than dropping files in lib/ext or setting maven.ext.class.path), so that maven is easy to upgrade. Regards Christophe -Original Message- From: Igor Fedorenko [mailto:i...@ifedorenko.com] Sent: Donnerstag, 23. Januar 2014 15:43 To: dev@maven.apache.org Subject: Re: Maven 4.0.0 I think there are two separate concerns/usecases here. Tools like m2e, netbeans or hudson need a way to push core components without changing maven distribution or project pom.xml files. I think system properties is the most straightforward way to do this. Existing event listener mechanisms are convoluted and inconsistent. I have to agree with this one, but I think we can offer clean(er) event listener interface(s) which will work the same way regardless how clients choose to contribute them to the system, via build extension, system property or custom distribution. -- Regards, Igor On 1/23/2014, 9:27, Jason van Zyl wrote: You either end up with a custom distribution and/or using system properties. Aside from the eventing mechanism being too convoluted, something where an extension can be specified in the POM and downloaded if required would be more consistent. The custom distribution route or having to invoke Maven using a system property IMO always ends up being more difficult than necessary. Additionally we have 4-5 different entities for eventing, I would just like one consistent one given everything we know now. On Jan 23, 2014, at 2:18 AM, Milos Kleint mkle...@gmail.com wrote: EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - 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 http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith - 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: Maven 4.0.0
Not for tooling integration usecase. There is usually a tight coupling between version of the tool, like m2e, and the version of extension getting pushed into maven core. So it should be the tool, not user, who decides what extensions should be pushed. There are usecases for user-configurable extensions like you suggest, but I do not believe stuffing them in settings.xml is a good idea. I believe separate set of config files, one per extension, is a better idea. I actually had this implemented some time ago but never got around to commit to public repo. It may actually happen, now that you reminded me about this, but no promise :-) -- Regards, Igor On 1/23/2014, 14:03, Dominik Bartholdi wrote: Would it not be nice to be able to configure such stuff in the settings.xml? and other thing like this is described in this issue: https://jira.codehaus.org/browse/MNG-5356 (plus an extension is mention in the comments) Configuring this in the settings.xml would allow to have a single configuration for a e.g. a build slave Domi On 23.01.2014, at 19:50, Thiebaud, Christophe christophe.thieb...@sap.com wrote: FYI, the use-case for EventSpies @ SAP is exactly the one described by Igor : we use an event spy to instrument our Hudson/Jenkins instance to monitor the builds. This instrumentation MUST NOT require any pom.xml modification, so any maven project thrown into the Hudson/Jenkins can be monitored, nor any customization of the maven distribution (other than dropping files in lib/ext or setting maven.ext.class.path), so that maven is easy to upgrade. Regards Christophe -Original Message- From: Igor Fedorenko [mailto:i...@ifedorenko.com] Sent: Donnerstag, 23. Januar 2014 15:43 To: dev@maven.apache.org Subject: Re: Maven 4.0.0 I think there are two separate concerns/usecases here. Tools like m2e, netbeans or hudson need a way to push core components without changing maven distribution or project pom.xml files. I think system properties is the most straightforward way to do this. Existing event listener mechanisms are convoluted and inconsistent. I have to agree with this one, but I think we can offer clean(er) event listener interface(s) which will work the same way regardless how clients choose to contribute them to the system, via build extension, system property or custom distribution. -- Regards, Igor On 1/23/2014, 9:27, Jason van Zyl wrote: You either end up with a custom distribution and/or using system properties. Aside from the eventing mechanism being too convoluted, something where an extension can be specified in the POM and downloaded if required would be more consistent. The custom distribution route or having to invoke Maven using a system property IMO always ends up being more difficult than necessary. Additionally we have 4-5 different entities for eventing, I would just like one consistent one given everything we know now. On Jan 23, 2014, at 2:18 AM, Milos Kleint mkle...@gmail.com wrote: EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - 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 http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith - 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
Re: Maven 4.0.0
You’r probably right about the tool integration, but I don’t think that password resolving as mention in the issue counts as a tool integration. I strongly believe this should be configurable in the settings.xml - which does not mean it must be the only place. Domi On 23.01.2014, at 20:09, Igor Fedorenko i...@ifedorenko.com wrote: Not for tooling integration usecase. There is usually a tight coupling between version of the tool, like m2e, and the version of extension getting pushed into maven core. So it should be the tool, not user, who decides what extensions should be pushed. There are usecases for user-configurable extensions like you suggest, but I do not believe stuffing them in settings.xml is a good idea. I believe separate set of config files, one per extension, is a better idea. I actually had this implemented some time ago but never got around to commit to public repo. It may actually happen, now that you reminded me about this, but no promise :-) -- Regards, Igor On 1/23/2014, 14:03, Dominik Bartholdi wrote: Would it not be nice to be able to configure such stuff in the settings.xml? and other thing like this is described in this issue: https://jira.codehaus.org/browse/MNG-5356 (plus an extension is mention in the comments) Configuring this in the settings.xml would allow to have a single configuration for a e.g. a build slave Domi On 23.01.2014, at 19:50, Thiebaud, Christophe christophe.thieb...@sap.com wrote: FYI, the use-case for EventSpies @ SAP is exactly the one described by Igor : we use an event spy to instrument our Hudson/Jenkins instance to monitor the builds. This instrumentation MUST NOT require any pom.xml modification, so any maven project thrown into the Hudson/Jenkins can be monitored, nor any customization of the maven distribution (other than dropping files in lib/ext or setting maven.ext.class.path), so that maven is easy to upgrade. Regards Christophe -Original Message- From: Igor Fedorenko [mailto:i...@ifedorenko.com] Sent: Donnerstag, 23. Januar 2014 15:43 To: dev@maven.apache.org Subject: Re: Maven 4.0.0 I think there are two separate concerns/usecases here. Tools like m2e, netbeans or hudson need a way to push core components without changing maven distribution or project pom.xml files. I think system properties is the most straightforward way to do this. Existing event listener mechanisms are convoluted and inconsistent. I have to agree with this one, but I think we can offer clean(er) event listener interface(s) which will work the same way regardless how clients choose to contribute them to the system, via build extension, system property or custom distribution. -- Regards, Igor On 1/23/2014, 9:27, Jason van Zyl wrote: You either end up with a custom distribution and/or using system properties. Aside from the eventing mechanism being too convoluted, something where an extension can be specified in the POM and downloaded if required would be more consistent. The custom distribution route or having to invoke Maven using a system property IMO always ends up being more difficult than necessary. Additionally we have 4-5 different entities for eventing, I would just like one consistent one given everything we know now. On Jan 23, 2014, at 2:18 AM, Milos Kleint mkle...@gmail.com wrote: EventSpies are not useless, I use them in netbeans extensively. I inject them using maven.ext.class.path property Milos On Thu, Jan 23, 2014 at 3:57 AM, Jason van Zyl ja...@takari.io wrote: I know there is the roadmap page (https://cwiki.apache.org/confluence/display/MAVEN/Roadmap), but I started a Maven 4.0.0 page with some general notes and I just want to hook in the JIRA macro to pull in all the 4.0.0 issues at the bottom, but I have figured that out yet. I just want to be able to write notes and and see the issues, and turn them into issues when appropriate. If anyone knows how to embed the macro the page I'd appreciate if you can tweak this page: https://cwiki.apache.org/confluence/display/MAVEN/Maven+4.0.0 Back to cleaning up JIRA. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - We know what we are, but know not what we may be. -- Shakespeare - 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 http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest
Re: JIRA Cleanup
Jason, the wiki page is a really good writeup and I like the strategy to force reporters to create a simple project which will reproduce their issue. Regards Mirko -- Sent from my mobile On Jan 23, 2014 3:33 AM, Jason van Zyl ja...@takari.io wrote: I changed the strategy slightly as I thought it might be crappy if the issue was created 5 years ago, but the person updated it 2 months ago. So I took all the issues that have not been updated in the last year and unassigned and closed those out. Got to about the same number and thought this more fair. I referred anyone looking at the comment to https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014 I'll start sifting through what remains tomorrow. On Jan 22, 2014, at 1:02 PM, Jason van Zyl ja...@takari.io wrote: Yup, it's very straight forward to add a comment to each of the issues that will be closed. When I publish the accompanying documentation I can point the comment at the documentation. Good call. On Jan 22, 2014, at 12:16 PM, Jason van Zyl ja...@takari.io wrote: Sure, good idea. I assume there's a relatively straight forward way to do that with a bulk operation. On Jan 22, 2014, at 12:09 PM, Paul Benedict pbened...@apache.org wrote: I advise that we add a comment in each closing issue explaining that it was closed specifically because it's more than 2 years old and to re-open it only if it is still valid. Otherwise, it will look very rude to close a ticket without an explanation. BTW, what I just recommended was done by JBoss Hibernate and Spring Framework when they cleared out their old tickets. It was great to know their reasoning. On Wed, Jan 22, 2014 at 10:59 AM, Jason van Zyl ja...@takari.io wrote: Ok, I'm going to pull the ripcord tonight (8 hours from now). On Jan 21, 2014, at 9:19 PM, Jason van Zyl ja...@takari.io wrote: So after looking at the issues more closely even at the 5 year-old mark there are still too many. At the 2 year-old mark it's a bit more reasonable. If I close all issues older than 2 years-old which are not assigned thats 415 so we would be left with 220 open issues which after a week or two I can probably get through, faster with some help. But that's probably reasonable as more recent issues are pertinent to 3.x as I myself am probably not going to dig back into 2.x issues and fix them. So I propose sending a note to the dev and user list stating that we're trying to get the JIRA issue under control. We're closing all unassigned issues older than 2 years but people are free to reopen issues for bugs if they follow a process of providing a working stand-alone example of the problem. This will at least start the cleanup process. How's that sound? On Jan 20, 2014, at 4:53 PM, Jason van Zyl ja...@takari.io wrote: Ok, I'll write something up and send it to the user and dev list. On Jan 20, 2014, at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: +1 here. On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar and...@hammar.net wrote: +1 on clean up if we communicate this (and explain why). 0 on move /Anders On Mon, Jan 20, 2014 at 6:53 PM, Dominik Bartholdi d...@fortysix.ch wrote: +1 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier aherit...@gmail.com wrote: +1 with a jira cleanup (but documented and announced to users to let them understand what we do and why) +1 to move to ASF On Mon, Jan 20, 2014 at 6:48 PM, Jason van Zyl ja...@takari.io wrote: Works for me to just start over on the ASF JIRA. There are a couple issues I'd move but we can migrate a issues easily. What can't continue is the complete, incomprehensible mess that is there now. On Jan 20, 2014, at 12:32 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: If we are going wholesale dumping issues (and I am not against that), I have a more radical suggestion... let's just move core to the ASF JIRA... with next to no issues needing migration it would be easy ;-) On 20 January 2014 17:23, Jason van Zyl ja...@takari.io wrote: Really, it's more about dropping a nuclear bomb on JIRA. While trying to sift through it this weekend it's clear to me it's less than ideal in there. There are issues that are 12 years old and while there might be some useful information in there that we hand select, I think anything that is older than 5 years we should just close as incomplete because with the great deal of change that's happened with 3.x most of it isn't relevant and if it is, and someone cares that much then it can be reopened with a stand-alone working example of the problem. Now, as to the requirements for a stand-alone working example I think we should enforce this because personally I'm not going to check out someone's project, figure
