[groovy-dev] Eclipse JIRA Dashboard plugin

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[groovy-dev] Eclipse JIRA Dashboard plugin

Guillaume Laforge
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
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Eclipse JIRA Dashboard plugin

Christian Stein
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
Reply | Threaded
Open this post in threaded view
|

RE: [groovy-dev] Eclipse JIRA Dashboard plugin

Dierk König
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
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Eclipse JIRA Dashboard plugin

Christian Stein
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=
Reply | Threaded
Open this post in threaded view
|

[groovy-dev] Jira issue workflow

Dierk König
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
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Jira issue workflow

tugwilson

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


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Jira issue workflow

Guillaume Laforge
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
Reply | Threaded
Open this post in threaded view
|

[groovy-dev] equals on Lists and arrays

Dierk König
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


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] equals on Lists and arrays

Jochen Theodorou
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
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] equals on Lists and arrays

tugwilson
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


123