Move to JIRA [was: Re: [8u] API Request: RT-25613, ObservableValue should have a hasListener(listener) method]

[Anthony Petrov]

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 at 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<steve.x.northover at oracle.com>  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
>>>>> Bair<richard.bair at oracle.com>wrote:
>>>>>
>>>>>>>> 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
>>
>