[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re[2]: [equinox-dev] Alternate Extension Point namespace
|
Jeff McAffer wrote:
JM> As for import package use, yes, this can be liberating and we
JM> will likely start using this more. There really is no right
JM> answer though. It actually a question of granularity. Package
JM> dependencies are not inherently better/different than bundle
JM> dependencies. They are just a different grain size. Every point
JM> (good or bad) one can make about bundle dependencies wrt packages,
JM> can be restated as a point about package dependencies wrt classes
JM> (just replace "bundle" with "package" and "package" with "class").
JM> Then you can do the same thing with classes and methods or go up
JM> and talk about features and bundles.
I think you ignore the point that Olivier made. Package dependencies are
a dependency on "what", bundle dependencies are "where/who". It is not
just a matter of granularity.
Bundle dependencies miss substitutability. A bundle with
bundle symbolic name X, version Y must always have the same
constituents. Packages, especially specification packages, can be
substituted at will. More important, it allows different providers to
provide a "part" of the solution.
This discussion is the same discussions that we are having regarding OBR2.
Grouping is, imho, causing the same type of atherosclerosis that
require bundle is causing. The lack of substitutability creates closed
worlds. The sad side effect is that it will make a tiny number of
platforms popular and others not supported because the original author
must do the work on these different platforms. An effect that Java was
supposed to prevent. We pay a very steep price in memory footprint and
performance to allow this diversity, it would be sad if we prohibited
it in our domain.
I know there are lots of issues with the substitutability approach but the
diversity of the world requires that we find solutions to those
issues. Or we have to live where software only runs on windows :-(
The only way to do find those solutions is to attack the diversity
head on and and make it work.
JM> Decreasing grain size brings more flexibility but it also
JM> brings more burden. Back when we were experiementing with Eclipse
JM> on OSGi, the use of Import-Package was deadly. We would spend
JM> literally hours pouring over package lists trying to get them
JM> right. Now we have (are getting) more tooling support, this
JM> approach is more feasible.
JM> But it is still alot to think about
JM> and manage. The tools can discover package use but they can't
JM> easily deal with the version numbers and version ranges required
JM> for an effective dependency mechanism. Currenty that requires
JM> real humans do assess the impact of semantic and syntactic
JM> changes. We are just getting to the point of having decent
JM> version numbers on our bundles and features! and wow, what a
JM> lesson this has been. We need to get some tooling in place for
JM> managing those numbers. Those same mechanisms can then be applied
JM> to finer and coarser grained chunks.
We are running the full OSGi build (>750 bundles in total) with full
version numbering and we rarely have a version problem. We have a
packageinfo file in each package directory that holds the version. We
have btool that picks up those numbers and builds the manifests import
and export clauses.
Version ranges are much harder because you have to think about
semantics as you say. However, the only one that can something useful
about this is the exporter and we decided to NOT have export ranges.
Kind regards,
Peter Kriens
JM> In any event, these certainly are worthy challenges and
JM> progress will be made, with the help of the community and their
JM> usecases.
JM> Jeff
JM> Olivier Gruber <ogruber@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 12/01/2005 07:46 AM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>cc
JM> Subject
JM> Re: [equinox-dev] Alternate Extension Point namespace
JM> Always surprising how things come around, you dismiss them and they come back... :-)
JM> In the very first prototype I built when Jeff and I created
JM> Equinox, I had relaxed both of the constraints, I had separated
JM> the namespaces for plug-ins and for extension points. I had also
JM> been using solely import-export for packages. I was after the
JM> experiment of running Eclipse on OSGi. For various reasons, in the
JM> final RCP design, we kept both models: the require-provide model
JM> and the import-export model. However, the consequences and related
JM> delicate issues are many. Equinox is facing an interesting and
JM> deep design issue with this point of extension names (ids) versus
JM> plugin names (ids), that interacts with import versus require for
JM> plug-in dependencies.
JM> Should we or should we not have the same namespace?
JM> What are the consequences on plug-in dependencies?
JM> What are the consequences on the resolver?
JM> I didn't want to restart the discussion until we had a clear
JM> use case. But now we do with eRCP. We want to have RCP and eRCP
JM> and we want to have as much portability between the two
JM> platforms.This is exactly where the tension lies between the
JM> require-provide model and the import-export model. In the
JM> require-provide model, the plug-in id is used to resolve both Java
JM> packages and extension dependencies. The resolution offers no
JM> other flexibility than versions. In contrast, the import-export
JM> model focuses on what is needed, not where it is coming from. This
JM> is true for Java packages but also for services. In other words,
JM> one model focuses on what one needs, not how or where to get it
JM> from... where the other model tends to focus on where one is
JM> guetting what one needs.
JM> Both are valid and have pros and cons.
JM> I still personally believe that services and extension
JM> points should be more alike. We should support full repleacability
JM> on both. A service may has a name (its PID) and it is something
JM> identifying the service, not any of the bundles that may provide
JM> an implementation for it. There is a strong separation between the
JM> service interface and its different implementations. The same
JM> should be true about extension points. The ids should be within
JM> their own name space, unrelated to the plugin namespace. The same
JM> names could be used, but one would not imply the other.
JM> Hence, eRCP plugins could provide the same Java package
JM> names and the same extension point ids. Any plug-in that would use
JM> only the right subset would run on both Workbench, RCP and eRCP.
JM> Of course, as Mark is pointing out, it requires that plug-ins use
JM> import-export statements for the Java package dependencies and
JM> that extensions and services be resolved similarly. Any client
JM> plug-in that would still use a require model would be bound to a
JM> given implementation, the one provided by the plug-in it requires.
JM> Hence, such a plugin written for RCP would not run on eRCP, or the
JM> other way around.
JM> I believe this strongly suggests that we sort out when and
JM> how to use our two dependency models. However, like the eRCP
JM> usecase is demonstrating, I believe we overuse bundle require when
JM> a dependency on the API is only needed. This prevents some other
JM> implementations to come along and provide an alternate
JM> implementation (different quality of service for example) or a
JM> subset (like the eRCP Workbench for example). In this case, if the
JM> dependencies would be expressed on imports of Java packages and
JM> "imports" for extension points, the resolver could wire the
JM> imports and exports for both extensions and Java packages.
JM> Finally, we are still facing a subset issue and how to grasp
JM> that in our meta data. Flexibility of origin for Java package,
JM> extensions, and services is one dimension of this issue. Now there
JM> is a very delicate issue about subsetting... we can subset Java
JM> types and we can subset extension point schema. It seems to me
JM> that versions are not enough, since each subset may need versions.
JM> How do we express subsets and their relationships so
JM> that we can still express accurate dependencies?
JM> Are we happy using other attributes than names and
JM> versions for qualifying subsets?
JM> Seems very similar to the problem of the different
JM> JREs we are facing anyway, like the J2ME subsets for instance.
JM> To summarize:
JM> 1) we are facing an architectural issue about different
JM> levels of resolution (Java package, extensions, and services)...
JM> 2) we need to use better judgement about when using a
JM> require model or an import model
JM> 3) we are facing a challenge about how to express subsets
JM> and how it impacts the way we express dependencies.
JM> Best regards,
JM> Olivier Gruber, Ph.D.
JM> Persistent & Distributed Object Platforms and Frameworks
JM> IBM TJ Watson Research Center
JM> Mark Rogalski/Austin/IBM@IBMUS
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 11/29/2005 10:35 PM
JM> Please respond to Equinox development mailing list
JM>
JM> To: Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc:
JM> Subject: Re: [equinox-dev] Alternate Extension Point namespace
JM> The eRCP programming guide will recommend that all app
JM> dependencies be declared by "Import-package" rather than
JM> "Require-plugin" so that dependencies can be resolved to either
JM> the full desktop plugin or to the eRCP subset version regardless
JM> of what symbolic ID is used for the plugins. The Extension Point
JM> namespace is the wrench in the works.
JM> Nick Edgar <Nick_Edgar@xxxxxxxxxx>
JM> Nick Edgar <Nick_Edgar@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 11/29/2005 02:58 PM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
JM> cc
JM> Subject
JM> Re: [equinox-dev] Alternate Extension Point namespace
JM> I thought that one of the goals of eRCP was to provide a common
JM> programming model so that plug-ins written against eRCP would run
JM> unmodified on the full RCP.
JM> If so (and I think this is an important goal), then we should keep not
JM> only the same type names and package ids where appropriate, but also the
JM> same plug-in ids, since these are essentially API (not just as part of
JM> extension point ids).
JM> But there should still be some way of distinguishing the eRCP subset of
JM> org.eclipse.ui in the configuration. I'm not sure what the best approach
JM> is here though. Using version ids doesn't seem to be the right answer.
JM> Nick Edgar
JM> Eclipse RCP UI lead
JM> Mark Rogalski <rogalski@xxxxxxxxxx>
JM> Sent by: equinox-dev-bounces@xxxxxxxxxxx
JM> 11/29/2005 03:38 PM
JM> Please respond to
JM> Equinox development mailing list
JM> To
JM> equinox-dev@xxxxxxxxxxx
JM> cc
JM> Subject
JM> [equinox-dev] Alternate Extension Point namespace
JM> For eRCP we would like to have a smaller org.eclipse.ui plugin that has
JM> fewer graphics and only a subset of extension points. However, producing a
JM> plugin with the same symbolic name but different content does not seem
JM> like a good practice since the two plugins could potentially be confused.
JM> The problem is that Extension Points are known by their "plugin symbolic
JM> name" + "extension name". Thus, Extensions Points can not be provided by
JM> another plugin and still be found.
JM> Tom Watson mentioned that there had been some discussion of loosening this
JM> restriction. Is there anything currently in the works that would resolve
JM> this problem or would you entertain adding a "namespace=" tag to allow
JM> changing the default namespace?
JM> Mark_______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
JM> _______________________________________________
JM> equinox-dev mailing list
JM> equinox-dev@xxxxxxxxxxx
JM> https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Peter Kriens Tel +33870447986
9C, Avenue St. Drézéry AOL,Yahoo: pkriens
34160 Beaulieu, France ICQ 255570717
Skype pkriens Fax +1 8153772599
