Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cross-project-issues-dev] Is everyone always visible?

Using that argument, we shouldn't have private fields or methods either
then ;-) ;-) ?!

-Randy



                                                                           
             "Mik Kersten"                                                 
             <beatmik@xxxxxxx>                                             
             Sent by:                                                   To 
             cross-project-iss         "'Cross project issues'"            
             ues-dev-bounces@e         <cross-project-issues-dev@eclipse.o 
             clipse.org                rg>                                 
                                                                        cc 
                                                                           
             09/09/2007 08:53                                      Subject 
             PM                        RE: [cross-project-issues-dev] Is   
                                       everyone always visible?            
                                                                           
             Please respond to                                             
               Cross project                                               
                  issues                                                   
             <cross-project-is                                             
             sues-dev@eclipse.                                             
                   org>                                                    
                                                                           
                                                                           




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

(Embedded image moved to file: pic18899.gif)Inactive hide details for David
M Williams---09/08/2007 04:26:09 AM---As philosophical as that sounds ... I
really am asking abDavid 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

Attachment: pic18899.gif
Description: GIF image


Back to the top