| Re: [gef-dev] GEF4 - Mars release planning |
|
Hi all,
I would like to clean-up the Zest.FX prototype (create a tests plugin, enhance javadoc, etc.) before we get into a closer discussion. Moreover, I analyzed the current usage of the layout interfaces from the layout algorithms to identify algorithm parameters. You can find my findings at the corresponding bug ticket [1] where we can continue the discussion. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=372365 Best regards, Matthias Am 25.06.2014 16:28, schrieb Alexander Nyßen: Hi team, while the team call planning is on its way, there is something else I would like to discuss: we have all stated our intention to contribute a first snapshot of GEF4 to Mars, so now actually is the time to start planning :-). In detail, there are two things I would like to clarify on the short term (if somebody has additional points, please speak up): 1) As I understood, our shared intention is to release this first snapshot with only provisional API. Therefore, I have read through all the API-guidelines I could find, and further took a look at how the e4 and p2 projects handled their provisional API. IMHO, the best solution would be to mark all our packages (that are intended to become API) as being x-internal:=true from now on (until we explicitly release something as API). Where packages are already intended to be non-API (as e.g. in the GEF4 DOT bundle), I would propose to include "internal" in the respective package name and to only expose such kind of packages with an x-friends directive (and thus only make it available where needed, e.g. for test plug-ins). I have already "prototyped" that in my local workspace; it will lead to about 12500 warnings in the code base (if the compiler preference is set to report non-API access with a WARNING), but IMHO that is the price we would have to pay if we want to be good Eclipse citizen s. 2) I think a major goal for the Mars release should be that the provided GEF4 snapshot is completely self-contained, i.e. that it does not include dependencies to GEF 3.x bundles any more. In detail, the only bundles that still need to be migrated/replaced are the Zest bundles, where Matthias has already completed a first prototype for a GEF4-MVC-based alternative (Zest.FX). Here, I would like to get into a closer discussion (maybe best by means of a second team call after the one with the KIELER guys) about: i) how appropriate we regard the chosen approach to be ii) what would have to be done in addition to replace the SWT/Draw2d-based Zest bundles II) how we could organize the work on this. Cheers Alexander -- Dr. Alexander Nyßen Dipl.-Inform. Software-Engineer Telefon: +49 (0) 231 / 98 60-210 Telefax: +49 (0) 231 / 98 60-211 Mobil: +49 (0) 151 / 17396743 http://www.itemis.de alexander.nyssen@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus -- Matthias Wienand Auszubildender Telefon: +49 231 98 60 210 Telefax: +49 231 98 60 211 http://www.itemis.de matthias.wienand@xxxxxxxxx itemis AG Am Brambusch 15-24 44536 Lünen Rechtlicher Hinweis: Amtsgericht Dortmund, HRB 20621 Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus |
Attachment:
signature.asc
Description: OpenPGP digital signature