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


This is exciting.

I think it is important that we do not mix different aspects: granularity and flexibility.
Traditionally, we tend to confuse them, but they are quite different.

You are correct, bundles and packages are two different granules. As always about granularity,
there are no clear winners, it all depends on the domain. While I believe it is perfectly ok that we keep
both granules, however, I think it is very important that we start looking at granularity as orthogonal to flexibility.

Today, we don't. With bundle require, both are combined, a bundle is both an origin and a grouping for Java
packages. Requiring a bundle fixes what I need but also where it comes from. This is where Peter is correct,
a bundle require strongly impacts flexibility.

However, the two concepts do not have to be mixed. We have a beginning of a solution today in R4,
with "use attributes" as well as other attributes. When importing a package, the flexibility can be large, not even
a version, just a name. Or, flexibility can be very tight. In fact, it can be as tight as a bundle require (we could specify the
bundle name and version). It can be tighter because the exporter may constrain who is allowed to import what
it exports.

However, you are making a very valid point Jeff about tooling. One of the main reasons for the success
of the bundle-require model is that it is simpler for developers. It conveys both the what-I-need and
the where-to-get-it-from. As we are separating the what from the where... as we are also separating
flexibility constraints and origins... two things are emerging:

        - we need tools to help with this.
        - we need to start thinking about roles

One of the problems we have is that we think developer only. But in fact, flexibility is rarely a developer's
concern, it is a concern for an end user, when installing plugins (granted, an end user may be a developer).
It is a concern for an administrator (when it is distinguished from the end user). Sometimes, one may want
to override such dependencies, allowing more recent versions for example, or allowing different origins for
certain Java packages. It is also a concern for a product manager who will want to check wider configurations
for compatibility... during the development phase but also later on, when new versions of needed plugins
are appearing... long after a developer has finished his or her job.

I believe that in the end, we will move toward separating the concepts of physical containers (bundles,
features, etc.) and the actual runtime concepts of dependencies, grouping of those dependencies.
I believe we are slowly realizing that what a component needs (basically classes from packages),
what are the constraints on these needed types (versions, origins, etc.), and where they are coming
from in terms of physical containers must be separated, considered orthogonal.

This is where I would like to see R5 going. This is pushing on the modularity thoughts we had in R4.
I don't think it is fair for us to ask the world to become modularized while we do not apply it to ourselves
to the same extent. As Peter is pointing out, we have to face flexibility and the complexity it brings head on.
Without flexibility, we cannot have an viable long-term ecosystem for our component technology. But as I
said above, solutions are not out of grasp. Also, we are having much more trouble getting bundles accepted
as a download and physical unit than we are having troubles making modules and services widely accepted.
It is time to separate the concepts that do not have to be bound together.

As I said, this is an exciting time.

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




Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

12/02/2005 04:06 AM
Please respond to Equinox development mailing list

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




Yup.  We definitely set aside a number of these questions so that we could focus on getting OSGi in, working and accepted in the 3.0 timeframe.  That has been accomplished and it is time to start looking at some of these other issues.  We've started down that path with the refactoring of the runtime etc but that is really not even crawling let alone a baby step.


We can likely do something about the registry namespace management in the 3.2 timeframe.  Note sure if it will be the "right" thing but something can likely be enabled (Mark, did you open a bug report for this?).


As for import package use, yes, this can be liberating and we will likely start using this more.  There really is no right answer though.  It actually a question of granularity.  Package dependencies are not inherently better/different than bundle dependencies.  They are just a different grain size.  Every point (good or bad) one can make about bundle dependencies wrt packages, can be restated as a point about package dependencies wrt classes (just replace "bundle" with "package" and "package" with "class").  Then you can do the same thing with classes and methods or go up and talk about features and bundles.


Decreasing grain size brings more flexibility but it also brings more burden.  Back when we were experiementing with Eclipse on OSGi, the use of Import-Package was deadly.  We would spend literally hours pouring over package lists trying to get them right.  Now we have (are getting) more tooling support, this approach is more feasible.  But it is still alot to think about and manage.  The tools can discover package use but they can't easily deal with the version numbers and version ranges required for an effective dependency mechanism.  Currenty that requires real humans do assess the impact of semantic and syntactic changes.  We are just getting to the point of having decent version numbers on our bundles and features!  and wow, what a lesson this has been.  We need to get some tooling in place for managing those numbers.  Those same mechanisms can then be applied to finer and coarser grained chunks.


In any event, these certainly are worthy challenges and progress will be made, with the help of the community and their usecases.


Jeff



Olivier Gruber <ogruber@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

12/01/2005 07:46 AM

Please respond to
Equinox development mailing list

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject
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
_______________________________________________
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