Administrator
|
Hi,
For those using Eclipse for developing, I noticed there's a nice plugin offering integration with JIRA: http://confluence.atlassian.com/display/JIRAEXT/JIRA+Dashboard+for+Eclipse It might be interesting to see if it's working fine with Codehaus' JIRA instance and our project. -- Guillaume Laforge http://glaforge.free.fr/blog/groovy |
Guillaume Laforge wrote:
> [...] > It might be interesting to see if it's working fine with Codehaus' > JIRA instance and our project. Nice screenshots! And having access to JIRA via the IDE, cool! On my way... the installation was easy, the login worked, but expanding the "Projects" node for all Codehaus projects seems to be to much... Eclipse's not responding anymore. :( Going to file an JIRA issue against that JIRA-plugin. (: Cheers, Christian |
I tried the IDEA Jira Plugin.
When using with Codehaus, it brings the list of projects correctly, but when fetching the issues it says: "earlier than 2.6 or RPC disabled" :-( ciao Mittie > -----Original Message----- > From: Christian Stein [mailto:[hidden email]] > Sent: Dienstag, 15. November 2005 10:22 > To: [hidden email] > Subject: Re: [groovy-dev] Eclipse JIRA Dashboard plugin > > > Guillaume Laforge wrote: > > [...] > > It might be interesting to see if it's working fine with Codehaus' > > JIRA instance and our project. > > Nice screenshots! And having access to JIRA via the IDE, cool! > > On my way... the installation was easy, the login worked, but expanding > the "Projects" node for all Codehaus projects seems to be to much... > > Eclipse's not responding anymore. :( > > Going to file an JIRA issue against that JIRA-plugin. (: > > Cheers, > Christian |
Dierk Koenig wrote:
> I tried the IDEA Jira Plugin. > When using with Codehaus, it brings the list of projects > correctly, but when fetching the issues it says: > "earlier than 2.6 or RPC disabled" :-( It worked here now. After 10 minutes all projects are shown and the issues as well. I'm just trying to resolve GROOVY-834 via Eclipse now. C= |
hiall,
I'm a bit confused about the issue workflow in Jira. What's the purpose of having two states 'resolved' and 'closed'? a) In some projects I have seen it such that there is only one state 'closed' when the implementor thinks he's finished. b) In other projects, the implementor only 'resolves' the issue and leave it to the reporter to 'close' it if it is finished by his measure. Which of the two approaches is supposed for Groovy? If a) a Jira admin should change the workflow. (can be done online) If b) we should distribute that rule more prominently and change our habits accordingly. BTW: I'm fine with both approaches, but want to know. cheers Mittie |
On 15 Nov 2005, at 13:30, Dierk Koenig wrote: > hiall, > > I'm a bit confused about the issue workflow in Jira. > What's the purpose of having two states 'resolved' and > 'closed'? > > a) In some projects I have seen it such that there is only > one state 'closed' when the implementor thinks he's > finished. > > b) In other projects, the implementor only 'resolves' the > issue and leave it to the reporter to 'close' it if > it is finished by his measure. > > Which of the two approaches is supposed for Groovy? > > If a) a Jira admin should change the workflow. > (can be done online) > If b) we should distribute that rule more prominently > and change our habits accordingly. > > BTW: I'm fine with both approaches, but want to know. I used just to resolve it but i was then asked to close it too (by MrG, I think). I'm happy with either too and agree that it should be clarified. If the workflow =can be approved all the better:) John Wilson The Wilson Partnership http://www.wilson.co.uk |
Administrator
|
In reply to this post by Dierk König
Hello Dierk,
On 15/11/05, Dierk Koenig <[hidden email]> wrote: > I'm a bit confused about the issue workflow in Jira. > What's the purpose of having two states 'resolved' and > 'closed'? > > a) In some projects I have seen it such that there is only > one state 'closed' when the implementor thinks he's > finished. > > b) In other projects, the implementor only 'resolves' the > issue and leave it to the reporter to 'close' it if > it is finished by his measure. > > Which of the two approaches is supposed for Groovy? > > If a) a Jira admin should change the workflow. > (can be done online) > If b) we should distribute that rule more prominently > and change our habits accordingly. > > BTW: I'm fine with both approaches, but want to know. Resolved / closed is a default setting in JIRA I think. Or at least, that's the scheme we've always had, AFAIK. When we're sure an issue is *really* fixed (and that their are test cases demonstrating that), an issue must be "closed". Otherwise, if we wish a user / reporter to check the bug is really fixed or the feature implemented correctly, "resolved" can be used. Then, if the user / reporter says it's okay, we can close it. So most of the time "closed" is good enough for our workflow, but on some occasions, it's handy to have "resolved", so that someone confirms the bug or feature is fixed or implemented correctly. -- Guillaume Laforge http://glaforge.free.fr/blog/groovy |
In reply to this post by Dierk König
Hi,
I'd like to place for discussion whether 'equals' should work on arrays like on Lists. see also http://jira.codehaus.org/browse/GROOVY-1130 Currently we have this: - java.util.List#equals has a special impl. in the DGM: ---- public static boolean equals(List left, List right) { if (left == null && right == null) return true; else if (left == null && right != null) return false; else if (left != null && right == null) return false; else if (left.size() != right.size()) return false; NumberComparator numberComparator = new NumberComparator(); Iterator it1 = left.iterator(), it2 = right.iterator(); for (; it1.hasNext() && it2.hasNext(); ) { Object o1 = it1.next(); Object o2 = it2.next(); if (Number.class.isInstance(o1) && Number.class.isInstance(o2)) { if (numberComparator.compare(o1, o2) != 0) return false; } else { if (o1 == null) { if (o1 != null) return false; } else if (!o1.equals(o2)) return false; } } if (it1.hasNext() || it2.hasNext()) return false; return true; } ---- - arrays of java primitives used with equals fall through to identity check (like in Java) - arrays of objects are also compared by indentity Since arrays and Lists are often used in a Groovy codebase interchangeably, the following is surprising: String[] a = new String[1] String[] b = new String[1] a[0] = 'x' b[0] = 'x' assert a != b assert a.toList() == b.toList() suggestions? cheers Mittie |
Dierk Koenig schrieb:
[...] > Since arrays and Lists are often used in a Groovy codebase > interchangeably, the following is surprising: > > String[] a = new String[1] > String[] b = new String[1] > a[0] = 'x' > b[0] = 'x' > assert a != b > assert a.toList() == b.toList() I think the beahviour for array should be changed. bye blackdrag |
In reply to this post by Dierk König
On 15 Nov 2005, at 14:30, Dierk Koenig wrote: > if (o1 == null) { > if (o1 != null) > return false; > } I don't understand this, I think it's a typo. did you mean the first test to be o2 == null? John Wilson The Wilson Partnership http://www.wilson.co.uk |
Free forum by Nabble | Edit this page |