[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] plugin paths
|
Actually it was supposed to solve installation requirements in general
whether it be Windows or Linux. There seems to be a disconnect between the
way products are made/installed and the way eclipse is expected to be
shipped with a product at least in V1.
This may be premature as well. If this isn't handled by the plugin-path
option in V1.0 then I assume it is handled by the "links" feature in V2.
1. Users complain about duplicated code and installs. Had understood that
due to the concept of "plugins" that eclipse is designed to only exist once
on a system. The core piece if you will. Products group a collection of
plugins I'll use WSSD and WSAD as an extreme example as WSSD is basically a
subset of WSAD function but a separate product. (i.e. they can exist side
by side). WSSD gets installed. The user then buys WSAD and installs it.
Now say WSAD has 1/2 the plugins the same as WSSD so instead of installing
them what WSAD has done is prereq WSSD and join adds its plugins to the
collection. Now to run the "WSAD product" which is basically productized as
the product-guide describes.Run WSAD launcher. Which throws up the
application splash etc and hooks up the plugins from WSAD and WSSD and then
passes all this configuration to the eclipse launcher. Which brings up WSAD
in its full glory :)
2. Touching the install tree of a another product's install is a no-no
especially from a support point of view. On Windows it was allowed until
the advent of Windows Installer which was created to handle some of the
problems that had been popping up mainly regarding shared files and files
being clobbered by other product installs. The installer is the one that
keeps track of what "files" are on the system. Installed on the system.
When you start adding/replacing that function you will break the
install/support mechanism's the OS provides. This is true of at least
Windows, AIX, and to some extent Linux. I am not sure about Solaris but i
would be surprised if it was similar to AIX.
Note that for VAJ Windows Installer had more than half its function in this
area suppressed in order to workaround some particular VAJ issues. You
can't usually do this on other systems as shown by the VAJ install on AIX
which required a shell script to copy over a significant amount of files
into user space. Products which do suppress this function are not usually
Windows 2000 compliant (if they care about that distinction) and have
problems with support issues. On AIX we can't even ship a product that
isn't using installp and PTF's for updates.
3. The installed files (which the operating system owns and knows about)
are generally in a read-only location. Therefore all configuration needs
to be done externally to the install tree. I had read the 2.0 Draft update
spec and had assumed that the update mechanism was placing the updates in a
location outside the product install tree as otherwise it isn't usable in a
product (refer back to 2). Updates to an installed product files are done
by an installer and eclipse would handle the configuration.
4. If we need to wait for V2.0 to introduce this function and use "links"
and a native installer as we actually have to in most cases the
restrictions on doing in the update spec are to say the least bizarre. So
bad in fact that products may as well disable the Update mechanism for it
will be of no use at all. I'll put the details about that into a separate
note on the spec though.
So if #1 above cannot be implemented using V1 of eclipse as these several
notes allude to then I assume that for version 2.0 of eclipse this is a
design goal? It seems to be according to the update spec. This would of
course require the wswb to actually become its own "product" with its own
install.
Eclipse taking over the OS install duties isn't a good choice, it will be a
support nightmare and won't even work on some systems correctly.
Thanks,
_____________________________________
Peter Manahan
WebSphere Studio Application Developer
Linux Port Team
VisualAge for Java Release Lead
manahan@xxxxxxxxxx
_____________________________________
John
Kellerman/Raleigh/IBM@IBMUS To: platform-update-dev@xxxxxxxxxxx
Sent by: cc:
platform-update-dev-admin@e Subject: Re: [platform-update-dev] plugin paths
clipse.org
12/06/2001 01:39 PM
Please respond to
platform-update-dev
Note that while plugin path works you need to consider that, in addition to
worrying about managing your environment, this parameter is not intended to
be supported as a command line parameter for tools built on eclipse. It
looks like you're attempting to use this as way of solving some
installation requirements you have in Linux. In general, take a look at
the branding/packaging guide at
http://www.eclipse.org/articles/product-guide/guide.html. If this doesn't
solve your requirement, I'd suggest a discussion on the newsgroup.
John Kellerman
Product Manager, WebSphere Studio Workbench
OTI - Research Triangle Park, NC
kellrman@xxxxxxxxxx
Please respond to platform-update-dev@xxxxxxxxxxx
Sent by: platform-update-dev-admin@xxxxxxxxxxx
To: platform-update-dev@xxxxxxxxxxx
cc:
Subject: Re: [platform-update-dev] plugin paths
The plugin-path support works in 1.0 and will continue to work in 2.0 ....
but using it basically puts you in a condition of being responsible for
controlling your environment. So, for example, depending on what you do,
you may not pickup any updates done by the update manager (eg. if your
plugin path is not updated to reflect the change).
Please respond to platform-update-dev@xxxxxxxxxxx
Sent by: platform-update-dev-admin@xxxxxxxxxxx
To: platform-update-dev@xxxxxxxxxxx
cc:
Subject: [platform-update-dev] plugin paths
Is the use of the -plugins parameter advisable in Eclipse v1? We are
building a product on it and it would make a lot of sense to have separate
installs of eclipse itself, and various subcomponents. Without this we
would end up with each product installing its own copy of the workbench
code. From my initial tests is seems to work properly, but since there is
a lack of documentation I wanted to find out what the official
recommendation is.
-- Steve Francisco
