Re: [equinox-dev] Alternate Extension Point namespace

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

This message snuck into a different
bucket and I missed replying...

equinox-dev-bounces@xxxxxxxxxxx wrote on 12/08/2005
12:47:32 PM:

> The "bad news" is that it is mostly a tool's issue.... in
fact 
> mostly PDE. It is true that plug-in dependencies are just simpler
to use for 
> developers. It also easier for the tools, because it says what you
> need and where to get it from. Without that, we need to move toward
> a design-time configuration.... as we have a runtime 
> configuration... that is, a set of plug-ins that tools are working
against... 
> as we have a set of plug-ins that a runtime hosts or executes. 
> 
> The good news is that PDE is already using the same resolver than
> the runtime... for resolving dependencies... 

You should check out the feature/function in PDE today
and in upcoming I builds.  There are many new things in terms of target
definition and management and under the covers classpath management.

> So everything has moved in the right direction...
> 
> It seems to me that we have just a few loose ends to tie together...
> at least from a design perspective :-)) 
> 
>         - separate namespaces (plugin names and
extension point names) 
>         - introduce versions on extension points
>         - express dependencies as much as possible
on packages for 
> the APIs using the new R4 features 
>         - use bundle dependencies where it makes
sense, such as for 
> implementation dependencies... 
> 
> The real question is what is the model shown to developers by PDE?
> Comments anybody? 

This seems disjoint from the loose ends mentioned
above.  

> To me, it seems that it is both a UI change and
an experience change
> for developers... 
> They need to be exposed to the dependency model of OSGi and how they
> are resolved 
> within a configuration (set of plug-ins). It is a bit harder than
> the current "classpath" management... 
> but it is just the way it is since it is the way classes need to be
> compiled or even executes... 
> At some point we will need to allow for advanced developers to see
> the actual configuration and class path management as well as the
> true visibility rules... 

I'm not sure if I followed.  Currently bundle
developers using PDE don't really have to think about classpaths or how
dependencies are resolved.  This is good.  They are free to focus
on simply declaring their dependencies as per the various OSGi mechanisms.
 PDE takes care of the rest (including detailed access rules etc).
 Developers should of course understand the tradeoffs between Import-Package
and Require-Bundle but ultimately be free to do whatever they want.  

Yes, advanced users should be able to get more detail
on where their classes are coming from.  Currently they can get quite
a bit of detail by going and expanding the plugin classpath container and
looking at the entries and access rules.  Ideally they would be able
to query things like "where does plugin P get class C from?"

> As far as I can see, this has no bearing on features...
Comments anybody? 

Features as in update features?  If so, correct,
features have nothing in particular to do with code development other than
potentially being an interesting way for developers to talk about groups
of bundles.  For example, a developer may want to describe a target
platform in terms of 4 features rather than listing 100 bundles.

> So we are facing quite straigthforward first
steps, from a technical
> perspective, 
> what I am not mastering is how this fits in the plan for 3.2 and the
> actual limitations of the 
> current design and architecture of PDE.... Comments anybody? 

This discussion needs to be much more concrete in
terms of changes to workflows, user concepts and user presentations.  I'm
not sure how the original topic really relates to PDE.  We could add
explicit namespace management to extensions and extension points reasonably
easily in the registry and with reasonably minor changes to PDE itself.
 Feels to me like there are several topics mixed up together here.
 Of course lots of stuff is interconnected but to make sense of it
and make progress they need to be teased apart.

Jeff