[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Alternate Extension Point namespace


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