[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cross-project-issues-dev] Is everyone always visible?
|
It just wouldn't be September without
this topic coming up... Guess it is David's turn to get slapped around
a bit... ;-)
I am firmly with Chris and Mik. Many
years ago I proposed something much along the lines of what you are suggesting.
The out-pouring was quite dramatic. Then a couple years ago someone
misunderstood something I said for such a proposal. It took about
a month of email to calm that one down.
In the end the "winning" argument
is that without exporting of some kind, people just cannot access the code.
Where is the win in that? The PDE/JDT folks have done a wonderful
job of tooling x-internal and x-friends. The upcoming API tooling
will enhance this by allowing for postmortem and third-party API/internal
usage analysis. Further more, you can run the platform in "strict"
mode and get the effect you are looking for. With all these mechanisms,
people do not have any excuse for using non-API other than "we thought
long and hard and really needed to call that method, access that class,
..." As open source bundle producers our job is to inform our
users of the API and intended use models. For the most part the consumers
are adults who can choose for themselves if they want to color outside
the lines.
Since the decision is so black and white,
pursuing this direction will also require considerable effort and debate
within the community as you decide which code to export and which to banish.
Chris' point about the code being freely
available and modifiable is bang on as well. All this would do in
the end is force people to fork *your* bundle to add the export. We'd
have a configuration nightmare.
Finally, rightly or wrongly, there are
quite a number of commercial products (some you know all too well) that
use internals. Who is to say that the code you are looking to banish
would not be the subject of such wandering eyes?
In short, just say "no"
Jeff
"Mik Kersten"
<beatmik@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx
09/09/2007 08:53 PM
Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx> |
|
To
| "'Cross project issues'" <cross-project-issues-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cross-project-issues-dev] Is everyone
always visible? |
|
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_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev