Home » Eclipse Projects » Equinox » Self Hosting Thread
| Self Hosting Thread [message #1660] |
Mon, 24 February 2003 15:23  |
Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
This posting is to start the thread of discussion on self-hosting...
although it was already started under other posting threads... :-)
I may sound more critical on self-hosting than on the other
issues, I want to apologize in advance if someone feels that
his or her work is on the grill... but I do think the self-hosting
support in Eclipse is the part that needs the more work and has
the more open issues. By self-hosting I mean the full triangle
between the host Eclipse, the target Eclipse, and the web infrastructure
for publishing and deploying. Self-hosting is just a hard thing to get
right,
and it is symbiosis between the runtime platform and the tooling (JDT-PDE).
In the component model thread, we discussed plug-ins and not even
fragments... Plug-ins and fragments are the concepts of components
that the Eclipse platform understands at runtime. They are managed locally
on disk, they are loaded in the JVM, they are isolated while promoting
sharing, etc.
Plug-ins and fragments also corresponds to development concepts.
They are Java projects, managed under both the Java Development
Tools (JDT) and the Plugin Development Environment (PDE).
There is a one-to-one mapping from Java projects to plug-ins or
fragments. Dependencies between plug-ins translates into
dependencies between projects at build time.
We have our first quirk right there, the buildpath and execution
path are only poorly integrated. It so happens that the buildpath is
actually driving the runtime path. Effectively, the buildpath is
constructed with projects (either plug-ins or fragments) in the workspace
and/or external plug-ins. Where this view makes sense from a compiler
perspective, it is rather confusing from an end-user perspective.
Indeed, the runtime path is constructed through features.
A user or administrator installs features, not individual
plug-ins or fragments. Therefore, a typical target environment
for a plug-in may only be known in terms of features... not in terms
of the details of which plug-ins and which fragments. Those
features may be provided by third-party companies,
they may evolve through time as they are themselves versioned,
and finally their contents is dependent on the target environment
(OS, WM, and ARCH).
This requires developpers to have intimate knowledge of their
target environments, not only in terms of features, but in terms
of plug-ins and fragments.This is really cumbersome, especially
when those features come from third-party providers. Basically,
althouhg Eclipse runs in many different environments and starts
having different major releases, cross-compiling across versions
and target environments is just poorly supported, if at all.
Features have to be first-class citizens. Having Eclipse having
knowledge of a target environment in terms of OS, WM, and
ARCH is not enough. Plug-ins and fragments have to be build
within their feature. The feature will need to be associated with
not only an OS, WM, and an ARCH, but a feature profile...
that is, the features expected to be available at runtime... very
much like a Java profile. The feature profile needs to drive both
the build-path and class-path.
Because features are logical groupings of plug-ins and fragments,
a project (plug-in or fragment) may have to be built several times
for different target environments... not only OS,WM, and ARCH
but also different feature profiles. One word about feature profiles.
When a feature F assumes a feature profile, it is a set of features
that allows to satisfy the dependencies of the plug-ins of F .
This does not mean that the feature F will only run if those features
from the feature profile are present; it means that those features will
contribute the necessary plug-ins to fulfill the plug-in dependencies of
feature F.
Today, features are not first-class citizens. PDE and JDT do not
understand features during the development cycle; features are
just a packaging concept. As I said, the build path is based on
Java projects, external jars, plug-ins, and fragments. When testing,
the target Eclipse is not configured with features, it is configured
manually with plug-ins and fragments. Furthermore, PDE seems
to strongly invite to have external plug-ins (and therefore fragments)
installed in the host Eclipse, through the update manager.
However, the update manager does not allow to install back-level
features (Eclipse 2.1). This is very limiting to work across versions.
This is pretty annoying when one needs to fix a bug on a plug-in for
a back-level Eclipse... he has to work in a back-level Eclipse as a
hosting environment. Things are made worse if one considers that
the host environment (OS,WM,ARCH) may differ from the target
one.
One of the problem I believe is that features cannot be downloaded
or imported directly into a workspace from a web site, through the
update manager. They have to be installed in the hosting Eclipse.
Why do I have to install a feature to actually resolve a build time
dependency?
I would expect to be able to download a feature directly to my
workspace. I would expect to be able to construct the target
environment at build time very much like I would at runtime
through the update manager.
There may be workarounds for some or all of the issues I discussed
here. However, this is not my point. The point is that Eclipse has
a cumbersome approach to self-hosting, especially considering
its very diverse target environments. The core of the problems are
that JDT and PDE are not integrated enough together and even
less integrated with the update manager.
I believe self-hosting requires a much more integrated design
between the tooling for creating features, the web infrastructure
for publishing and deploying them, and the platform for hosting
them. In other words, features have to become first-class
citizens, a concept present both at development and
deployment time, bridging both together.
That said, I understand that getting a self-hosting environment
is difficult and Eclipse is certainly a great first pass at it. I simply
believe that Equinox should make it a priority to improve on
self-hosting because it would be such an attractive feature,
pun intended, for future releases of Eclipse.
Best regards,
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
|
|
|
| Re: Self Hosting Thread [message #2875 is a reply to message #1660] |
Tue, 25 February 2003 07:42  |
| Eclipse User |
|
|
|
Originally posted by: pascal_rapicault.yahoo.fr
ARGH ! I've been fooled by my newsreader that directly answered to Olivier.
I'm trying to keep up with Olivier fast pace ;-) and just comment
a few things I've seen here.
First, just as a regular user of the self-hosting I don't have that many
problems, and don't see all the problems you named as being so painfull...
But I'll go through what I mean here. Note that I'm not from the PDE team.
> There is a one-to-one mapping from Java projects to plug-ins or fragments.
This is untrue since plug-ins can contains only doc, and fragments often
contains translation files..
>Dependencies between plug-ins translates into dependencies between projects
at build time.
Yes, but it's like any regular java code... Moreover, although plugins
require
plugins, the dependencies between project is now handled in a nicer way
when
the libraries of plugins are imported as variables referencing the jars.
> It so happens that the buildpath is actually driving the runtime path.
Indeed it's backward. The build path is computed to match at best the
runtime path.
I know it, I fixed it recently...
> Indeed, the runtime path is constructed through features.
> A user or administrator installs features, not individual
> plug-ins or fragments. Therefore, a typical target environment
> for a plug-in may only be known in terms of features... not in terms
> of the details of which plug-ins and which fragments.
Personnaly I consider the features as being a shipping facility, and not
a
runtime one. You can have dependencies among features, but I think it's
wrong to have the plugins knowing about their features: a same plugin
could
be packaged in different features.
Moreover as a plugin writer you don't want to restrict your plugin to
run on
a given feature, whereas all the plugins you may needs are here.
Let's for example consider the case, where in 2.2 we decide to have a
different
organisation of features (like several UI features, different levels of
core, etc...)
Do you think it's normal plugins got broken?
> However, the update manager does not allow to install back-level features
(Eclipse 2.1).
> [...]
I don't really see the benefit of that relatively to the self-hosting
pb.
If you need to fix a plugin, you need to import the code, and you can
also
choose the location you import your plugin from (or run against) in
various
places in the workspace.
So to be short, I'm just not convinced yet that having features at runtime
is of any help.
Regards
PaScaL
|
|
|
| Re: Self Hosting Thread [message #2926 is a reply to message #2875] |
Tue, 25 February 2003 09:53 |
| Eclipse User |
|
|
|
Pascal Rapicault wrote:
> ARGH ! I've been fooled by my newsreader that directly answered to Olivier.
>
> I'm trying to keep up with Olivier fast pace ;-) and just comment
> a few things I've seen here.
> First, just as a regular user of the self-hosting I don't have that many
> problems, and don't see all the problems you named as being so painfull...
> But I'll go through what I mean here. Note that I'm not from the PDE team.
>
>
>>There is a one-to-one mapping from Java projects to plug-ins or fragments.
>
> This is untrue since plug-ins can contains only doc, and fragments often
> contains translation files..
>
The PDE projects which have the Java nature seem to enforce this
one-to-one mapping. Even if you only ship docs or translations if you
want to use the PDE you create a separate project for each plugin/fragment.
>
>>Dependencies between plug-ins translates into dependencies between projects
>
> at build time.
> Yes, but it's like any regular java code... Moreover, although plugins
> require
> plugins, the dependencies between project is now handled in a nicer way
> when
> the libraries of plugins are imported as variables referencing the jars.
>
>
>>It so happens that the buildpath is actually driving the runtime path.
>
> Indeed it's backward. The build path is computed to match at best the
> runtime path.
> I know it, I fixed it recently...
>
>
>>Indeed, the runtime path is constructed through features.
>>A user or administrator installs features, not individual
>>plug-ins or fragments. Therefore, a typical target environment
>>for a plug-in may only be known in terms of features... not in terms
>>of the details of which plug-ins and which fragments.
>
> Personnaly I consider the features as being a shipping facility, and not
> a
> runtime one. You can have dependencies among features, but I think it's
> wrong to have the plugins knowing about their features: a same plugin
> could
> be packaged in different features.
> Moreover as a plugin writer you don't want to restrict your plugin to
> run on
> a given feature, whereas all the plugins you may needs are here.
> Let's for example consider the case, where in 2.2 we decide to have a
> different
> organisation of features (like several UI features, different levels of
> core, etc...)
> Do you think it's normal plugins got broken?
The sub-features are cross dependent. If one is missing then a plugin
gets broken if it requires a plugin from another feature. The Platform
feature carries all the plugins in the platform necessary for the
platform to function.
>
>
I understand about a plugin writer not wanting restricting your plugin
to run in a given feature. However, as a practical matter the general
rule of thumb (and internally to the WSxx tools this is a requirement)
is to associate a particular plugin with a particular feature. That
feature now "owns" the plugin and is responsible for its life cycle
support/updates etc. No one gets the plugin without the feature. If they
need a new version of the plugin the y get a new feature y containing
plugin y + any other plugins.
I know it sounds like packaging only but that is a surface impression if
you have 2 different versions of a feature the latest one gets loaded
like a plugin. The problem that occurs that the plugins do their own
resolution as well so it is possible for a plugin version to load that
isn't the same version as the same plugin in the the currently loaded
feature. This should NOT happen.
It makes it very difficult to support the code if you can't determine If
features were more primary then hopefully there would be some
consistency between what the user thinks they have running and what is
actually running.
It doesn't have to be a feature it could be a "super-plugin" one that
contains other plugins and decides to load them or not. Whatever the
solution, the need is there for this type of
behaviour/function/whatever. Not from a plugin writer point of view
perhaps but from a product or user point of view.
I don't believe eclipse is made for plugin writers it made for users and
users see features not plugins, product teams work in features not
plugins, and plugin writers of any complex function ship groups of
plugins that work together and expect them to be a unit when run (like a
feature).
>
>>However, the update manager does not allow to install back-level features
>
> (Eclipse 2.1).
>
>>[...]
>
> I don't really see the benefit of that relatively to the self-hosting
> pb.
> If you need to fix a plugin, you need to import the code, and you can
> also
> choose the location you import your plugin from (or run against) in
> various
> places in the workspace.
>
> So to be short, I'm just not convinced yet that having features at runtime
> is of any help.
>
> Regards
>
> PaScaL
>
>
>
|
|
|
| Re: Self Hosting Thread [message #3044 is a reply to message #2926] |
Tue, 25 February 2003 11:12 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Peter Manahan" <manahan@ca.ibm.com> wrote in message
news:3E5B8364.7000602@ca.ibm.com...
> Pascal Rapicault wrote:
> >>There is a one-to-one mapping from Java projects to plug-ins or
fragments.
> >
> > This is untrue since plug-ins can contains only doc, and fragments
often
> > contains translation files..
>
> The PDE projects which have the Java nature seem to enforce this
> one-to-one mapping. Even if you only ship docs or translations if you
> want to use the PDE you create a separate project for each
plugin/fragment.
yeah, this forced correspondence between plugins/fragments and projects is
simplifying but can be annoying. Having said that, for most people I
suspect that once you understand it, it works fine.
> >>Dependencies between plug-ins translates into dependencies between
projects
> > at build time.
yup. That simplifies things. User's need only think about one dependency
chain.
> >>It so happens that the buildpath is actually driving the runtime path.
> >
> > Indeed it's backward. The build path is computed to match at best
the
> > runtime path.
> > I know it, I fixed it recently...
Pascal's got it. The project dependencies etc are directly derived from the
plugin.xml statements (i.e., the runtime inter-plugin dependencies).
> >>Indeed, the runtime path is constructed through features.
> >>A user or administrator installs features, not individual
> >>plug-ins or fragments. Therefore, a typical target environment
> >>for a plug-in may only be known in terms of features... not in terms
> >>of the details of which plug-ins and which fragments.
Lets be really clear here. Features allow one to control the "scope" of an
Eclipse *install*. That is, I can have 4000 features and 10000 plugins
installed but ask Eclipse to start using only a specific set of 4 features
and the related 12 plugins. Features play NO role beyond that in the
running of Eclipse. They are very useful to *people* managing
plugins/fragments and building products (see Peter's comments) but you could
delete all features from an install and Eclipse would run fine.
> > Moreover as a plugin writer you don't want to restrict your plugin
to
> > run on
> > a given feature, whereas all the plugins you may needs are here.
> > Let's for example consider the case, where in 2.2 we decide to have
a
> > different
> > organisation of features (like several UI features, different levels
of
> > core, etc...)
> > Do you think it's normal plugins got broken?
This is very important as well. Features can overlap in the plugin's they
specify. This is an important packaging approach that allows people to
install multiple "products" into the same Eclipse eventhough several my
require/supply the same plugins.
> I understand about a plugin writer not wanting restricting your plugin
> to run in a given feature. However, as a practical matter the general
> rule of thumb (and internally to the WSxx tools this is a requirement)
> is to associate a particular plugin with a particular feature. That
> feature now "owns" the plugin and is responsible for its life cycle
> support/updates etc. No one gets the plugin without the feature. If they
> need a new version of the plugin the y get a new feature y containing
> plugin y + any other plugins.
>
> I know it sounds like packaging only but that is a surface impression if
> you have 2 different versions of a feature the latest one gets loaded
> like a plugin. The problem that occurs that the plugins do their own
> resolution as well so it is possible for a plugin version to load that
> isn't the same version as the same plugin in the the currently loaded
> feature. This should NOT happen.
>
> It makes it very difficult to support the code if you can't determine If
> features were more primary then hopefully there would be some
> consistency between what the user thinks they have running and what is
> actually running.
Much of this is true from a product stack point of view. However, Eclipse
is specifically designed to allow for multiple, disjoint, overlapping
function sets to be installed simultaneously. In such an environment, it is
nearly impossible to maintain strict control over all aspects of the
install. What this means when you get down to it is that we are writing
components. Components can choose to be reused or not. If your component
is available separately and wants to be reused then it needs to have API,
people need to use only that API and you have to be serious about your API
compatibility commitments.
> I don't believe eclipse is made for plugin writers it made for users and
> users see features not plugins, product teams work in features not
> plugins, and plugin writers of any complex function ship groups of
> plugins that work together and expect them to be a unit when run (like a
> feature).
Absolutely. The observation is however that products often assemble
reusable parts from third parties. There needs to be recognition that
others will do the same and that these previously disjoint products will
then be installed into the same eclipse. There will be conflicts.
Jeff
|
|
|
| Re: Self Hosting Thread [message #4138 is a reply to message #1660] |
Tue, 25 February 2003 12:44 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Olivier Gruber" <ogruber@us.ibm.com> wrote in message
news:b3dt4n$6js$1@rogue.oti.com...
> Because features are logical groupings of plug-ins and fragments,
> a project (plug-in or fragment) may have to be built several times
> for different target environments... not only OS,WM, and ARCH
> but also different feature profiles. One word about feature profiles.
> When a feature F assumes a feature profile, it is a set of features
> that allows to satisfy the dependencies of the plug-ins of F .
> This does not mean that the feature F will only run if those features
> from the feature profile are present; it means that those features will
> contribute the necessary plug-ins to fulfill the plug-in dependencies of
> feature F.
There is a failure if this is true. There is no magic here. An individual
plugin/fragment can be compiled if all the required classes can be found at
compile time. Assuming that the class definitions do not change, how they
are compiled has no bearing on how they are run. This is standard Java
stuff. So with a strong commitment to APIs and compatibility, one can
successfully compile their plugin against one configuration of plugins and
run against another.
The only time a plugin might need to be built multiple times is if it has
some OS/WS/ARCH dependency. In general the approach there has been to
separate those dependencies into fragments which are specific to that
configuration. Java (or Eclipse) does not support any conditional
building/compiling so rebuilding multiple times would likely yield the same
result each time.
> However, the update manager does not allow to install back-level
> features (Eclipse 2.1). This is very limiting to work across versions.
> This is pretty annoying when one needs to fix a bug on a plug-in for
> a back-level Eclipse... he has to work in a back-level Eclipse as a
> hosting environment. Things are made worse if one considers that
> the host environment (OS,WM,ARCH) may differ from the target
> one.
I don't understand this. You can target whatever version of Eclipse you
want. We do this all the time. I know whole development teams that use 2.1
to develop 2.0 based products.
> That said, I understand that getting a self-hosting environment
> is difficult and Eclipse is certainly a great first pass at it. I simply
> believe that Equinox should make it a priority to improve on
> self-hosting because it would be such an attractive feature,
> pun intended, for future releases of Eclipse.
To rephrase, Equinox should make it a priority to understand the issues and
explore directions, and interest the Eclipse team in those results. I
believe that the bulk of the work is stuff that the PDE team (in particular)
is very interested in doing.
Jeff
|
|
| |
| Re: Self Hosting Thread [message #4278 is a reply to message #4138] |
Tue, 25 February 2003 18:26 |
| Eclipse User |
|
|
|
Originally posted by: ogruber.us.ibm.com
Sorry Jeff, it seems I was lacking precision, again :-)
Let's be a bit clearer and more precise.
You are only partially correct in your assertion of the standard Java stuff.
If the classes you are compiled against do not change, you are correct.
This means the plug-ins must expose unmodified API in their different
features.
This is probably coarsly true for most plug-ins... agreed.
But as you pointed out, this may not be true for plug-ins dependent on OS,
WM, and ARCH. Therefore, PDE will have to support this. It does not matter
if it is likely or not, the need for the functionality is there.
Also, my point for re-building was not to argue that class files needed
to be rebuilt, indeed Java allows to avoid this... however, the question
is really on the feature profiles... The rebuilding not only rebuilds class
files but as a side effect checks all dependencies on classes and
interfaces.
In other words, the rebuild tells you if you plug-in is compatible with the
feature profiles you selected.
I really like the analogy between features and profiles. Like in the J2ME
world, one has to build against the different profiles it targets unless he
is
sure they are ine a super-subset relationship and that he builts against the
smallest one.
This actually suggests something I forgot to stress... in self-hosting mode,
the host Eclipse should really behave as a feature server. Hence, it should
drive the update manager of the target Eclipse remotely, provoking the
install... Hey, now that we will be dynamic, why not use it to our advantage
:-)
Indeed, for cross-compiling across different feature profiles, one
will need to deploy on different targets, populated differently... even
potentially
on a different OS, WM, and ARCH. This makes self-hosting deployment
for testing very similar to debugging, both would rely on a remote
interface.
Best regards,
Olivier.
--
Olivier Gruber, Ph.D.
Persistent & Distributed Object Platforms and Frameworks
IBM TJ Watson Research Center
"Jeff McAffer" <jeff_mcaffer_REMOVE@ca.ibm.com> wrote in message
news:b3g8b6$12g$1@rogue.oti.com...
>
> "Olivier Gruber" <ogruber@us.ibm.com> wrote in message
> news:b3dt4n$6js$1@rogue.oti.com...
> > Because features are logical groupings of plug-ins and fragments,
> > a project (plug-in or fragment) may have to be built several times
> > for different target environments... not only OS,WM, and ARCH
> > but also different feature profiles. One word about feature profiles.
> > When a feature F assumes a feature profile, it is a set of features
> > that allows to satisfy the dependencies of the plug-ins of F .
> > This does not mean that the feature F will only run if those features
> > from the feature profile are present; it means that those features will
> > contribute the necessary plug-ins to fulfill the plug-in dependencies of
> > feature F.
>
> There is a failure if this is true. There is no magic here. An
individual
> plugin/fragment can be compiled if all the required classes can be found
at
> compile time. Assuming that the class definitions do not change, how they
> are compiled has no bearing on how they are run. This is standard Java
> stuff. So with a strong commitment to APIs and compatibility, one can
> successfully compile their plugin against one configuration of plugins and
> run against another.
>
> The only time a plugin might need to be built multiple times is if it has
> some OS/WS/ARCH dependency. In general the approach there has been to
> separate those dependencies into fragments which are specific to that
> configuration. Java (or Eclipse) does not support any conditional
> building/compiling so rebuilding multiple times would likely yield the
same
> result each time.
>
> > However, the update manager does not allow to install back-level
> > features (Eclipse 2.1). This is very limiting to work across versions.
> > This is pretty annoying when one needs to fix a bug on a plug-in for
> > a back-level Eclipse... he has to work in a back-level Eclipse as a
> > hosting environment. Things are made worse if one considers that
> > the host environment (OS,WM,ARCH) may differ from the target
> > one.
>
> I don't understand this. You can target whatever version of Eclipse you
> want. We do this all the time. I know whole development teams that use
2.1
> to develop 2.0 based products.
>
> > That said, I understand that getting a self-hosting environment
> > is difficult and Eclipse is certainly a great first pass at it. I simply
> > believe that Equinox should make it a priority to improve on
> > self-hosting because it would be such an attractive feature,
> > pun intended, for future releases of Eclipse.
>
> To rephrase, Equinox should make it a priority to understand the issues
and
> explore directions, and interest the Eclipse team in those results. I
> believe that the bulk of the work is stuff that the PDE team (in
particular)
> is very interested in doing.
>
> Jeff
>
>
|
|
|
Goto Forum:
Current Time: Tue Nov 04 06:22:43 EST 2025
Powered by FUDForum. Page generated in 0.09382 seconds |
Home