Hi Goktug and John,
Thanks for your answers, here's what I can say to be more explicit in my
thoughts
@Goktug
you were basically asking about exposing a method from a class that is not
even
a public API in the first place, which basically means "please start
maintaining the API of some internal implementation detail for my use case"
Usually, internal APIs are in a package named "internal" because they are
subject to change and the architecture is still not clear (the first
iterations usually). I experienced this in the years 2005 (already at that
time) when I was at Omondo and we needed to develop plugin features even
using those cutting edge libraries (at our own risks of rewriting at the
next eclipse version). The libraries were marked "internal" but were still
designed well enough so we were able to use them (that's why I mentioned
that the protected access should be the default one in open sources).
Naturally everything was not blue sky at that time, but it was great to be
able to know that we take risks by using those libraries (marked "internal"),
and at the same time to be able to use them (at the same risks as the
eclipse team itself).
So to mark a library as "subject to change" or "only for experts" you may
write it explicitely in the docs, but I don't see the point of
overprotecting the developers by forbidding them to enter the zone, or
considering it's too hard and dangerous for them. I pointed the
consequences of "forbidding" zones at the first mail here : saying it leads
to forking the project. That's definitely not a good strategy to get people
consider them selves at home. I prefer warning but letting people do at
their own risks, you might be surprised of what the community can do (and
as I said, it's completely valid to refuse to treat bugs on a part that is
marked as "subject to change").
So that's why I proposed to make the necessary methods (not one method, I
was talking about roughly 20 classes) accessible from the outside to permit
extending GWT in that part (even as independent libraries) without having
to fork GWT (or extract those too restricted classes)
@John
"in any community project, whoever cares about a feature the most is
the one that designs it, convinces others it is worth including, and
implements it"
I agree with you, I didn't know how it works inside the GWT team, that's
why I supposed the most votes features are given more importance. Anyway,
what I was asking in that bug was exactly : "to permit access to the class
members so I can do a lib that relies on it without having to fork a part
of GWT".
//---------------------------------------------
We left the principal subject and focused on a specific bug, I think it's
good to do this but to a certain extent. as long as we don't loose focus on
the subject of the post, which is not that tightly related to that bug,
even if it was triggered by it. The subject is more "procedural" than
technical
I was thinking about Ubuntu that raises the xx.04 versions that are
maintainable for some years and the xx.10 versions that are more
experimental. Having a similar model for GWT with the community releases
and the incubator releases might be an answer to permit both a stable and
head and a dynamic community move?... I wouldn't like to reinvent the
wheel, I'm wondering what can be done to allow the community to feel like
home on the GWT project. Ideally, people should be able to try patches
independently (somehow as plugins) and the GWT team can have visibility on
the most popular patches that might be candidates to the head version (or
are worth thinking on how to specify them cleanly).
This would imply having versions of the GWT incubator (not a constantly
moving trunk) and a system for dependency control (gradle, maven, ant)
between both module-module and module-GWT builds. A similar system was used
for the browser plugins, which showed to be complicated, especially when
modules depended on each other (an app the uses flash that is compatible
with a certain version of the browser)
Take as an example what I'm adopting now (for the bug I submitted): I
prefer to change the GWT core code locally and maintain my code working on
the core code each time a pull a new version than copying the GWT classes
to my own library where I will have to do manual comparing of which class
became what in the next GWT version (loosing the git history of the files).
--
You received this message because you are subscribed to the Google Groups "GWT
Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/86ef2834-ca05-43a9-9402-91539bd03f40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
