I very strongly agree with the points that Chris raises.
As someone who has to evolve and maintain an API, I
wholeheartedly sympathize with the desire to hide some of the internals that
can make a framework fragile or result in a burden when integrators complain
about changing internals. But in my opinion the benefits to integrators
far outweigh the relatively small burden to the project. Those building
APIs can never predict all the interesting ways that their framework will get
extended, which is why access to internals has been such a key enabler of
extensibility for the Platform. By being at the bottom of the stack the Platform
exposes itself to more of a maintenance burden more than any other project, and
they have done an amazing job leading by example, and putting safeguards in
place when needed. The following blog post has a summary of why I think
it’s so important to have access to all of the code in an open framework:
http://tasktop.com/blog/?p=5
As a practical matter, for our 3.0 cycle Mylyn is planning to better
support JEE development via WTP-specific extensions, such as those already prototyped
in Spring IDE. The Mylyn Platform/SDK extensions could not exist if any
of the SDK had inaccessible internals, even those that the API developers
thought nobody would ever want to access. This is because Mylyn is an extension
that crosscuts typical API boundaries by layering over the tools entire UI and
models beneath that UI. If WTP starts hiding packages this would either
preclude or severely limit the Mylyn integration for WTP, and we would get
stuck doing exactly the “crazy stuff” that Chris is referring to.
Mik
From:
cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris
Aniszczyk
Sent: Saturday, September 08, 2007 1:59 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Is everyone always visible?
I don't think this is a good idea personally.
WTP isn't a commercial product, it's an open source project. The community
expects that they can access any code, internal or not. If you prevent them
from accessing certain classes, they'll do crazy stuff like Equinox Transforms
(http://wiki.eclipse.org/Equinox_Transforms)
to get the MANIFEST.MF the way they like it.
My inclination is no to the change especially since this is going from a
"everything open come join the party" to "something things are
closed" model.
After reading your policy, how will you implement #1? It seems this would only
be possible for future packages.
"The only packages that can be made "hidden" are ones that no
adopter currently uses and that no one in WTP currently uses, even test
plugins..."
In response to what other projects do, I think that's a fantastic idea to
document how other projects treat API (although most I believe will follow the
traditional Platform model)
Cheers,
---
Chris Aniszczyk | IBM Lotus | Eclipse Committer | http://mea-bloga.blogspot.com |
+1.860.839.2465
David M Williams---09/08/2007 04:26:09 AM---As
philosophical as that sounds ... I really am asking about Java code. :) I hope
everyone knows
|
From:
|
David M Williams/Raleigh/IBM@IBMUS
|
|
To:
|
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
|
|
Date:
|
09/08/2007 04:26 AM
|
|
Subject:
|
[cross-project-issues-dev] Is everyone always
visible?
|
As philosophical as that sounds ... I really am asking about Java code. :)
I hope everyone knows that package visibility outside it's bundle is controlled
by whether it is listed in the manifest.mf file.
Historically, we in WTP have followed the Eclipse Platform's policy of
always making every package visible to others, even if it was
not API and even if it really was never used any where else. But, now we in WTP
are considering
to change our policy, to allow some
packages to be hidden, if they really are completely internal. We see this
potentially as an improved way to specify API's, along with
the usual correct use of x-internal, x-friend, etc. And also, we hope it will
motivate us to be more careful in our future code and designs to
better separate API from implementation.
So, two things came to mind:
1. What do other projects do?, and
2. Would it be useful to request each project in Ganymede to document their
policy?
To address both these questions, I've started Ganymede_Policies_on_Package_Visibility
as a place where Projects
can specify, and link to, their written policy on the matter.
So, if you would please, take a minute and fill in the tables listed there, if
you think it would be useful.
I created the table assuming each top level project would have one policy, and
that it would not differ from component to
component ... so, that's another thing ... let me know if that's an incorrect
assumption.
And, by all means, respond here if you have strong feelings about what a
project's policy should be.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
