maven-core tests fail when invoked via ant.
Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. = test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/target/test-reports [junit] Running org.apache.maven.WagonSelectorTest [junit] Testsuite: org.apache.maven.WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:795) [junit] at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121) [junit] at org.apache.maven.WagonSelectorTest.setUp(WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.repository.exception.ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.components.sec.dispatcher.SecDispatcher', implementation: 'org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.repository.DefaultComponentRepository.addComponentDescriptor(DefaultComponentRepository.java:184) [junit] at org.codehaus.plexus.DefaultPlexusContainer.addComponentDescriptor(DefaultPlexusContainer.java:515) [junit] at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:738) [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779) [junit] BUILD FAILED /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/maven-build.xml:206: Test org.apache.maven.WagonSelectorTest failed = Any clues on getting rid of this error? I'm thinking whether the generated build.xml has some issue. Much appreciate your help! The maven-build.xml is at [2]. The full ant output of the test failure is at [3]. I'm using maven-ant-plugin-2.3 with maven-2.2.1. The test fails with both ant 1.7.1 and 1.8.1. Please do let me know if any other information is needed. [1] https://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-core/ [2] http://pastebin.com/9eWM0xjN [3] http://pastebin.com/vRC6qVa8 Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa Blog: http://kasunbg.blogspot.com Twitter: http://twitter.com/kasunbg
Re: The JIRA chocolate box
a very good idea +1 LieGrue, strub --- On Sun, 6/19/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: The JIRA chocolate box To: Maven Developers List dev@maven.apache.org Date: Sunday, June 19, 2011, 3:05 AM I am only proposing this for MNG at this point. On Jun 18, 2011, at 10:55 PM, Ralph Goers ralph.go...@dslextreme.com wrote: My guess is a reference to Forrest Gump - you never know what you are going to get. Ralph On Jun 18, 2011, at 7:51 PM, Martin Gainty wrote: agreed although scanning the Surefire JIRA i did notice some of jasons original jiras were'nt addressed for upwards of 3-4 years (by Brett Porter) I havent heard of JIRA chocolate box..maybe an implementation of a Finite State Machine or perhaps this is a non sequitir? Bedankt, Martin __ Date: Sat, 18 Jun 2011 18:30:04 -0400 Subject: The JIRA chocolate box From: bimargul...@gmail.com To: dev@maven.apache.org I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
Nice idea +1. BTW asking a test case is not very easy. As most of the time issues happen on corpo/private *complex* project. So extracting a test case can be hard. 2011/6/19 Benson Margulies bimargul...@gmail.com: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Margulies bimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
I opened MNG-5119 to track this. We can use the Wiki too [2], if useful at any time. I already did some minor improvements and published 3.0.4-SNAPSHOT site [3] (sync pending) to see the actual state, to be compared with 3.0.3 [4] I'm starting to test ideas on shared components, since they are the other place where components (not plugins) need documentation improvement Regards, Hervé [1] http://jira.codehaus.org/browse/MNG-5119 [2] https://cwiki.apache.org/confluence/display/MAVEN/Proposals [3] http://maven.apache.org/ref/3.0.4-SNAPSHOT/ [4] http://maven.apache.org/ref/3.0.3/ Le samedi 18 juin 2011, Benson Margulies a écrit : Returning to the very start of this thread: Now that I seem to have caught up with my current box of itches on plugins for the moment, I'd be more than happy to join this parade. Could some more experience committer grab a defect JIRA that has a some value to it, throw it up here on the list, and shout 'pull'? On Mon, Jun 13, 2011 at 5:25 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: While we have a good standard for plugin site organization [1] that was debated a few years ago to improve Maven documentation, we have nothing for components. And the actual state is not good: see Maven core, where even simplest description of every component is not done but inherited from parent... I think we could define something for components like plugins, relatively easy to follow and definitely useful as a starting point. I have a few ideas: - a site descriptor with links to javadoc and jxr (since code is the most important thing expected from components), and a FAQ - an introduction with a list of component interfaces and implementations provided (I have no precise idea on the form) Any other idea? I'll try to implement some ideas on Maven core for the next version: we'll write a guide later with practices found. Regards, Hervé [1] http://maven.apache.org/guides/development/guide-plugin-documentation.ht ml Le vendredi 10 juin 2011, Evgeny Mandrikov a écrit : HI all, Just my 2 cents : Main problem with jumping into Maven core development is understanding of internal architecture and core parts. Also this affects development of plugins. Thus IMO improving this can definitely animate Maven ecosystem (Core, Core Plugins, Mojo, ...) in general. Another point is that improving core without visible user features doesn't bring a lot of value. But such things (like slf4j, @Inject) also interesting as a paralel process together with new features. On Thu, Jun 9, 2011 at 20:21, John Casey jdca...@commonjava.org wrote: CC'ing dev@: I hope the PMC doesn't mind. We've been spending some time on-and-off talking about how we can open up development in the Maven core, and see if we can attract some fresh minds and ideas. I'd like to copy a list of some things we've been talking about, and open it up to anyone here on the dev list who has an opinion. This list is not meant to be comprehensive, that's the point! I (and others) would like to start the conversation about what we need to do to get more of the community involved in developing the core of Maven. If you're interested, please read on, and give us your thoughts! --- On 6/8/11 8:18 PM, Barrie Treloar wrote: List of suggestions to improve hacking on the core * Move to a more sustainable architecture (Stephens started this with plexus-utils) * Upgrading Wagon (Mark) * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) * Component annotations via more standard notations (suggested by John) * do stuff that is interesting to others (see the reaction to the mixin stuff I started) (suggested by Brett) * apply patches from people that genuinely can help (suggested by Brett) John also suggested - the Maven App Engine stuff I've been working on. which allows people to cobble together Maven-based apps, and play around with the different internal services / subsystems of Maven this is under: http://svn.apache.org/repos/asf/maven/sandbox/trunk/mae if anyone is interested... - blogs explaining the way to do various tasks inside the core...how different subsystems work, or something see below... - putting together some sort of call for people to come help with specific new features in the core, like versionless parents, multiple POM syntaxes, etc... I think this thread is going to be the call...or at least, the first of many such calls. Here I think etc needs to be expanded :) Please, that's the point of the conversation...expand it! p.s. I really like the idea of versionless parents that would save some pain I'm
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: RE: [VOTE]: release maven-changes-plugin 2.6
don't knock somebody who is taking the time and effort to actually run a release. any improvement is an improvement... you could quibble that maybe it should have been a 2.5.1 and not a 2.6 but it is down to the person who steps up to make the release. speaking with my pmc hat on, any improvement merrits a release... the decision as to whether to take that effort is down to the individual committer who steps up. it may be that benson needs the release in another project, so what you see as trivial may be a blocker to somebody else (personally in those cases I usually add a ref to the project needing the fast release, but there is no requirement to have such a ref). lets keep things positive, and benson, keep up the hard work I'll review the release when at a computer where I can test it - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 09:35, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: The JIRA chocolate box
On 2011-06-19 00:30, Benson Margulies wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. This is one of the major obstacles we have at the Maven project. The sheer amount of old and sometimes really old issues in JIRA. For the last couple of years I've pinged reporters of new issues straight away for test cases, if none was attached to a new issue. But as you say there are lots of old ones that are practically impossible to resolve without some kind of test case. Maybe we should plan a JIRA cleanup day? Let's find a date where some of us on the dev team can work together to clean up old issues. We announce that together with your proposed letter to the users list as well. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I've done this kind of thing for plugins in the past. For those I have opted to close the issue as Incomplete, because it lacks a reproducible test case. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. Agreed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
This is a great idea. Some minor comments inline. On 2011-06-19 04:22, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. Over the years I've sometimes had problems reading tar files attached to JIRA from users on my Windows machine, even though I have the proper tools for it. I think ZIP of JAR files are generally more portable than TAR files. To be able to keep our stuff in one place, I prefer attached compressed archives in JIRA over something pushed to GitHub. What happens if someone, after a couple of years, wants to download the test case and github no longer exists. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. Excellent stuff! --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Margulies bimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
On 19 June 2011 11:52, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 00:30, Benson Margulies wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. This is one of the major obstacles we have at the Maven project. The sheer amount of old and sometimes really old issues in JIRA. For the last couple of years I've pinged reporters of new issues straight away for test cases, if none was attached to a new issue. But as you say there are lots of old ones that are practically impossible to resolve without some kind of test case. Maybe we should plan a JIRA cleanup day? Let's find a date where some of us on the dev team can work together to clean up old issues. We announce that together with your proposed letter to the users list as well. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I've done this kind of thing for plugins in the past. For those I have opted to close the issue as Incomplete, because it lacks a reproducible test case. +1 This will make it easier to find later if necessary. I think it's vital that the resolution distinguish such cases from fixed bugs and non-bugs. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. Agreed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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: svn commit: r1137235 - /maven/plugins/trunk/maven-changes-plugin/pom.xml
Hmm, I not quite sure what happened here. Benson? On 2011-06-18 22:00, bimargul...@apache.org wrote: Author: bimargulies Date: Sat Jun 18 20:00:55 2011 New Revision: 1137235 URL: http://svn.apache.org/viewvc?rev=1137235view=rev Log: [maven-release-plugin] rollback the release of maven-changes-plugin-2.6 Modified: maven/plugins/trunk/maven-changes-plugin/pom.xml Modified: maven/plugins/trunk/maven-changes-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-changes-plugin/pom.xml?rev=1137235r1=1137234r2=1137235view=diff == --- maven/plugins/trunk/maven-changes-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-changes-plugin/pom.xml Sat Jun 18 20:00:55 2011 @@ -507,7 +507,6 @@ under the License. locales localede/locale localefr/locale -localept_BR/locale localesv/locale /locales /configuration -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
FWIW, I've spent plenty of time on the 'trying to make a test case' side of the fence and I appreciate how hard it can be. If someone makes a cogent case that they can't come with a testcase, then there are possible outcomes: 1: A dev finds the story sufficiently compelling to try to build a test case or otherwise analyze the problem, soon enough that the caravan does not move on. 1a: they come up with something and the OP can confirm that it fixes things. 1b: they are stumped or whatever they come with doesn't work. 2: no one in the dev community is willing to tackle. In short, stating this policy doesn't stop us from trying to be helpful in the impossible case, I just think that we should be realistic in declaring failure to avoid recreating the compost heap. As for github, I don't mind having the email stick to 'attach a zip'. There are cases where github, or even, 'this svn URL of another Apache project' allows collaboration with the OP in refining a test case, but OPs will think of this for themselves. I don't know that we need a JIRA day; we need everyone willing on dev@ to start digging down the JIRAs pinging. On Sun, Jun 19, 2011 at 7:02 AM, sebb seb...@gmail.com wrote: On 19 June 2011 11:52, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 00:30, Benson Margulies wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. This is one of the major obstacles we have at the Maven project. The sheer amount of old and sometimes really old issues in JIRA. For the last couple of years I've pinged reporters of new issues straight away for test cases, if none was attached to a new issue. But as you say there are lots of old ones that are practically impossible to resolve without some kind of test case. Maybe we should plan a JIRA cleanup day? Let's find a date where some of us on the dev team can work together to clean up old issues. We announce that together with your proposed letter to the users list as well. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I've done this kind of thing for plugins in the past. For those I have opted to close the issue as Incomplete, because it lacks a reproducible test case. +1 This will make it easier to find later if necessary. I think it's vital that the resolution distinguish such cases from fixed bugs and non-bugs. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. Agreed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1137235 - /maven/plugins/trunk/maven-changes-plugin/pom.xml
I know what I think I did. 1) my copy of the pom was one back from Dennis' change for the locale. 2) I started the release process. 3) I got an error to the effect that pom.xml was out of date. 4) release:rollback 5) svn up, with a G on the pom, which I thought merged Dennis in. I can't rule out the possibility that I reversed the rollback and the up. I'll cancel the vote, fix the pom, and re-roll. On Sun, Jun 19, 2011 at 7:03 AM, Dennis Lundberg denn...@apache.org wrote: Hmm, I not quite sure what happened here. Benson? On 2011-06-18 22:00, bimargul...@apache.org wrote: Author: bimargulies Date: Sat Jun 18 20:00:55 2011 New Revision: 1137235 URL: http://svn.apache.org/viewvc?rev=1137235view=rev Log: [maven-release-plugin] rollback the release of maven-changes-plugin-2.6 Modified: maven/plugins/trunk/maven-changes-plugin/pom.xml Modified: maven/plugins/trunk/maven-changes-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-changes-plugin/pom.xml?rev=1137235r1=1137234r2=1137235view=diff == --- maven/plugins/trunk/maven-changes-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-changes-plugin/pom.xml Sat Jun 18 20:00:55 2011 @@ -507,7 +507,6 @@ under the License. locales localede/locale localefr/locale - localept_BR/locale localesv/locale /locales /configuration -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
I'd rather see a release with 3 bug fixes if they code base is idle than see not see a release for weeks/months whilst someone waits for N more issues to be resolved. -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Sun, Jun 19, 2011 at 8:34 PM, Gavin McDonald ga...@16degrees.com.auwrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - 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: RE: [VOTE]: release maven-changes-plugin 2.6
1: This [VOTE] is cancelled due to a merge snafu in the prep. 2: for Gavin: I spent several days fixing up a very broken feature to render the plugin actually usable with customized JIRA installations. I want to put that work to work in the real world, and I didn't see any other outstanding issues that I felt qualified to tackle straight off. I also invited the dev@ and pmc@ community to comment on the proposal to make a release several days before I started it, and received no doubts. If people would prefer to call it 2.5.1 tell me now, but I think that the amount of code furniture movement, pace the small JIRA count, justifies 2.6. On Sun, Jun 19, 2011 at 5:56 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: don't knock somebody who is taking the time and effort to actually run a release. any improvement is an improvement... you could quibble that maybe it should have been a 2.5.1 and not a 2.6 but it is down to the person who steps up to make the release. speaking with my pmc hat on, any improvement merrits a release... the decision as to whether to take that effort is down to the individual committer who steps up. it may be that benson needs the release in another project, so what you see as trivial may be a blocker to somebody else (personally in those cases I usually add a ref to the project needing the fast release, but there is no requirement to have such a ref). lets keep things positive, and benson, keep up the hard work I'll review the release when at a computer where I can test it - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 09:35, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Kristian, How are you seeing 10? --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11212version=17375 ?? Den 19. juni 2011 kl. 13:40 skrev Benson Margulies bimargul...@gmail.com: Kristian, How are you seeing 10? --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
On 2011-06-19 13:39, Benson Margulies wrote: Kristian, How are you seeing 10? In the release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375styleName=TextprojectId=11212 In JIRA 4 the default layout changed so that it shows some sort of summary, which I don't understand the need for at all. It shows the 3 most recently updated issues: http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 If you want to see *all* issues for that version (who doesn't?) you need to click on the Issues tab on the left. Not very user friendly is you ask me... --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE]: release maven-changes-plugin 2.6
Well, that explains that. 2.6 it is, and new vote coming soon. On Sun, Jun 19, 2011 at 8:02 AM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 13:39, Benson Margulies wrote: Kristian, How are you seeing 10? In the release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375styleName=TextprojectId=11212 In JIRA 4 the default layout changed so that it shows some sort of summary, which I don't understand the need for at all. It shows the 3 most recently updated issues: http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 If you want to see *all* issues for that version (who doesn't?) you need to click on the Issues tab on the left. Not very user friendly is you ask me... --benson On Sun, Jun 19, 2011 at 5:50 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: Dont know if we're looking at the same jira; I see 10 issues being resolved. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - 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
[VOTE take 2]: release maven-changes-plugin version 2.6
Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375styleName=TextprojectId=11212 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-025/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE take 2]: release maven-changes-plugin version 2.6
+1 BTW: Your reply-to and send-to headings are not totally according to maven common release procedure; http://maven.apache.org/developers/release/maven-project-release-procedure.html Kristian sø., 19.06.2011 kl. 08.16 -0400, skrev Benson Margulies: Hi, We solved 10 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?version=17375styleName=TextprojectId=11212 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-025/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Help in starting with maven prompter
Hi I would like to create this scenario on running a maven project: Do you want to enter module-name? ( Y / N) (on entering Y , i should ask for the parameter) *Y module-name: nameofthename * (on entering N , i should terminate the asking process and the rest of the project build should be completed) *N . . Project Build Success Full * -- Is this possible with ArchetypeCreationQueryer ? If so i dont know how to implement it in my project and run it and see how it works? Any help will be thank full Regards -Goutham
Re: The JIRA chocolate box
+1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connollystephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connollystephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE take 2]: release maven-changes-plugin version 2.6
Hi, i've checked the web site and found that the link (http://maven.apache.org/plugins/maven-changes-plugin-2.6/index.html) to the changes.xsd file does not work... Furthermore the link Cobertura Test Coverage links to the index.html page...and not to a cobertura test coverage... And a question about the the homepage link on the http://maven.apache.org/plugins/maven-changes-plugin-2.6/project-summary.html Shouldn't that a be a different location than so many ../../.. why no simple http://maven.apache.org/plugins/maven-changes-plugin/; ? Kind regards Karl Heinz Marbaise -- SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893 Dipl.Ing.(FH) Karl Heinz MarbaiseICQ#: 135949029 Hauptstrasse 177 USt.IdNr: DE191347579 52146 Würselen http://www.soebes.de - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connollystephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE take 2]: release maven-changes-plugin version 2.6
Benson, Did you use Maven 3 to deploy the site? I recommend using Maven 2 for site deployment until we get maven-site-plugin 3.0-beta-4 released. On 2011-06-19 19:00, Karl Heinz Marbaise wrote: Hi, i've checked the web site and found that the link (http://maven.apache.org/plugins/maven-changes-plugin-2.6/index.html) to the changes.xsd file does not work... Furthermore the link Cobertura Test Coverage links to the index.html page...and not to a cobertura test coverage... And a question about the the homepage link on the http://maven.apache.org/plugins/maven-changes-plugin-2.6/project-summary.html Shouldn't that a be a different location than so many ../../.. why no simple http://maven.apache.org/plugins/maven-changes-plugin/; ? Kind regards Karl Heinz Marbaise -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE take 2]: release maven-changes-plugin version 2.6
1) yes. WHen I use 2 I got stumped on authentication in the deploy. 2) I can redeploy. Little did I know. I don't see any reason to rewind the vote. I'll redeploy. On Sun, Jun 19, 2011 at 1:15 PM, Dennis Lundberg denn...@apache.org wrote: Benson, Did you use Maven 3 to deploy the site? I recommend using Maven 2 for site deployment until we get maven-site-plugin 3.0-beta-4 released. On 2011-06-19 19:00, Karl Heinz Marbaise wrote: Hi, i've checked the web site and found that the link (http://maven.apache.org/plugins/maven-changes-plugin-2.6/index.html) to the changes.xsd file does not work... Furthermore the link Cobertura Test Coverage links to the index.html page...and not to a cobertura test coverage... And a question about the the homepage link on the http://maven.apache.org/plugins/maven-changes-plugin-2.6/project-summary.html Shouldn't that a be a different location than so many ../../.. why no simple http://maven.apache.org/plugins/maven-changes-plugin/; ? Kind regards Karl Heinz Marbaise -- Dennis Lundberg - 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: The JIRA chocolate box
Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- Dennis
Re: The JIRA chocolate box
On Sunday, June 19, 2011 7:13:11 PM Dennis Lundberg wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. For CXF, we have a special NeedMoreInfo version that we use for this. We set the FixFor version to that when we've added a comment that requires more information from the user. We can easily get a list of all the issues that require more information, when we asked for it, etc. Probably an abuse of the version field though. :-) Dan K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connollystephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. -- --- 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE take 2]: release maven-changes-plugin version 2.6
I have redeployed using 2.x. On Sun, Jun 19, 2011 at 1:42 PM, Benson Margulies bimargul...@gmail.com wrote: 1) yes. WHen I use 2 I got stumped on authentication in the deploy. 2) I can redeploy. Little did I know. I don't see any reason to rewind the vote. I'll redeploy. On Sun, Jun 19, 2011 at 1:15 PM, Dennis Lundberg denn...@apache.org wrote: Benson, Did you use Maven 3 to deploy the site? I recommend using Maven 2 for site deployment until we get maven-site-plugin 3.0-beta-4 released. On 2011-06-19 19:00, Karl Heinz Marbaise wrote: Hi, i've checked the web site and found that the link (http://maven.apache.org/plugins/maven-changes-plugin-2.6/index.html) to the changes.xsd file does not work... Furthermore the link Cobertura Test Coverage links to the index.html page...and not to a cobertura test coverage... And a question about the the homepage link on the http://maven.apache.org/plugins/maven-changes-plugin-2.6/project-summary.html Shouldn't that a be a different location than so many ../../.. why no simple http://maven.apache.org/plugins/maven-changes-plugin/; ? Kind regards Karl Heinz Marbaise -- Dennis Lundberg - 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: The JIRA chocolate box
labels seems reasonable, assuming that Codehaus deploys them. Given the positive response to this idea, I plan to send the email tomorrow some time and start on MNG. On Sun, Jun 19, 2011 at 3:24 PM, Daniel Kulp dk...@apache.org wrote: On Sunday, June 19, 2011 7:13:11 PM Dennis Lundberg wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. For CXF, we have a special NeedMoreInfo version that we use for this. We set the FixFor version to that when we've added a comment that requires more information from the user. We can easily get a list of all the issues that require more information, when we asked for it, etc. Probably an abuse of the version field though. :-) Dan K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connollystephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. -- --- 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend -
Re: The JIRA chocolate box
as far as I know ben made you me and brett admins... but that might be for maven stuff only... I can always bash ben on the head if we want to ;-) (our at least ask someone to bash ben on the head) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 19:53, Arnaud Héritier aherit...@gmail.com wrote: Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org)
Convoluted jiras
Since my lame attempt at humor on the last thread led to some confusion, I'll keep this relatively straight. Consider, if you please, http://jira.codehaus.org/browse/MNG-2258. For one thing, this report is marked as 'superceded by' another, but it's still open. What's that mean? For another, it wends it ways through various topics, ending up with a supposition that the OP's original problem might have, in fact, been a result of a more-or-less by design behavior. At least, a behavior with the possibility of causing havoc if lightly changed. Personally, I don't find this sort of thing helpful. I would give it the same treatment as discussed in the other thread. Either there's a concrete unwanted behavior, with a test case, or not. If there is, we should endeavor to resolve it in a comprehensible way. Other opinions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
Yes I am admin on the codehaus instance thus technically it is possible for now. It will be perhaps less easy when we'll be @ Apache. Arnaud On Sun, Jun 19, 2011 at 9:28 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: as far as I know ben made you me and brett admins... but that might be for maven stuff only... I can always bash ben on the head if we want to ;-) (our at least ask someone to bash ben on the head) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 19:53, Arnaud Héritier aherit...@gmail.com wrote: Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org : +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. - To unsubscribe,
Re: The JIRA chocolate box
yes label are available @ Codehaus Arnaud On Sun, Jun 19, 2011 at 9:26 PM, Benson Margulies bimargul...@gmail.comwrote: labels seems reasonable, assuming that Codehaus deploys them. Given the positive response to this idea, I plan to send the email tomorrow some time and start on MNG. On Sun, Jun 19, 2011 at 3:24 PM, Daniel Kulp dk...@apache.org wrote: On Sunday, June 19, 2011 7:13:11 PM Dennis Lundberg wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. For CXF, we have a special NeedMoreInfo version that we use for this. We set the FixFor version to that when we've added a comment that requires more information from the user. We can easily get a list of all the issues that require more information, when we asked for it, etc. Probably an abuse of the version field though. :-) Dan K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org : +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connollystephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. -- --- 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
We're good here. I just added the label maven-messy to http://jira.codehaus.org/browse/MNG-2258 as an experiment. I suggest that we use a specific label for the backlog, so: Old report, no test case: maven-backlog-cleanup New report, no testcase: maven-needs-testcase Has a patch (this works better than the checkbox) maven-patch-available Needs design attention and not just a bug fix: maven-design On Sun, Jun 19, 2011 at 3:28 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: as far as I know ben made you me and brett admins... but that might be for maven stuff only... I can always bash ben on the head if we want to ;-) (our at least ask someone to bash ben on the head) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 19:53, Arnaud Héritier aherit...@gmail.com wrote: Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct
Re: The JIRA chocolate box
All committers will have access to 'edit' issues at Apache, and that's all you need to work with labels. 2011/6/19 Arnaud Héritier aherit...@gmail.com: Yes I am admin on the codehaus instance thus technically it is possible for now. It will be perhaps less easy when we'll be @ Apache. Arnaud On Sun, Jun 19, 2011 at 9:28 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: as far as I know ben made you me and brett admins... but that might be for maven stuff only... I can always bash ben on the head if we want to ;-) (our at least ask someone to bash ben on the head) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 19:53, Arnaud Héritier aherit...@gmail.com wrote: Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org : +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical
Re: The JIRA chocolate box
It was about to (re-)define the workflow which requires full jira admin Arnaud On Sun, Jun 19, 2011 at 9:35 PM, Benson Margulies bimargul...@gmail.comwrote: All committers will have access to 'edit' issues at Apache, and that's all you need to work with labels. 2011/6/19 Arnaud Héritier aherit...@gmail.com: Yes I am admin on the codehaus instance thus technically it is possible for now. It will be perhaps less easy when we'll be @ Apache. Arnaud On Sun, Jun 19, 2011 at 9:28 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: as far as I know ben made you me and brett admins... but that might be for maven stuff only... I can always bash ben on the head if we want to ;-) (our at least ask someone to bash ben on the head) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 19:53, Arnaud Héritier aherit...@gmail.com wrote: Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org : +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5
Re: The JIRA chocolate box
Yes, indeed. 2011/6/19 Arnaud Héritier aherit...@gmail.com: It was about to (re-)define the workflow which requires full jira admin Arnaud On Sun, Jun 19, 2011 at 9:35 PM, Benson Margulies bimargul...@gmail.comwrote: All committers will have access to 'edit' issues at Apache, and that's all you need to work with labels. 2011/6/19 Arnaud Héritier aherit...@gmail.com: Yes I am admin on the codehaus instance thus technically it is possible for now. It will be perhaps less easy when we'll be @ Apache. Arnaud On Sun, Jun 19, 2011 at 9:28 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: as far as I know ben made you me and brett admins... but that might be for maven stuff only... I can always bash ben on the head if we want to ;-) (our at least ask someone to bash ben on the head) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 19:53, Arnaud Héritier aherit...@gmail.com wrote: Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org : +1 Great idea! On 6/18/11 10:22 PM, Benson Margulies wrote: If no one objects to this idea, I'd like to add a component, which is an email like the following to the user list. --snip-- Dear Maven Users, Over the years, the JIRA for core Maven (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved issues. All this clutter makes it difficult to tell where the real problems are. Further, many of these issues do not contain self-contained test cases. Practically speaking, it is very difficult to diagnose and resolve a problem without a test case 'on the bench.' We developers would like to turn over a bit of a new leaf. We're going to ask you to supply a test case to go with your bug reports. In return, we're going to try very hard to attend to them. You can tar it up and attach it to the jira, or just push it to github and add a link. To clean up the current mess, we plan to start going through the backlog. We'll add comments asking for test cases or other followup. If we don't hear back in two weeks, we're going to close. We're sorry for any frustration felt by the originators of long-neglected reports, but we believe that this process will help us be more responsive in the future. --snip-- On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: they can always reopen if they want after the issue has been closed if the 2nd weeks was too short - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 00:20, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +50 I say lets give each issue a ping, wait 2 weeks and close if no response - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Jun 2011 23:30, Benson Marguliesbimargul...@gmail.com wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. What's the policy? My temptation would be to comment on
Re: [VOTE take 2]: release maven-changes-plugin version 2.6
On 2011-06-19 19:42, Benson Margulies wrote: 1) yes. WHen I use 2 I got stumped on authentication in the deploy. 2) I can redeploy. Little did I know. I don't see any reason to rewind the vote. I'll redeploy. Me neither. A redeploy will do nicely, thanks. I'll try to review tomorrow. On Sun, Jun 19, 2011 at 1:15 PM, Dennis Lundberg denn...@apache.org wrote: Benson, Did you use Maven 3 to deploy the site? I recommend using Maven 2 for site deployment until we get maven-site-plugin 3.0-beta-4 released. On 2011-06-19 19:00, Karl Heinz Marbaise wrote: Hi, i've checked the web site and found that the link (http://maven.apache.org/plugins/maven-changes-plugin-2.6/index.html) to the changes.xsd file does not work... Furthermore the link Cobertura Test Coverage links to the index.html page...and not to a cobertura test coverage... And a question about the the homepage link on the http://maven.apache.org/plugins/maven-changes-plugin-2.6/project-summary.html Shouldn't that a be a different location than so many ../../.. why no simple http://maven.apache.org/plugins/maven-changes-plugin/; ? Kind regards Karl Heinz Marbaise -- Dennis Lundberg - 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 -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Kristian Rosenvold [mailto:kristian.rosenv...@gmail.com] Sent: Sunday, 19 June 2011 7:50 PM To: 'Maven Developers List' Subject: RE: [VOTE]: release maven-changes-plugin 2.6 Dont know if we're looking at the same jira; I see 10 issues being resolved. Probably not, I'm looking at the link that Benson gave: http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 and combining that with the words: We solved 3 issues: I think you are looking in the wrong place. +1 binding Given the amount of *work* staging a release is, I hardly doubt anyone does a release they don't think is worth it. Compared to some other projects, not much work at all. Gav... Kristian sø., 19.06.2011 kl. 18.34 +1000, skrev Gavin McDonald: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQu ery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.ht ml Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE]: release maven-changes-plugin 2.6
-Original Message- From: Mark Derricutt [mailto:m...@talios.com] Sent: Sunday, 19 June 2011 9:37 PM To: Maven Developers List; ga...@16degrees.com.au Subject: Re: [VOTE]: release maven-changes-plugin 2.6 I'd rather see a release with 3 bug fixes if they code base is idle than see not see a release for weeks/months whilst someone waits for N more issues to be resolved. I would be happy with weeks to be honest. Then again I have been used to being around slower projects that have released only every 2 or 3 years once 1 or 2 hundred issues have been gathered into a release. And the release process itself takes weeks of work to achieve. Therefore ignore me, 3 issues seems like doing a days work, then release, then another days work, then release etc ... Gav... -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Sun, Jun 19, 2011 at 8:34 PM, Gavin McDonald ga...@16degrees.com.auwrote: -Original Message- From: Benson Margulies [mailto:bimargul...@gmail.com] Sent: Sunday, 19 June 2011 6:08 AM To: Maven Developers List; Maven Project Management Committee List Subject: [VOTE]: release maven-changes-plugin 2.6 Hi, We solved 3 issues: Really? You'd release a product after solving 3 issues? Having looked at those 3 issues I believe it can wait for more. Don’t release for the sake of releasing. Gav... +-0 non-binding http://jira.codehaus.org/browse/MCHANGES/fixforversion/17375 There are plenty of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truejqlQuery= project+%3D+MCHANGES+AND+status+%3D+Open+ORDER+BY+priority+DE SCmode=hide Staging repo: https://repository.apache.org/content/repositories/maven-024/ Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.6/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing- releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
1.5 policy
http://maven.apache.org/developers/java5.html Should we update the above? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-core tests fail when invoked via ant.
Is there a reason you can't use the build.xml we've already provided for those that need to bootstrap? Hopefully that would simplify things for you. The problem you're seeing is probably related to an incorrect definition of a META-INF/plexus/components.xml file related to that SecDispatcher component. You're probably pulling in a file you didn't intend to. Hopefully you can grep through the test resources and find the culprit. - Brett On 19/06/2011, at 4:34 PM, Kasun Gajasinghe wrote: Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. = test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/target/test-reports [junit] Running org.apache.maven.WagonSelectorTest [junit] Testsuite: org.apache.maven.WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:795) [junit] at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121) [junit] at org.apache.maven.WagonSelectorTest.setUp(WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.repository.exception.ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.components.sec.dispatcher.SecDispatcher', implementation: 'org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.repository.DefaultComponentRepository.addComponentDescriptor(DefaultComponentRepository.java:184) [junit] at org.codehaus.plexus.DefaultPlexusContainer.addComponentDescriptor(DefaultPlexusContainer.java:515) [junit] at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:738) [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779) [junit] BUILD FAILED /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/maven-build.xml:206: Test org.apache.maven.WagonSelectorTest failed = Any clues on getting rid of this error? I'm thinking whether the generated build.xml has some issue. Much appreciate your help! The maven-build.xml is at [2]. The full ant output of the test failure is at [3]. I'm using maven-ant-plugin-2.3 with maven-2.2.1. The test fails with both ant 1.7.1 and 1.8.1. Please do let me know if any other information is needed. [1] https://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-core/ [2] http://pastebin.com/9eWM0xjN [3] http://pastebin.com/vRC6qVa8 Thanks, --Kasun -- ~~~***'***~~~ Kasun Gajasinghe, University of Moratuwa Blog: http://kasunbg.blogspot.com Twitter: http://twitter.com/kasunbg -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: 1.5 policy
IMO yep, no need to go through that much effort - we haven't supported running Maven on Java 1.4 in the core for quite some time now. On 20/06/2011, at 8:29 AM, Benson Margulies wrote: http://maven.apache.org/developers/java5.html Should we update the above? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
Thanks for initiating this. The cleanup is something I've worked on from time to time and each time burned out before getting to the end :) It's definitely a case of many hands make light work. At the moment, we use versions to measure triage, but labels sound like a much better alternative. I like yours, though I think backlog cleanup should apply to all issues regardless of test case / old / new / patch that we can work down to 0. You also have a gap - there's nothing to specify that it's reviewed, has sufficient information to reproduce (preferably a test case), but doesn't have a patch. How about we have 3 label states to describe triage: * no label in this group - brand new issue, needs review. We should send this list to dev@ once a week to remind us to look at them... * maven-backlog-cleanup - old issues that have not been reviewed recently * maven-triaged - new issues get this once they've been reviewed but nobody is ready to work on it yet Then the other two labels are additive to the above: * maven-needs-testcase * maven-patch-available Both are self explanatory, the first calling on the reporter to push it forward, the second calling on the committers to push it forward. What we have now: 1) 1 issue for 2.2.2 (because it's a regression on the 2.2.x branch) We can either discard the changes on the 2.2.x branch (resume from 2.2.1 if we ever need a patch release), or fix this and push 2.2.2 as the EOL version 2) 1 issue for 3.0.4 Something Hervé is working on - but in general we need a list of stuff to do for this release, if at all. 3) 42 issues for 3.1 This list is probably out of date now, but they were at least triaged. We should decide what really is going to constitute 3.1, and move the rest to the triaged area 4) 325 Issues to be reviewed for 3.x Not yet triaged issues, moved out so that new stuff coming in could be more easily identified (!). I suggest we remove this version and label them maven-backlog-cleanup 5) 30 in 3.x / Backlog Triaged issues (bearing in mind that it happened over a year ago, and so may have aged again). I suggest we remove the version and label it maven-triaged 6) 52 Documentation Deficit These would be best moved to a dedicated documentation project, or a label within MNG. We sometimes use MNG, sometimes MNGSITE - a strategy around this would be helpful. I continue to favour versioned documentation, but I know that's not everyone's preference - best leave that decision to those working on it more recently :) 7) 96 Unscheduled Not yet triaged issues. We can either keep these as new, or filter by time and put some in the cleanup bucket. Cheers, Brett On 20/06/2011, at 5:34 AM, Benson Margulies wrote: We're good here. I just added the label maven-messy to http://jira.codehaus.org/browse/MNG-2258 as an experiment. I suggest that we use a specific label for the backlog, so: Old report, no test case: maven-backlog-cleanup New report, no testcase: maven-needs-testcase Has a patch (this works better than the checkbox) maven-patch-available Needs design attention and not just a bug fix: maven-design On Sun, Jun 19, 2011 at 3:28 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: as far as I know ben made you me and brett admins... but that might be for maven stuff only... I can always bash ben on the head if we want to ;-) (our at least ask someone to bash ben on the head) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 19 Jun 2011 19:53, Arnaud Héritier aherit...@gmail.com wrote: Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention Another solution is to have a custom workflow with a default state Need Triage and additional status like Verified ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 18:46, Kristian Rosenvold wrote: Is there any smart way to tag a bug as processed in a triaging process so we can focus on the remaining bugs? I've always wondered if there's any option to tag an issue or create shared custom lists...? We should be able to use Labels for this: http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue I haven't used them myself yet, but they seem to fit the bill. K Den 19. juni 2011 kl. 18:42 skrev John Casey jdca...@commonjava.org: +1
Re: Convoluted jiras
On 20/06/2011, at 5:30 AM, Benson Margulies wrote: Since my lame attempt at humor on the last thread led to some confusion, I'll keep this relatively straight. Consider, if you please, http://jira.codehaus.org/browse/MNG-2258. For one thing, this report is marked as 'superceded by' another, but it's still open. What's that mean? That's not very helpful. I'd remove that link, or maybe make it related. For another, it wends it ways through various topics, ending up with a supposition that the OP's original problem might have, in fact, been a result of a more-or-less by design behavior. At least, a behavior with the possibility of causing havoc if lightly changed. Personally, I don't find this sort of thing helpful. I would give it the same treatment as discussed in the other thread. Either there's a concrete unwanted behavior, with a test case, or not. If there is, we should endeavor to resolve it in a comprehensible way. Other opinions? I agree with the current state - it should stay closed, and anyone that wants to report a different case can create a new issue linking back to that one. If I catch a comment on a closed issue I generally tell them to start a new one. I'll only reopen if there hasn't been a release and it can be reclosed in a reasonable time (otherwise you mess up historical release notes). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Convoluted jiras
It's closed because I, myself, closed it today :-) On Sun, Jun 19, 2011 at 8:47 PM, Brett Porter br...@apache.org wrote: On 20/06/2011, at 5:30 AM, Benson Margulies wrote: Since my lame attempt at humor on the last thread led to some confusion, I'll keep this relatively straight. Consider, if you please, http://jira.codehaus.org/browse/MNG-2258. For one thing, this report is marked as 'superceded by' another, but it's still open. What's that mean? That's not very helpful. I'd remove that link, or maybe make it related. For another, it wends it ways through various topics, ending up with a supposition that the OP's original problem might have, in fact, been a result of a more-or-less by design behavior. At least, a behavior with the possibility of causing havoc if lightly changed. Personally, I don't find this sort of thing helpful. I would give it the same treatment as discussed in the other thread. Either there's a concrete unwanted behavior, with a test case, or not. If there is, we should endeavor to resolve it in a comprehensible way. Other opinions? I agree with the current state - it should stay closed, and anyone that wants to report a different case can create a new issue linking back to that one. If I catch a comment on a closed issue I generally tell them to start a new one. I'll only reopen if there hasn't been a release and it can be reclosed in a reasonable time (otherwise you mess up historical release notes). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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: The JIRA chocolate box
There is one critical issue open only because it was never ported to 2.0.x. Presumably that also gets closed? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
Yes. On 20/06/2011, at 11:10 AM, Benson Margulies wrote: There is one critical issue open only because it was never ported to 2.0.x. Presumably that also gets closed? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: maven-core tests fail when invoked via ant.
Hi Brett, On Mon, Jun 20, 2011 at 5:41 AM, Brett Porter br...@apache.org wrote: The problem you're seeing is probably related to an incorrect definition of a META-INF/plexus/components.xml file related to that SecDispatcher component. You're probably pulling in a file you didn't intend to. Hopefully you can grep through the test resources and find the culprit. Yes, thanks. maven-core uses plexus-sec-dispatcher version 1.3, which doesn't contain a role-hint in META-INF/plexus/components.xml. So, I've updated the version to 1.4, and the test error I mentioned is gone. Well, now there's a test _failure_ (not error), in MavenCliTest, which I've identified as due to the wrong compilation version. i.e. according to maven-core pom, **/cli/*.java files should be compiled using JDK 1.4 while the rest of classes using 1.5. But apparently, the generated build.xml disregard this setting and compiles the whole bunch using 1.5. Is this a bug in the maven ant plugin or ant is incapable of handling this kind of thing? Is there a reason you can't use the build.xml we've already provided for those that need to bootstrap? Hopefully that would simplify things for you. Since we have to package the sub-modules separately, we can't use the provided build.xml. Building via mvn ant:ant too isn't a much of a problem. But these test failures is a concern. Thanks for the help! --Kasun - Brett On 19/06/2011, at 4:34 PM, Kasun Gajasinghe wrote: Hi, We are in the process of integrating Maven in to Gentoo. Currently, we are trying to bootstrap maven. Our strategy is to integrate each and every sub-project of Maven-2.2.1 [1] separately. So, we first transformed these to an ant projects by generating the build.xml via `mvn ant:ant`. I know that Maven provides a build.xml in the parent, but we have to integrate each and every project separately. We will be moving to 3.x after 2.x is complete. We chose 2.x as it's much stable, and is much popular currently. So far, we have successfully integrated project up-to maven-core in the build order. But, we are encountering an issue in maven-core. When invoked via mvn (mvn install), it passes the tests successfully (obviously!). But when I invoke the project via ant, a test fails with an ERROR. I'm sending this to the dev group thinking this error is probably obvious to you all. = test: [mkdir] Created dir: /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/target/test-reports [junit] Running org.apache.maven.WagonSelectorTest [junit] Testsuite: org.apache.maven.WagonSelectorTest [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 2.361 sec [junit] [junit] Testcase: testSelectHttpWagonFromDefault took 0.358 sec [junit] Caused an ERROR [junit] Error starting container [junit] org.codehaus.plexus.PlexusContainerException: Error starting container [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:795) [junit] at org.codehaus.plexus.PlexusTestCase.setUp(PlexusTestCase.java:121) [junit] at org.apache.maven.WagonSelectorTest.setUp(WagonSelectorTest.java:76) [junit] Caused by: org.codehaus.plexus.component.repository.exception.ComponentRepositoryException: Component descriptor role: 'org.sonatype.plexus.components.sec.dispatcher.SecDispatcher', implementation: 'org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher', role hint: 'maven' has a hint, but there are other implementations that don't [junit] at org.codehaus.plexus.component.repository.DefaultComponentRepository.addComponentDescriptor(DefaultComponentRepository.java:184) [junit] at org.codehaus.plexus.DefaultPlexusContainer.addComponentDescriptor(DefaultPlexusContainer.java:515) [junit] at org.codehaus.plexus.DefaultPlexusContainer.discoverComponents(DefaultPlexusContainer.java:738) [junit] at org.codehaus.plexus.DefaultPlexusContainer.start(DefaultPlexusContainer.java:779) [junit] BUILD FAILED /gentoo-sources/maven/maven-2/tags/maven-2.2.1/maven-core-2.2.1/maven-build.xml:206: Test org.apache.maven.WagonSelectorTest failed = Any clues on getting rid of this error? I'm thinking whether the generated build.xml has some issue. Much appreciate your help! The maven-build.xml is at [2]. The full ant output of the test failure is at [3]. I'm using maven-ant-plugin-2.3 with maven-2.2.1. The test fails with both ant 1.7.1 and 1.8.1. Please do let me know if any other information is needed. [1] https://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-core/ [2] http://pastebin.com/9eWM0xjN [3] http://pastebin.com/vRC6qVa8 Thanks, --Kasun --
