RE: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Hi Anthony, Thanks for sending a request for applying the multi-threaded plug-in. As for the email plug-in mentioned below, using it does not mean sending all JIRA's automatically to a single mailing list.. On the contrary it can be used as a selective tool for sharing selective JIRAs to selective people/groups. This might be handy in case an issue was previously discussed in JIRA and at a point you want to share with specific recipients. Anyway if the current watch list mechanism functionality suffices that's it's fine with me.. :) Regards, Seeon -Original Message- From: Anthony Petrov Sent: Friday, January 24, 2014 1:07 PM To: Seeon Birger; Steve Northover Cc: John Hendrikx; openjfx-dev@openjdk.java.net Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method] Hi Seeon, I don't think that posting updates from all our JIRAs to a single mailing list is a good idea because the messages traffic would be huge. Each JIRA provides a watch list, so people can follow specific bugs that they're interested in. I believe that this functionality is sufficient for all reasonable purposes. However, your suggestion about using threaded comments sounds interesting. We've sent a request to our Infrastructure team to evaluate the plugin and consider adding it to our JIRA instance. Note that this is not going to happen overnight and could take some time, but the request is filed at least. Thanks for the suggestion! -- best regards, Anthony On 1/23/2014 9:09 PM, Seeon Birger wrote: > Steve, > > I wonder if we could take advantage of available plug-ins for JIRA. > > I particular I found this one which enables threaded comments for JIRA: > https://marketplace.atlassian.com/plugins/com.atlassian.jira.threadedc > omments.threaded-comments > > Also interesting is the following which make it easy to put JIRA updates on > mailing lists in a flexible and customizable way: > https://marketplace.atlassian.com/plugins/com.metainf.jira.plugin.emai > lissue > > What do you think? > > Seeon > > > > -Original Message- > From: Stephen F Northover > Sent: Thursday, January 23, 2014 12:45 AM > To: John Hendrikx; openjfx-dev@openjdk.java.net > Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, > ObservableValue should have a hasListener(listener) method] > > Hi John, > > The goal is not to end the discussion! > > It's a trade off. Mailing lists are good because they provide a threaded > discussion. JIRA is bad because it is not threaded. JIRA has the advantage > that it captures data in a single place and provides a good history of why a > decision was made. > > There's no right answer here but the policy that the FX committers is using > is to try to capture as much as possible in JIRA. > > Steve > > On 2014-01-22 5:29 PM, John Hendrikx wrote: >> Unfortunately, "discussing" things in JIRA works very poorly and is a >> good way to end a productive discussion IMHO. Mailinglists are much >> better suited to the task, as thousands of interesting mailinglists >> accross many developer communities will atest to. >> >> Keeping a record is good, aren't these mailinglists archived? >> >> --John >> >> On 22/01/2014 18:47, Daniel Blaukopf wrote: >>> Hi Martin, Randahl, Tom, Richard, Tomas and Ali, >>> >>> This is a productive discussion, but once we get to this level of >>> detail JIRA is the place to have it, so that we don't lose our >>> record of it. Would you continue the discussion on >>> https://javafx-jira.kenai.com/browse/RT-25613 ? >>> >>> See >>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeRevie >>> w s-TechnicalDiscussionsandCodeReviews >>> >>> Thanks, >>> Daniel >>> >>> On Jan 22, 2014, at 7:23 PM, Stephen F >>> Northover wrote: >>> >>>> If we add this API, I like addListener(InvalidationListener, >>>> boolean) better than ensureListener(). >>>> >>>> Steve >>>> >>>> On 2014-01-22 8:20 AM, Ali Ebrahimi wrote: >>>>> I suggest adding another overload for addListener method taking >>>>> boolean parameter "duplicateAllowed" or "duplicateNotAllowed". >>>>> >>>>> >>>>> On Wed, Jan 22, 2014 at 3:00 PM, Richard >>>>> Bairwrote: >>>>> >>>>>>>> The default implementation (for Observable) would look like this: >>>>>>>> >>>>>>>> public def
Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Hi Seeon,
I don't think that posting updates from all our JIRAs to a single
mailing list is a good idea because the messages traffic would be huge.
Each JIRA provides a watch list, so people can follow specific bugs that
they're interested in. I believe that this functionality is sufficient
for all reasonable purposes.
However, your suggestion about using threaded comments sounds
interesting. We've sent a request to our Infrastructure team to evaluate
the plugin and consider adding it to our JIRA instance. Note that this
is not going to happen overnight and could take some time, but the
request is filed at least. Thanks for the suggestion!
--
best regards,
Anthony
On 1/23/2014 9:09 PM, Seeon Birger wrote:
Steve,
I wonder if we could take advantage of available plug-ins for JIRA.
I particular I found this one which enables threaded comments for JIRA:
https://marketplace.atlassian.com/plugins/com.atlassian.jira.threadedcomments.threaded-comments
Also interesting is the following which make it easy to put JIRA updates on
mailing lists in a flexible and customizable way:
https://marketplace.atlassian.com/plugins/com.metainf.jira.plugin.emailissue
What do you think?
Seeon
-Original Message-
From: Stephen F Northover
Sent: Thursday, January 23, 2014 12:45 AM
To: John Hendrikx; openjfx-dev@openjdk.java.net
Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue
should have a hasListener(listener) method]
Hi John,
The goal is not to end the discussion!
It's a trade off. Mailing lists are good because they provide a threaded
discussion. JIRA is bad because it is not threaded. JIRA has the advantage
that it captures data in a single place and provides a good history of why a
decision was made.
There's no right answer here but the policy that the FX committers is using is
to try to capture as much as possible in JIRA.
Steve
On 2014-01-22 5:29 PM, John Hendrikx wrote:
Unfortunately, "discussing" things in JIRA works very poorly and is a
good way to end a productive discussion IMHO. Mailinglists are much
better suited to the task, as thousands of interesting mailinglists
accross many developer communities will atest to.
Keeping a record is good, aren't these mailinglists archived?
--John
On 22/01/2014 18:47, Daniel Blaukopf wrote:
Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
This is a productive discussion, but once we get to this level of
detail JIRA is the place to have it, so that we don't lose our record
of it. Would you continue the discussion on
https://javafx-jira.kenai.com/browse/RT-25613 ?
See
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReview
s-TechnicalDiscussionsandCodeReviews
Thanks,
Daniel
On Jan 22, 2014, at 7:23 PM, Stephen F
Northover wrote:
If we add this API, I like addListener(InvalidationListener,
boolean) better than ensureListener().
Steve
On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
I suggest adding another overload for addListener method taking
boolean parameter "duplicateAllowed" or "duplicateNotAllowed".
On Wed, Jan 22, 2014 at 3:00 PM, Richard
Bairwrote:
The default implementation (for Observable) would look like this:
public default void ensureListener(InvalidationListener listener) {
removeListener(listener);
addListener(listener);
}
subclasses might do something more effective. The same would
apply to
ObservableValue and ChangeListener and Observable[List|Set|Map] and
[List|Set|Map]ChangeListener.
Well this would destroy the order! I expect listeners to be
called in
the correct order not?
That's a good point :-(
Why doing a remove and not simply check if the
listener has already been added?
Because there is no way to check, except in the implementation.
From the
Observable interface level, there is no way to a) force all
implementations
of the interface to implement the method correctly (without
breaking source
compatibility anyway), or b) to provide a reasonable default
implementation.
Maybe this is one of those things we can't fix on the Observable
interface
and just have to provide implementations of on our concrete
properties.
Richard
RE: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Steve,
I wonder if we could take advantage of available plug-ins for JIRA.
I particular I found this one which enables threaded comments for JIRA:
https://marketplace.atlassian.com/plugins/com.atlassian.jira.threadedcomments.threaded-comments
Also interesting is the following which make it easy to put JIRA updates on
mailing lists in a flexible and customizable way:
https://marketplace.atlassian.com/plugins/com.metainf.jira.plugin.emailissue
What do you think?
Seeon
-Original Message-
From: Stephen F Northover
Sent: Thursday, January 23, 2014 12:45 AM
To: John Hendrikx; openjfx-dev@openjdk.java.net
Subject: Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue
should have a hasListener(listener) method]
Hi John,
The goal is not to end the discussion!
It's a trade off. Mailing lists are good because they provide a threaded
discussion. JIRA is bad because it is not threaded. JIRA has the advantage
that it captures data in a single place and provides a good history of why a
decision was made.
There's no right answer here but the policy that the FX committers is using is
to try to capture as much as possible in JIRA.
Steve
On 2014-01-22 5:29 PM, John Hendrikx wrote:
> Unfortunately, "discussing" things in JIRA works very poorly and is a
> good way to end a productive discussion IMHO. Mailinglists are much
> better suited to the task, as thousands of interesting mailinglists
> accross many developer communities will atest to.
>
> Keeping a record is good, aren't these mailinglists archived?
>
> --John
>
> On 22/01/2014 18:47, Daniel Blaukopf wrote:
>> Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
>>
>> This is a productive discussion, but once we get to this level of
>> detail JIRA is the place to have it, so that we don't lose our record
>> of it. Would you continue the discussion on
>> https://javafx-jira.kenai.com/browse/RT-25613 ?
>>
>> See
>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReview
>> s-TechnicalDiscussionsandCodeReviews
>>
>> Thanks,
>> Daniel
>>
>> On Jan 22, 2014, at 7:23 PM, Stephen F
>> Northover wrote:
>>
>>> If we add this API, I like addListener(InvalidationListener,
>>> boolean) better than ensureListener().
>>>
>>> Steve
>>>
>>> On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
>>>> I suggest adding another overload for addListener method taking
>>>> boolean parameter "duplicateAllowed" or "duplicateNotAllowed".
>>>>
>>>>
>>>> On Wed, Jan 22, 2014 at 3:00 PM, Richard
>>>> Bairwrote:
>>>>
>>>>>>> The default implementation (for Observable) would look like this:
>>>>>>>
>>>>>>> public default void ensureListener(InvalidationListener listener) {
>>>>>>> removeListener(listener);
>>>>>>> addListener(listener);
>>>>>>> }
>>>>>>>
>>>>>>> subclasses might do something more effective. The same would
>>>>>>> apply to
>>>>>>> ObservableValue and ChangeListener and Observable[List|Set|Map] and
>>>>>>> [List|Set|Map]ChangeListener.
>>>>>> Well this would destroy the order! I expect listeners to be
>>>>>> called in
>>>>>> the correct order not?
>>>>> That's a good point :-(
>>>>>
>>>>>> Why doing a remove and not simply check if the
>>>>>> listener has already been added?
>>>>> Because there is no way to check, except in the implementation.
>>>>> From the
>>>>> Observable interface level, there is no way to a) force all
>>>>> implementations
>>>>> of the interface to implement the method correctly (without
>>>>> breaking source
>>>>> compatibility anyway), or b) to provide a reasonable default
>>>>> implementation.
>>>>>
>>>>> Maybe this is one of those things we can't fix on the Observable
>>>>> interface
>>>>> and just have to provide implementations of on our concrete
>>>>> properties.
>>>>>
>>>>> Richard
>
Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Hi John,
The goal is not to end the discussion!
It's a trade off. Mailing lists are good because they provide a
threaded discussion. JIRA is bad because it is not threaded. JIRA has
the advantage that it captures data in a single place and provides a
good history of why a decision was made.
There's no right answer here but the policy that the FX committers is
using is to try to capture as much as possible in JIRA.
Steve
On 2014-01-22 5:29 PM, John Hendrikx wrote:
Unfortunately, "discussing" things in JIRA works very poorly and is a
good way to end a productive discussion IMHO. Mailinglists are much
better suited to the task, as thousands of interesting mailinglists
accross many developer communities will atest to.
Keeping a record is good, aren't these mailinglists archived?
--John
On 22/01/2014 18:47, Daniel Blaukopf wrote:
Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
This is a productive discussion, but once we get to this level of
detail JIRA is the place to have it, so that we don’t lose our record
of it. Would you continue the discussion on
https://javafx-jira.kenai.com/browse/RT-25613 ?
See
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReviews-TechnicalDiscussionsandCodeReviews
Thanks,
Daniel
On Jan 22, 2014, at 7:23 PM, Stephen F
Northover wrote:
If we add this API, I like addListener(InvalidationListener,
boolean) better than ensureListener().
Steve
On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
I suggest adding another overload for addListener method taking
boolean
parameter "duplicateAllowed" or "duplicateNotAllowed".
On Wed, Jan 22, 2014 at 3:00 PM, Richard
Bairwrote:
The default implementation (for Observable) would look like this:
public default void ensureListener(InvalidationListener listener) {
removeListener(listener);
addListener(listener);
}
subclasses might do something more effective. The same would
apply to
ObservableValue and ChangeListener and Observable[List|Set|Map] and
[List|Set|Map]ChangeListener.
Well this would destroy the order! I expect listeners to be
called in
the correct order not?
That’s a good point :-(
Why doing a remove and not simply check if the
listener has already been added?
Because there is no way to check, except in the implementation.
From the
Observable interface level, there is no way to a) force all
implementations
of the interface to implement the method correctly (without
breaking source
compatibility anyway), or b) to provide a reasonable default
implementation.
Maybe this is one of those things we can’t fix on the Observable
interface
and just have to provide implementations of on our concrete
properties.
Richard
Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
The point is that we'd rather have quick reference to the historical
discussion without having to cross-reference between jira and the
mailing list archives (which isn't automatically done). Once you add
yourself as a watcher to the jira issue you are notified of every
change, in much the same way as you are emailed of the discussion on
this mailing list.
A good case in point came up just today with Martin referencing
historical choices made with the Observable API, but not being able to
reference them as they are not recorded anywhere (and if they are, being
able to search for them is not trivial - the only hope is to find them
in your email client and then go off to the openjfx-dev archives and
manually search through the discussions until the right thread is
found). Whilst Jira search isn't great, it is better than this!
In other words, I can see an upside without any downside. What troubles
do you have with Jira specifically?
-- Jonathan
On 23/01/2014 11:29 a.m., John Hendrikx wrote:
> Unfortunately, "discussing" things in JIRA works very poorly and is a
> good way to end a productive discussion IMHO. Mailinglists are much
> better suited to the task, as thousands of interesting mailinglists
> accross many developer communities will atest to.
>
> Keeping a record is good, aren't these mailinglists archived?
>
> --John
>
> On 22/01/2014 18:47, Daniel Blaukopf wrote:
>> Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
>>
>> This is a productive discussion, but once we get to this level of
>> detail JIRA is the place to have it, so that we don’t lose our record
>> of it. Would you continue the discussion on
>> https://javafx-jira.kenai.com/browse/RT-25613 ?
>>
>> See
>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReviews-TechnicalDiscussionsandCodeReviews
>>
>> Thanks,
>> Daniel
>>
>> On Jan 22, 2014, at 7:23 PM, Stephen F
>> Northover wrote:
>>
>>> If we add this API, I like addListener(InvalidationListener,
>>> boolean) better than ensureListener().
>>>
>>> Steve
>>>
>>> On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
I suggest adding another overload for addListener method taking
boolean
parameter "duplicateAllowed" or "duplicateNotAllowed".
On Wed, Jan 22, 2014 at 3:00 PM, Richard
Bairwrote:
>>> The default implementation (for Observable) would look like this:
>>>
>>> public default void ensureListener(InvalidationListener listener) {
>>> removeListener(listener);
>>> addListener(listener);
>>> }
>>>
>>> subclasses might do something more effective. The same would
>>> apply to
>>> ObservableValue and ChangeListener and Observable[List|Set|Map] and
>>> [List|Set|Map]ChangeListener.
>> Well this would destroy the order! I expect listeners to be
>> called in
>> the correct order not?
> That’s a good point :-(
>
>> Why doing a remove and not simply check if the
>> listener has already been added?
> Because there is no way to check, except in the implementation.
> From the
> Observable interface level, there is no way to a) force all
> implementations
> of the interface to implement the method correctly (without
> breaking source
> compatibility anyway), or b) to provide a reasonable default
> implementation.
>
> Maybe this is one of those things we can’t fix on the Observable
> interface
> and just have to provide implementations of on our concrete
> properties.
>
> Richard
>
Re: Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]
Unfortunately, "discussing" things in JIRA works very poorly and is a
good way to end a productive discussion IMHO. Mailinglists are much
better suited to the task, as thousands of interesting mailinglists
accross many developer communities will atest to.
Keeping a record is good, aren't these mailinglists archived?
--John
On 22/01/2014 18:47, Daniel Blaukopf wrote:
Hi Martin, Randahl, Tom, Richard, Tomas and Ali,
This is a productive discussion, but once we get to this level of detail JIRA
is the place to have it, so that we don’t lose our record of it. Would you
continue the discussion on https://javafx-jira.kenai.com/browse/RT-25613 ?
See
https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews#CodeReviews-TechnicalDiscussionsandCodeReviews
Thanks,
Daniel
On Jan 22, 2014, at 7:23 PM, Stephen F Northover
wrote:
If we add this API, I like addListener(InvalidationListener, boolean) better
than ensureListener().
Steve
On 2014-01-22 8:20 AM, Ali Ebrahimi wrote:
I suggest adding another overload for addListener method taking boolean
parameter "duplicateAllowed" or "duplicateNotAllowed".
On Wed, Jan 22, 2014 at 3:00 PM, Richard Bairwrote:
The default implementation (for Observable) would look like this:
public default void ensureListener(InvalidationListener listener) {
removeListener(listener);
addListener(listener);
}
subclasses might do something more effective. The same would apply to
ObservableValue and ChangeListener and Observable[List|Set|Map] and
[List|Set|Map]ChangeListener.
Well this would destroy the order! I expect listeners to be called in
the correct order not?
That’s a good point :-(
Why doing a remove and not simply check if the
listener has already been added?
Because there is no way to check, except in the implementation. From the
Observable interface level, there is no way to a) force all implementations
of the interface to implement the method correctly (without breaking source
compatibility anyway), or b) to provide a reasonable default implementation.
Maybe this is one of those things we can’t fix on the Observable interface
and just have to provide implementations of on our concrete properties.
Richard
