Re: [equinox-dev] Alternate Extension Point namespace

[Olivier Gruber <ogruber@xxxxxxxxxx>]

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.

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