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 wrote: > +1 here. > > On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar 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 wrote: >> >>> +1 cleanup is a really good idea! >>> >>> On 20.01.2014, at 18:50, Arnaud Héritier 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 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 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-
Re: JIRA Cleanup
+1 here. On Mon, Jan 20, 2014 at 1:12 PM, Anders Hammar 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 wrote: > >> +1 cleanup is a really good idea! >> >> On 20.01.2014, at 18:50, Arnaud Héritier 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 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 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..
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 wrote: > +1 cleanup is a really good idea! > > On 20.01.2014, at 18:50, Arnaud Héritier 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 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 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 cleanup is a really good idea! On 20.01.2014, at 18:50, Arnaud Héritier 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 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 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 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 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 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
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 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 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
On Jan 20, 2014, at 12:32 PM, Stephen Connolly 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 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
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 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 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
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 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: SPDX Maven Plugin
I believe m2eclipse does have some built-in completion for that, and yes, I'm interested -- -- Aldrin Leal, 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 wrote: > 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
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
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 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 wrote: There is probably more ways to do this, but you can implement AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate project . 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 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
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 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 wrote: > There is probably more ways to do this, but you can implement > AbstractMavenLifecycleParticipant#afterProjectsRead to manipulate > project . 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 > 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 > (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, > 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 > > 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 directly > > > > > > On 20 January 2014 09:03, Stephane Nicoll > > 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 > > > > > > > > > > > > the-s-project > > > ... > > > pom > > > import > > > > > > > > > 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 MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! nbsp;! >
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 . 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 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
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
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 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
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, 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 > 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 directly > > > On 20 January 2014 09:03, Stephane Nicoll > 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 > > > > > > > > the-s-project > > ... > > pom > > import > > > > > > 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 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 directly On 20 January 2014 09:03, Stephane Nicoll 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 > > > > the-s-project > ... > pom > import > > > 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. >
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 the-s-project ... pom import 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.
