[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tools-pmc] GEF4 provisional component
|
Alexander,
Thanks for the additional explanations. I think your question then is
primarily is if it is "legal" for you use the package name
"org.eclipse.gef4"? And, I'd say the answer is "yes". (Technically a
project should inform the EMO if they use package names out of the norm of
their project's name, but not sure anyone would find 'gef4' to be the least
bit confusing ... plus, I know Wayne follows all these PMC lists, so
consider the EMO informed. :)
I know there is some precedent in "modeling" where they use "emfquery2" in
some package names, in addition to "emfquery" and I think split off in a
separate EMFQuery2 project, separate from the original EMFQuery project.
But, when you get closer to any sort of formal release, or your own project
proposal, then I'd just ask you (and the GEF project) to reconsider if
having the version number in the package is the right way to go, or to have
an official GEF 4.0 release. But, that sounds like an issue for the distant
future, if ever, and in the mean time I can see how having the version
number in the package name makes things easier while
exploring/experimenting. I think this issue came up recently with the xtext
team that originally had xtext2 in some package names at first, but after
some discussion at the project level (at the urging of Eclipse leaders)
decided they could use Eclipse's powerful refactoring tools and avoid the
version number in the package name. But, if you have to stay with gef4
forever, I don't think that would ever be forbidden (just discouraged).
Thanks for asking. Good luck!
From: Alexander Nyssen <Alexander.Nyssen@xxxxxxxxx>
To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date: 02/14/2012 04:26 AM
Subject: Re: [tools-pmc] GEF4 provisional component
Sent by: tools-pmc-bounces@xxxxxxxxxxx
David,
please find my comments below.
Am 14.02.2012 um 02:51 schrieb David M Williams:
To start with, I'd want to hear what the GEF project lead would
advise
first, and suggest you work with Anthony to come up with a plan and
specific proposal. If that's not possible for some reason, then yes,
it
becomes a PMC issue, but you'll need to be explicit that's not
possible ...
and we can set up a PMC-plus-interested-parties call to discuss that.
Anthony and I have discussed and agreed on all "terms" regarding the GEF4
provisional component already. As stated on the bug, we have started the
enterprise in terms of a provisional sub-component (which technically is
placed in its own Git component) that may later be transferred into an
incubator sub-project (when community interest grows) and at some point in
time also be graduated to replace GEF 3.x (which will only be done as far
as we also have a compatibility layer for 3.x ready in place).
As this is currently quite far away, GEF 3.x and GEF4 will have to live
next to each other for quite some time, which implies that there may be the
wish to include them both in a single distribution without collision.
That's the reason I introduced the org.eclipse.gef4 namespace and the
concern of my question. I am sorry if the PMC is the wrong location to ask
such kind of things, but as it thought it to be a question probably without
the scope of the GEF project alone, I thought this to be the right place.
BTW, GEF also uses the org.eclipse.draw2d and org.eclipse.zest namespaces,
which seem to be out of the project scope either...
From reading the bug (347636) it sounds like everything is about the
same
except for some new additions.. Am I misreading that? It seems like
the
ideal would be to evolve gef, rather than simply have a branch of gef
that
was close to gef, but not gef.
Well, I thought to start with sort of a "branch" and let it evolve. What
has been done so far is to work on a "new" (API incompatible) geometry API.
After we have released Juno, my plans are to transfer the other parts of
the current 3.8 code (while already porting it to the new geometry api) and
then start to refactor the API there, beginning also to integrate new
features. So, no, its not going to be the same except for some additions...
It is a little unclear, from your note and from reading the bug, what
your
ultimate goal is. If it is to evolve GEF, that's one thing. If it is
to
radically change gef in some incompatible ways, then I'd want to hear
more
about that ... a little how and what ... more along the lines of a
project
proposal, either a new re-organized project under Tools or a new
project
under gef.
The goal is indeed to evolve GEF without any restrictions on its current
API. That may indeed lead to "incompatible" changes. I think it is more or
less a question about what we understand about evolution. Especially Draw2d
will probably have to change significally. Other things are e.g. the
command framework within GEF, that can be reconsidered. There are several
other points. However, the goal of the sub-component respectively
sub-project is to evolve GEF into something modern and better usable, so
setting it up as a new project does not seem to be appropriate from my
point of view.
If it is to be "something new" I think most of us dislike adding
"version
numbers" into the package name, as handy as that is. Perhaps
"org.eclipse.get.plus.* ...." or something more meaningful.
Another option, if Anthony agreed, is to declare GEF 3.8.x will
continue as
maintenance, but your work would be GEF 4.0 and would contain API
breaking
changes? But, that's more a decision for you and Anthony (and rest of
GEF
committers ... are there any others, still active?).
Well, Anthony and I have already agreed on this, as stated on the bug. GEF
3.x will continue as it is (i.e. no API breaking changes) and GEF4 will
have the chance to develop without being bound to API compatibility.
Actually that's the reason we started the provisional component. As already
said, creating an incubator sub-project would be the next logical step
after having sep up the provisional component. However, I did not want to
discuss the decision whether we are going to do this step or not here
(that's indeed between Anthony and me), I simply wanted to know what would
have to be done from an organizational viewpoint. If this is not the right
place for such kind of questions, I apologize.
While there's no answers in my reply, I hope it gives some ideas for
next
steps.
Thanks,
Cheers,
Alexander
From: Alexander Nyssen <alexander.nyssen@xxxxxxxxx>
To: Tools PMC mailing list <tools-pmc@xxxxxxxxxxx>,
Date: 02/12/2012 03:16 PM
Subject: [tools-pmc] GEF4 provisional component
Sent by: tools-pmc-bounces@xxxxxxxxxxx
As documented in Bugzilla #347636 (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=347636) I have recently
initiated the creation of a GEF4 provisional component inside the GEF
project. I have already set-up an own Git repository (
http://git.eclipse.org/c/gef/org.eclipse.gef4.git/) as well as a
Tycho-based build infrastructure on hudson.eclipse.org
(gef4-nightly-tycho)
for it, as well as an initial code contribution where I made use of
the
org.eclipse.gef4 namespace (to avoid name clashes with GEF proper
plug-ins). As this is not officially covered by GEF, I would like to
investigate if use of the org.eclipse.gef4 namespace is a legal way
to go
(and what would have to be done to protect it), or whether I would
have to
change the namespace back to use an org.eclipse.gef prefix instead.
Also, I
would like to know what would have to be done to transfer the
provisional
component to an official incubation sub-project (if not in the former
case,
would it be legal to use the org.eclipse.gef4 namespace there?).
Best Regards
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
[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
--
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
[attachment "signature.asc" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
tools-pmc mailing list
tools-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tools-pmc
