[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-pmc] Platform Runtime modification requests

Hi Dirk

The -1 was for the major version increase.

> 1. Memory leak in ExtendedObjectSupplier

> I proposed a patch via Gerrit. But it introduces the sending of an event on
> dispose and the existing ExtendedObjectSupplier will need to additionally


I assume this is to do the clean-up, i.e. if they do nothing, nothing will happen beyond the leak we have today. In that case +1 for this.


 > 2. Publish org.eclipse.e4.core.di.extensions annotations

I'd defer this to 4.8 unless there is a major issue doing so. Even in Photon (4.8) we would not increase the major version. It was a mistake in the first place to start with 0.*. The change only adds new APIs, hence not mandating a major version increase.


> 3. Deprecate MessageXxx functional interfaces

+1 to deprecate them now and follow the instructions in https://wiki.eclipse.org/Eclipse/API_Central/API_Removal_Process.


Dani



From:        Dirk Fauth <dirk.fauth@xxxxxxxxx>
To:        eclipse-pmc@xxxxxxxxxxx
Date:        21.03.2017 14:50
Subject:        Re: [eclipse-pmc] Platform Runtime modification requests
Sent by:        eclipse-pmc-bounces@xxxxxxxxxxx




Which topic is a -1? I understand it for the publishing of the annotations. But what about the minor version increase for the context disposal? 

Am 21.03.2017 2:47 PM schrieb "Daniel Megert" <daniel_megert@xxxxxxxxxx>:
Lars,

I already replied that we will discuss this in the next PMC call since it is a major version increase. I also already gave a potential -1 for Oxygen.


I doubt we have quorum in today's call due to absences.


Dani




From:        
Lars Vogel <lars.vogel@xxxxxxxxxxx>
To:        
eclipse-pmc@xxxxxxxxxxx
Date:        
21.03.2017 14:22
Subject:        
Re: [eclipse-pmc] Platform Runtime modification requests
Sent by:        
eclipse-pmc-bounces@xxxxxxxxxxx




Hi Dirk,

IIRC our PMC rule is that if you do not get a negativ reply within 7
days, the request gets automatically approved. I suggest to wait 1-2
days to give the other PMC members to react to this request and
afterwards continue with the change.

Best regards, Lars

On Tue, Mar 14, 2017 at 9:13 PM, Dirk Fauth <
dirk.fauth@xxxxxxxxx> wrote:
> Dear PMC,
>
> I would like to perform some actions for which I think I need your approval.
>
> 1. Memory leak in ExtendedObjectSupplier
>
> We got a bug report about a memory leak within several
> ExtendedObjectSupplier (although just reported for the
> TranslationObjectSupplier).
>
>
https://bugs.eclipse.org/bugs/show_bug.cgi?id=513377
>
> The main reason is that for supporting re-injection the IRequestor are
> cached in the supplier implementations. But the framework does not provide
> methods for cleaning up if those IRequestor are discarded.
>
> One part of the solution would be to inform the ExtendedObjectSupplier if an
> EclipseContext is disposed. Since there is no API for that I would suggest
> to make use of the EventAdmin to send an asynchronous event that can be used
> to inform OSGi services like ExtendedObjectSupplier that they should cleanup
> their caches.
>
> I proposed a patch via Gerrit. But it introduces the sending of an event on
> dispose and the existing ExtendedObjectSupplier will need to additionally
> implement the EventHandler interface. It is not marked as an API breakage
> (and I even don't think it is one), but I wanted to get feedback on this
> before merging it.
>
> Also note that this is probably not the complete solution, as there might be
> still IRequestor that are created and discarded for one EclipseContext that
> is not disposed. But the only idea we had to solve this was to introduce
> cleanup threads that periodically try to cleanup IRequestor. But I don't
> want to introduce that now because of possible performance leaks.
>
> 2. Publish org.eclipse.e4.core.di.extensions annotations
>
> I would like to publish the annotations in
> org.eclipse.e4.core.di.extensions. Most of them are pretty mature and used
> the way they are for several years. I would like to remove the x-friends
> directive to make it public API. As this would also change the major version
> of the bundle to 1.0.0 your approval is needed.
>
> 3. Deprecate MessageXxx functional interfaces
>
> I introduced some MessageXxx functional interfaces once the bundle
> o.e.e4.core.services required Java 7. Now that we require Java 8 these
> interfaces could be replaced with the Java 8 interfaces. Such a change
> should not even be noticable by users. As I learned we first need to mark
> the interfaces as deprecated so they can be removed in the future.
>
> Please give me some feedback so I know if and how I can proceed.
>
> Greez,
> Dirk
>
> _______________________________________________
> eclipse-pmc mailing list
>
eclipse-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
>
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc



--
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax
(040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com
_______________________________________________
eclipse-pmc mailing list

eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/eclipse-pmc



_______________________________________________
eclipse-pmc mailing list

eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

https://dev.eclipse.org/mailman/listinfo/eclipse-pmc_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc