Skip to main content

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


Always surprising how things come around, you dismiss them and they come back... :-)

In the very first prototype I built when Jeff and I created Equinox, I had relaxed both of the constraints, I had separated the namespaces for plug-ins and for extension points. I had also been using solely import-export for packages. I was after the experiment of running Eclipse on OSGi. For various reasons, in the final RCP design, we kept both models: the require-provide model and the import-export model. However, the consequences and related delicate issues are many. Equinox is facing an interesting and deep design issue with this point of extension names (ids) versus plugin names (ids), that interacts with import versus require for plug-in dependencies.

Should we or should we not have the same namespace?
What are the consequences on plug-in dependencies?

What are the consequences on the resolver?

I didn't want to restart the discussion until we had a clear use case. But now we do with eRCP. We want to have RCP and eRCP and we want to have as much portability between the two platforms.This is exactly where the tension lies between the require-provide model and the import-export model. In the require-provide model, the plug-in id is used to resolve both Java packages and extension dependencies. The resolution offers no other flexibility than versions. In contrast, the import-export model focuses on what is needed, not where it is coming from. This is true for Java packages but also for services. In other words, one model focuses on what one needs, not how or where to get it from... where the other model tends to focus on where one is guetting what one needs.

Both are valid and have pros and cons.

I still personally believe that services and extension points should be more alike. We should support full repleacability on both. A service may has a name (its PID) and it is something identifying the service, not any of the bundles that may provide an implementation for it. There is a strong separation between the service interface and its different implementations. The same should be true about extension points. The ids should be within their own name space, unrelated to the plugin namespace. The same names could be used, but one would not imply the other.

Hence, eRCP plugins could provide the same Java package names and the same extension point ids. Any plug-in that would use only the right subset would run on both Workbench, RCP and eRCP. Of course, as Mark is pointing out, it requires that plug-ins use import-export statements for the Java package dependencies and that extensions and services be resolved similarly. Any client plug-in that would still use a require model would be bound to a given implementation, the one provided by the plug-in it requires. Hence, such a plugin written for RCP would not run on eRCP, or the other way around.

I believe this strongly suggests that we sort out when and how to use our two dependency models. However, like the eRCP usecase is demonstrating, I believe we overuse bundle require when a dependency on the API is only needed. This prevents some other implementations to come along and provide an alternate implementation (different quality of service for example) or a subset (like the eRCP Workbench for example). In this case, if the dependencies would be expressed on imports of Java packages and "imports" for extension points, the resolver could wire the imports and exports for both extensions and Java packages.

Finally, we are still facing a subset issue and how to grasp that in our meta data. Flexibility of origin for Java package, extensions, and services is one dimension of this issue. Now there is a very delicate issue about subsetting... we can subset Java types and we can subset extension point schema.  It seems to me that versions are not enough, since each subset may need versions.  

        How do we express subsets and their relationships so that we can still express accurate dependencies?
        Are we happy using other attributes than names and versions for qualifying subsets?
        Seems very similar to the problem of the different JREs we are facing anyway, like the J2ME subsets for instance.

To summarize:

1) we are facing an architectural issue about different levels of resolution (Java package, extensions, and services)...
2) we need to use better judgement about when using a require model or an import model
3) we are facing a challenge about how to express subsets and how it impacts the way we express dependencies.

Best regards,

Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center




Mark Rogalski/Austin/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx

11/29/2005 10:35 PM
Please respond to Equinox development mailing list

       
        To:        Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
        cc:        
        Subject:        Re: [equinox-dev] Alternate Extension Point namespace



The eRCP programming guide will recommend that all app dependencies be declared by "Import-package" rather than "Require-plugin" so that dependencies can be resolved to either the full desktop plugin or to the eRCP subset version regardless of what symbolic ID is used for the plugins. The Extension Point namespace is the wrench in the works.



Inactive hide details for Nick Edgar <Nick_Edgar@xxxxxxxxxx>Nick Edgar <Nick_Edgar@xxxxxxxxxx>

Nick Edgar <Nick_Edgar@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

11/29/2005 02:58 PM

Please respond to
Equinox development mailing list



To

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

cc

Subject

Re: [equinox-dev] Alternate Extension Point namespace




I thought that one of the goals of eRCP was to provide a common
programming model so that plug-ins written against eRCP would run
unmodified on the full RCP.
If so (and I think this is an important goal), then we should keep not
only the same type names and package ids where appropriate, but also the
same plug-in ids, since these are essentially API (not just as part of
extension point ids).

But there should still be some way of distinguishing the eRCP subset of
org.eclipse.ui in the configuration.  I'm not sure what the best approach
is here though.  Using version ids doesn't seem to be the right answer.

Nick Edgar
Eclipse RCP UI lead




Mark Rogalski <rogalski@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx
11/29/2005 03:38 PM
Please respond to
Equinox development mailing list


To
equinox-dev@xxxxxxxxxxx
cc

Subject
[equinox-dev] Alternate Extension Point namespace






For eRCP we would like to have a smaller org.eclipse.ui plugin that has
fewer graphics and only a subset of extension points. However, producing a
plugin with the same symbolic name but different content does not seem
like a good practice since the two plugins could potentially be confused.
The problem is that Extension Points are known by their "plugin symbolic
name" + "extension name". Thus, Extensions Points can not be provided by
another plugin and still be found.

Tom Watson mentioned that there had been some discussion of loosening this
restriction. Is there anything currently in the works that would resolve
this problem or would you entertain adding a "namespace=" tag to allow
changing the default namespace?

Mark_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/equinox-dev


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev


Back to the top