Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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




_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gef-dev


-- 
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


Back to the top