Re: [equinox-dev] Alternate Extension Point namespace

[Olivier Gruber <ogruber@xxxxxxxxxx>]

Hi Mark,

Sorry for the delay in following up...

This discussion thread is not to be
alarmist... or wanting to make a statement that we are facing things that
we don't know how to solve.
This is more a question about how to
absorb the change, that is, how to evolve from the current mindset to a
more flexible mindset...

The good news, since OSGi R4, the runtime
has almost all it needs to support all degrees of flexibility you need...
from none to quite flexible.
This seems to be a very small change,
technically speaking, but this is a mindset change for the Eclipse community,
and this is never easy...

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...
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?

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...

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

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?

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 12/02/2005 05:10 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

There is a bug report already open for this issue: 112856
I added a comment to it stating the eRCP use case. 

While I agree that major dependency resolution changes may be needed to
solve this problem in a good, generic fashion, I would like to point out
that eRCP needs an interrim solution in the 3.2 timeframe. Hopefully, something
simple could be introduced which would be the first step toward the full
blown solution which would also include more tooling support.

Olivier
Gruber/Watson/IBM@IBMUS

Olivier Gruber/Watson/IBM@IBMUS
Sent by: equinox-dev-bounces@xxxxxxxxxxx

12/02/2005 09:48 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

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
_______________________________________________
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