Re: [eclipse-dev] Your plug-in may be a liability if...: ACTION REQUIRED

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

No, when you run an Eclipse Application
from the IDE you are running a real, honest to goodness Eclipse.  You
can set it to run in strict mode and it will respond accordingly.  When
people sometimes encounter their exported apps behaving differently it
is usually because their build.properties' bin.includes line is incorrect.
 

What I was refering to in my reply was
situations where everything compiles ok but then does not run properly.
 This is due to mismatches in the PDE classpath model and the Runtime's
classpath model.  As I said, there will always be a bit of difference
but the PDE classpath computation is getting pretty darn accurate.  

Jeff

"Max Rydahl Andersen" <max.andersen@xxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

04/07/2005 10:01 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]        Your        plug-in        may        be        a        liability        if...:        ACTION        REQUIRED/ACTION REQUISE

On Thu, 07 Apr 2005 15:49:41 +0200, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
 
wrote:

> Max,
>
> I think there is some confusion here.  Plugin A contains some
packages
> declares exports for them.  Plugin B needs some of the packages
so
> declares imports for them or "requires"  A.  If
A is free to add packages
> to its export list without affecting B.  B does not have to change.
 A  
> can
> remove exports but should be mindful of API implications.  Again
this  
> does
> not affect B (as long as it can still be resolved).
>
> The magic of plugins is that they know what they have (their exports)
and
> they know that they need (imports/requires).  These lists for
A are
> independent of the lists for B.  Are we talking about the same
thing?

Yes - or at least I think so ,)

I follow your arguments for keeping api's strict.

What I'm just "nagging" about is that from my understanding when
I run an eclipse workbench from inside eclipse i'm not running under the
same restrictions as if I started eclipse normally (especailly ALL classes
 
are
available to me, even though its not listed in the plugin.xml).

So I would only discover any missing package exports by starting eclipse
standalone - which is not something I do every day while developing.

/max

>
> As for the tooling, in mere days the full power of PDE will come to
bear
> on the classpath and give you control over what you see.  In
fact, even
> today the classpath that PDE manages only exposes the things that
you
> export.  Coming is the ability to change to a strict mode where
the
> "internal" exports are not visible either.  I think
you will find that
> PDE's modelling of the classpath is pretty good (Note it will not
be
> perfect.  That would require very significant effort for marginal
> incremental gain).
>
> Jeff
>
>
>
> "Max Rydahl Andersen" <max.andersen@xxxxxxxxx>
> Sent by: eclipse-dev-bounces@xxxxxxxxxxx
> 04/07/2005 08:32 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] Your  plug-in may     be    
 a       liability if...:
> ACTION  REQUIRED/ACTION REQUISE
>
>
>
>
>
>
>
>> practice. What
>> is the problem with that? After all, as you say in the end, you
are
>> developing
>> plugins.
>
>
> This explicit listing of packages are a pain since:
>
>  From my understanding plugins will not be possible to access
any new
> packages added to some of the libraries without updating the plugin.xml
> (and that is bad if users should be allowed to update the dependent
> library without
> needing to mess with package names)
>
> And when you run the workbench from inside PDE you have access to
all
> classes/packages
> in your PDE project no matter what the plugin.xml says....at least
that  
> is
> my current experience.
> Meaning that you will not discover any classloading issues until you
 
> start
> from a total clean eclipse,
> which wont happen very often while you develop.
>
> /max
>
>
>>
>> _______________________________________________
>>
>> 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
>
>
>



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max@xxxxxxxxxxxxx
http://hibernate.org

JBoss Inc
max.andersen@xxxxxxxxx
http://jboss.com
_______________________________________________
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