Hi team,
If I understand correctly, Lars is willing to put his efforts into
dealing with building and releasing GEF3, and Serge and Alois are
willing to improve the codebase without breaking downstream projects.
@Zoltán Ujhelyi <mailto:zoltan.ujhelyi@xxxxxxxxxxxxxxxx> @Tamas Miklossy
<mailto:miklossy@xxxxxxxxx> @Zoey Winter @Nico Prediger
<mailto:mail@xxxxxxxxxxxxxxx> @Fabian Steeg: Would you be happy with
Lars, Alois and Serge working on GEF3? My suggestion would be to
nominate them as committers with the additional agreement to focus their
efforts on GEF3. If we later on feel the need to split GEF3 into another
Eclipse project, we should still be able to do so, right?
Best regards,
Matthias
On Mon, Feb 21, 2022 at 6:02 PM Serge Rider <serge@xxxxxxxxx
<mailto:serge@xxxxxxxxx>> wrote:
Hi Alexander,
My point is that, perhaps, somebody else could be "in charge". In
fact, I don't really know what "in charge" means if we talk about
the Eclipse project.
Maybe we don't need to transfer ownership. What we need is to have
the possibility to patch/improve GEF3.
Can it do any harm to the Eclipse community?
Thanks,
Serge Rider
On Mon, Feb 21, 2022 at 11:04 AM Alexander Nyßen <nyssen@xxxxxxxxxx
<mailto:nyssen@xxxxxxxxxx>> wrote:
Hi Serge,
there is not much to add from my side. The wish 'not to be "in
charge" (in any form)‘ IMHO is not really compatible with a 'GEF
project ownership transfer‘.
Best Regards,
Alexander
Am 18.02.2022 um 15:56 schrieb Matthias Wienand
<matthias.wienand@xxxxxxxxx <mailto:matthias.wienand@xxxxxxxxx>>:
Hi Serge,
the simple solution for allowing you to bring your changes
into GEF Legacy is to separate GEF Legacy into another Eclipse
Project. But you or someone else would have to take over
responsibility.
Best regards,
Matthias
On Fri, Feb 18, 2022 at 12:20 PM Serge Rider <serge@xxxxxxxxx
<mailto:serge@xxxxxxxxx>> wrote:
Hi Matthias, Alexander, Lars,
Honestly, I'd prefer not to be "in charge" (in any form)
for GEF legacy.
Because I am not the best expert in the Eclipse platform
ecosystem as a whole, I never participated in GEF
development in the past.
I am not even an Eclipse committer yet, but I could try to
become one.
I (together with DBeaver team) would be happy to propose
PRs with bug fixes and improvements.
I would be happy to participate in discussions about GEF
developments and, hopefully, participate in GEF3/GEF5
transition process.
However, I doubt that we can bring features of GEF5 into
GEF3 (at least major features).
I think GEF3 API should remain the same for backward
compatibility as there are hundreds of existing GEF3-based
solutions. But it should be improved.
This is the main idea of my letter - return GEF3 to life
to be able to fix bugs and provide minor UI or API
improvements. We don't want to turn GEF3 into GEF5.
Another idea is that we could try to add support of
SWT-based UI rednering into GEF5. This will solve
conceptual problems with GEF3->GEF5 migration.
Briefly: the main thing we need now is a possibility to
commit into GEF3 legacy repository and return GEF3 into
release cycle.
Best,
Serge
On Thu, Feb 17, 2022 at 3:29 PM Matthias Wienand
<matthias.wienand@xxxxxxxxx
<mailto:matthias.wienand@xxxxxxxxx>> wrote:
Hey,
it is nice to see some action here :-)
@Lars: Yes, I think that is the way to go. Thank you
for offering your support with the uncomfortable stuff
;-) Maybe we need Serge and Alois to bring in a few
contributions first, before we do an election, but I
would also be fine with skipping directly to an
election TBH.
@Serge: It would be nice if you could try to answer
Alexander's question "Do you plan to actively
contribute to the GEF project as a whole, or do you
just feel obliged to GEF-legacy?". I am also very
interested in the answer.
Of course, I would like to see you try to bring
features from GEF 5 into an improved GEF 3 (the idea
you touch on in the presentation, IIUC?).
Best regards,
Matthias
On Thu, Feb 17, 2022 at 10:19 AM Pierre-Charles David
<pierre-charles.david@xxxxxxx
<mailto:pierre-charles.david@xxxxxxx>> wrote:
Le 16/02/2022 à 17:11, Serge Rider a écrit :
> Hi Team!
>
> I am from the DBeaver development team
(https://dbeaver.io <https://dbeaver.io/>). We
> develop the universal database management tool
based on the Eclipse
> RCP platform.
> Besides other Eclipse RCP extensions, we heavily
rely on legacy
> GEF/draw2d.
>
> I was a speaker on several recent Eclipse Cons,
the last session was
> about legacy GEF adoption:
>
https://www.eclipsecon.org/2021/sessions/diagrams-eclipse-rcp-back-future
<https://www.eclipsecon.org/2021/sessions/diagrams-eclipse-rcp-back-future>
> https://www.youtube.com/watch?v=3ZIUB2XFDLE
<https://www.youtube.com/watch?v=3ZIUB2XFDLE>
>
> What we want is to resurrect GEF3 maintenance
and include it back to
> the standard Eclipse RCP lifecycle.
> We have several PRs we'd like to merge in the
codebase (currently we
> maintain all fixes in our forked repository on
GitHub). We also want
> to propose legacy API improvements (keeping API
backward
> compatibility) and several features.
Hi.
This is great news, thanks for the initiative
Serge! (Thanks for DBeaver
btw, I use it almost every day and it's a great tool).
As the maintainer of GMF Runtime, I'd like to
remind that *a lot* of
projects depend on GEF Legacy (via GMF Runtime or
not). In the SimRel
alone there's Graphiti, Sirius (and Capella, even
if it's not in the
SimRel), Papyrus, Ecore Tools, and probably others.
Of course improvements would be welcome, and we
(in GMF and Sirius) may
able to propose some fixes/improvements we've
currently had to make in
our own copies of GEF classes like you, but care
must be taken not to
break the many projects which depend on the
current behavior (sometimes
in subtle ways).
Regards,
Pierre-Charles David
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx <mailto:gef-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/gef-dev
<https://www.eclipse.org/mailman/listinfo/gef-dev>
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx <mailto:gef-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/gef-dev
<https://www.eclipse.org/mailman/listinfo/gef-dev>
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx <mailto:gef-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/gef-dev
<https://www.eclipse.org/mailman/listinfo/gef-dev>
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx <mailto:gef-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/gef-dev
<https://www.eclipse.org/mailman/listinfo/gef-dev>
Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan
Eberle, Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef
Schuermann
Aufsichtsrat/Supervisory Board: Michael Neuhaus
(Vors./chairman), Harald Goertz, Eric Swehla
Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24,
44536 Lünen (Germany)
Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx <mailto:gef-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/gef-dev
<https://www.eclipse.org/mailman/listinfo/gef-dev>
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx <mailto:gef-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/gef-dev
<https://www.eclipse.org/mailman/listinfo/gef-dev>
_______________________________________________
gef-dev mailing list
gef-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/gef-dev
