exclude on scope import
Hi, Has anybody thought (or worked on) the ability to exclude dependencies from the import of a pom for a given project. Let's say that project S uses commons-logging and we use that project in our project. We have something like dependency groupId/groupId artifactIdthe-s-project/artifactId version.../version typepom/type scopeimportscope /dependency Now I'd like to exclude the commons-logging dependency from the whole project so that I can use the slf4j binder instead. Thoughts? Thanks, S.
Re: exclude on scope import
The hack way I would use is to create an intermediate wrapper project and then you can define exclusions on that wrapper at the pom level directly. Other than that you just have to wait for model version 5.0.0 when the provides element that I want to introduce would allow either slf4j's binder to advertise that it provides commons-logging, or you would be able to state that in your dependency directly On 20 January 2014 09:03, Stephane Nicoll stephane.nic...@gmail.com wrote: Hi, Has anybody thought (or worked on) the ability to exclude dependencies from the import of a pom for a given project. Let's say that project S uses commons-logging and we use that project in our project. We have something like dependency groupId/groupId artifactIdthe-s-project/artifactId version.../version typepom/type scopeimportscope /dependency Now I'd like to exclude the commons-logging dependency from the whole project so that I can use the slf4j binder instead. Thoughts? Thanks, S.
Re: exclude on scope import
(TL;DR: Use this repo and the versions on your dependencyMgmt: http://version99.qos.ch/) a hack, but works like a charm: http://day-to-day-stuff.blogspot.com.br/2007/10/announcement-version-99-does-not-exist.html -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Mon, Jan 20, 2014 at 6:12 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The hack way I would use is to create an intermediate wrapper project and then you can define exclusions on that wrapper at the pom level directly. Other than that you just have to wait for model version 5.0.0 when the provides element that I want to introduce would allow either slf4j's binder to advertise that it provides commons-logging, or you would be able to state that in your dependency directly On 20 January 2014 09:03, Stephane Nicoll stephane.nic...@gmail.com wrote: Hi, Has anybody thought (or worked on) the ability to exclude dependencies from the import of a pom for a given project. Let's say that project S uses commons-logging and we use that project in our project. We have something like dependency groupId/groupId artifactIdthe-s-project/artifactId version.../version typepom/type scopeimportscope /dependency Now I'd like to exclude the commons-logging dependency from the whole project so that I can use the slf4j binder instead. Thoughts? Thanks, S.
maven-shared pull request: Upgrade the dependency on maven-artifact for mav...
GitHub user ebourg opened a pull request: https://github.com/apache/maven-shared/pull/4 Upgrade the dependency on maven-artifact for maven-shared-io Hi, A maven-shared-io test doesn't compile against maven-artifact 2.2.1 because the signature of a constructor changed in `org.apache.maven.artifact.resolver.ArtifactResolutionException`. Here is a patch fixing this. An alternative would be to put back the missing constructor in ArtifactResolutionException. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ebourg/maven-shared maven-core-upgrade-for-maven-shared-io Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven-shared/pull/4.patch commit c8ce595cff9e3fad56b7844b3a2fd69222101957 Author: Emmanuel Bourg ebo...@apache.org Date: 2014-01-20T10:59:31Z Update maven-shared-io to build against Maven 2.2.1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Adding a classpath element within a Mojo
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
Re: Adding a classpath element within a Mojo
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
Re: exclude on scope import
+1, we've been using this trick for some years now to be sure nobody could send their logs basically to /dev/null without being noticed. In the meantime, as we actually control the corp pom, we also both added the exclusions everywhere we could + enabled a bannedDependencies on commons-logging. Granted, it kind of became a (2) belt(s) and braces solution, but this works perfectly fine :-). HTH 2014/1/20 Aldrin Leal ald...@leal.eng.br (TL;DR: Use this repo and the versions on your dependencyMgmt: http://version99.qos.ch/) a hack, but works like a charm: http://day-to-day-stuff.blogspot.com.br/2007/10/announcement-version-99-does-not-exist.html -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Mon, Jan 20, 2014 at 6:12 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: The hack way I would use is to create an intermediate wrapper project and then you can define exclusions on that wrapper at the pom level directly. Other than that you just have to wait for model version 5.0.0 when the provides element that I want to introduce would allow either slf4j's binder to advertise that it provides commons-logging, or you would be able to state that in your dependency directly On 20 January 2014 09:03, Stephane Nicoll stephane.nic...@gmail.com wrote: Hi, Has anybody thought (or worked on) the ability to exclude dependencies from the import of a pom for a given project. Let's say that project S uses commons-logging and we use that project in our project. We have something like dependency groupId/groupId artifactIdthe-s-project/artifactId version.../version typepom/type scopeimportscope /dependency Now I'd like to exclude the commons-logging dependency from the whole project so that I can use the slf4j binder instead. Thoughts? Thanks, S. -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! nbsp;!
Re: Adding a classpath element within a Mojo
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.comwrote: 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
Re: Adding a classpath element within a Mojo
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.comwrote: 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
SPDX Maven Plugin
Greetings all, I am somewhat new to Maven plugin development and would like to ask the developer community for some feedback and help in developing a plugin to generate project license metadata compliant with the Software Product Data Exchange (SPDX) standard. The SPDX specification is a standard format for communicating the components, licenses and copyrights associated with a software package. We are on version 1.2 of the spec and is in use at several of the SPDX participating companies (see www.spdx.org for more info). The motivation for the plugin was the result of a discussion between Phil Odence and myself (from SPDX) and Jim Jagielski and Henri Yandell (from Apache) on ideas for how Apache projects could produce or utilize SPDX. It was suggested that a maven plugin would substantially reduce the effort for several Apache projects. Over the past couple weeks, I have studied the Maven Mojo and plugin API's and produced a prototype which will generate an SPDX file based on a POM file. You can find the code on Github at https://github.com/goneall/spdx-maven-plugin Here's my questions for the Maven Developers: - Is anyone on the list interested and have some time to collaborate on the plugin? I'm pretty comfortable on the Java and SPDX output coding, but I'm new to Maven and could use some experienced review of some of my choices regarding Maven parameters and implementation. A review of the code would be most appreciated. I could also post the more specific questions to this list if that is appropriate. - Are there any related efforts I should be aware of? (Note: I did find another spdx maven plugin on github. I reached out to the author and have not heard back, so I'm not sure how active the project is). - Once the plugin is built and unit tested, what is the best way to make it more accessible to other developers? - A spreadsheet mapping the SPDX properties to either spdx-maven-prototype configuration parameters or existing Maven model properties can be downloaded at https://github.com/goneall/spdx-maven-plugin/blob/master/SPDX-fields-maven-m apping.xlsx. Feedback on the prototype choices are welcome. There is also a proposed longer term mapping, some of which extends the current Maven model. Thanks in advance, Gary - Gary O'Neall Principal Consultant Source Auditor Inc. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
JIRA Cleanup
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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: SPDX Maven Plugin
I believe m2eclipse does have some built-in completion for that, and yes, I'm interested -- -- Aldrin Leal, ald...@leal.eng.br Master your EC2-fu! Get the latest ekaterminal public beta http://www.ingenieux.com.br/products/ekaterminal/ On Mon, Jan 20, 2014 at 2:20 PM, Gary O'Neall g...@sourceauditor.comwrote: Greetings all, I am somewhat new to Maven plugin development and would like to ask the developer community for some feedback and help in developing a plugin to generate project license metadata compliant with the Software Product Data Exchange (SPDX) standard. The SPDX specification is a standard format for communicating the components, licenses and copyrights associated with a software package. We are on version 1.2 of the spec and is in use at several of the SPDX participating companies (see www.spdx.org for more info). The motivation for the plugin was the result of a discussion between Phil Odence and myself (from SPDX) and Jim Jagielski and Henri Yandell (from Apache) on ideas for how Apache projects could produce or utilize SPDX. It was suggested that a maven plugin would substantially reduce the effort for several Apache projects. Over the past couple weeks, I have studied the Maven Mojo and plugin API's and produced a prototype which will generate an SPDX file based on a POM file. You can find the code on Github at https://github.com/goneall/spdx-maven-plugin Here's my questions for the Maven Developers: - Is anyone on the list interested and have some time to collaborate on the plugin? I'm pretty comfortable on the Java and SPDX output coding, but I'm new to Maven and could use some experienced review of some of my choices regarding Maven parameters and implementation. A review of the code would be most appreciated. I could also post the more specific questions to this list if that is appropriate. - Are there any related efforts I should be aware of? (Note: I did find another spdx maven plugin on github. I reached out to the author and have not heard back, so I'm not sure how active the project is). - Once the plugin is built and unit tested, what is the best way to make it more accessible to other developers? - A spreadsheet mapping the SPDX properties to either spdx-maven-prototype configuration parameters or existing Maven model properties can be downloaded at https://github.com/goneall/spdx-maven-plugin/blob/master/SPDX-fields-maven-m apping.xlsx. Feedback on the prototype choices are welcome. There is also a proposed longer term mapping, some of which extends the current Maven model. Thanks in advance, Gary - Gary O'Neall Principal Consultant Source Auditor Inc. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA Cleanup
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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau
Re: JIRA Cleanup
Am 2014-01-20 18:32, schrieb Stephen Connolly: 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 ;-) +1 I head this idea in mind for several months. Make a clean cut. Read only. Period. New issues in ASF JIRA only. If someone has found an issue which is already in Codehaus JIRA that should be migrated of course. 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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA Cleanup
Am 2014-01-20 18:32, schrieb Stephen Connolly: 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 ;-) +1 I head this idea in mind for several months. Make a clean cut. Read only. Period. New issues in ASF JIRA only. If someone has found an issue which is already in Codehaus JIRA that should be migrated of course. 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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA Cleanup
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 ;-) +1 Good idea. Dan 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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA Cleanup
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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: JIRA Cleanup
+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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: JIRA Cleanup
+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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA Cleanup
+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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JIRA Cleanup
+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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - 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: JIRA Cleanup
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 out how to interpret it in relation to the actual problem in Maven and then create a project I can turn into an IT. I'm just not going to do it generally. There might be exceptions but I don't want to read a textual examples or try to figure out snippets of a production project that can't be shared. In m2e we require a working example project to even look at a problem and if the issue sits there for a year with a working sample project we close it. Having an issue tracking system with 700 open issues is useless, so I would like to do a mass purge. It shouldn't really get beyond 50 open issues or it's just impossible to manage effectively. Not sure what anyone else thinks but our JIRA situation is just not effective. I'm thinking anything over 5 years old that isn't assigned to a core developer we just close as incomplete and then see what we're left with. If anyone complains then we point them at doco (I'll write it) about creating a stand-alone project because otherwise it become impossible. I spent 8 hours over the weekend looking at issues trying to interpret what someone was trying to say and I don't want to guess. If the user cares enough they can make an example project. Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier - 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 - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
