RE: [eclipse-dev] Re: [platform-ui-dev] Platform UI's plug-insconverted

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Your cases would no doubt have been
caught if you were developing in strict mode.  Since this is a perfectly
functional (and equivalent) mechanism to simple omission and has the bonus
of enabling investigation and exploration we can actually get the best
of both worlds.

I'm not sure we have to hold people's
hands so much as to force them to change some configuration file to switch
development modes.  Where does it stop?  There are lots of compiler
warning/error severity preferences that people can tweak and we don't try
to make them hard even though some are definitely not recommended.

What do you mean about being able to
edit plugins for RCP apps.  Are you suggesting that people go and
modify the code or manifests for other plugins?  While techincally
possible this is definitely not recommended.  Its not clear what that
capability has to do with RCP apps either.  If you modify some plugin
you don't own, you basically void its warranty/testing and potentially
impact all other consuming plugins.  Sure, if your app (RCP or otherwise)
is completely closed or under your control, knock yourself out.  This
is not a practice I would feel comfortable promoting or relying on.

Jeff

"Ed Burnette" <Ed.Burnette@xxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/07/2005 12:44 AM

Please respond to
"General development mailing list of the Eclipse project."

To	"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>
cc
Subject	RE: [eclipse-dev] Re: [platform-ui-dev] Platform UI's        plug-insconverted to manifest        format

Just today I had two projects
fail on me when I tried to use them in 3.1M6 (WebTools and VE) and I'm
pretty sure it's because they depended upon internal packages that changed
in M6. It's too easy to use internals by accident or to use them to get
things working and never go back and fix it the right way. I've done it
in my own code.
 
Therefore if I have a vote I cast
it in favor of #1 for most cases. This a) gives developers the flexibility
to change any internal package at any time without fear of breaking a consumer,
and b) enforces a discipline of API usage that has been lacking up to now.

 
If you do use #2 and/or #3, may
I suggest that strict mode be the default for everyone, and that it be
hard to turn it off, so while one developer or small team could be promiscuous,
their code could not easily be run by anyone else. By 'hard' I mean don't
put in UI for it, make somebody edit a configuration file or set a debug
option or something like that.
 
Note that for RCP apps, the developer
can edit the manifests or change the code or whatever they want so I don't
think it's a big deal for them. It's more a big deal for add-ins to the
IDE that need to work with older and newer IDE builds/releases.

---

From:  Jeff McAffer
Sent: Wednesday, April 06, 2005 5:25 PM
To: eclipse-dev@xxxxxxxxxxx
Subject: [eclipse-dev] Re: [platform-ui-dev] Platform UI's plug-insconverted
to manifest format

There are four states a package can be in 
1) omitted from the Export-Package list - in this case the package is just
plain not visible to other plugins.  Ever. 
2) Export-Package: org.eclipse.foo;x-internal:=true - in this case the
package is available if PDE or Runtime (whichever is relevant) is in "promiscuous"
mode.  In "strict" mode this state is equivalent to #1.
3)  Export-Package: org.eclipse.foo;x-friends:="org.eclipse.bar"
- In promiscuous mode foo is available to all.  In strict mode foo
is only available to plugin b.  This is equivalent to the two plugins
being members of the same "component" in component.xml terms
4)  Export-Package: org.eclipse.foo - this is an unqualified export
and allows all other plugins the opportunity to see the contents of foo
in all modes. _______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev