[platform-update-dev] Re: [platform-releng-dev] RE: Proposal for Eclipse

[celek@xxxxxxxxxx]

Cross post to Update Component

Christophe Elek
Eclipse Project: <http://eclipse.org>
IBM canada


To: "'platform-releng-dev@xxxxxxxxxxx'" <platform-releng-dev@xxxxxxxxxxx>
cc:
From: "Casey, Chance" <ccasey@xxxxxxxxxxxx>
Subject: [platform-releng-dev] RE: Proposal for Eclipse Installation
Standard



The real value of your proposal is to provide a standard
identification of the installation, not the location. We
could find out where to install by looking for a core
plugin and traversing up the directory structure, I believe.

Only knowing where to install makes for ugly installer user
experience/UI, however.  That's the value of the plugin.inf,
we can be more informative as to what installation the
user is dropping the plugin into, as you've stated.

However, if we do not get 100% buy-in from vendors, we cannot
use a plugin.inf search as the only means of finding Eclipse
installations.  In this situation, I might attempt to traverse
back up to it after the finding the plugin directory via
alternative means - for the purposes of displaying useful
info in the plugin install process.

I would also like suggest that this not be an .inf file, but
an .xml file,  something like:

<?xml version="1.0" encoding-"UTF-8">
<redistributor>
  organization="XYX Corp"
  product="MegaTool"
  version="1.0"

  <eclipse version="1.0"/>
  <plugin dir="E:\Program Files\XYZ\MegaTool 1.0\plugins"/>
</redistributor>

With the same slash caveats for unix.  Perhaps even a GUID,
so that later installers can check this to enable a "This
application certified to use YourCompanyPlugin!" sometime
down the road.  Maybe that's going a little too far ;)

How can we push this to vendors, if "everyone" agrees on
a standard, whatever it may be?

-CC



-----------------------------------------------------------------
Proposal for Eclipse Installation Standard - by Andrew Cornwall
=====================================================

Multiple vendors are providing plugins for Eclipse technology. In
addition, more than one vendor is shipping the entire Eclipse
framework. Because these different vendors sometimes change the
directory structure for Eclipse, everyone's install utility has to
take these differences into account. This results in a combinatorial
explosion for writers of install programs.

In order to reduce this, we offer the following suggestion:

1. All providers of the Eclipse framework include, in the base
directory of their installation, a text file with the name plugin.inf
with the following format:

BrandName <my branding name>
BrandVersion <my branding version>
EclipseVersion <my Eclipse version>
PluginDir <my plugin dir>

Each keyword is case sensitive. The value for a keyword is a text
string corresponding to all the text after the first space up to the
end-of-line. (For instance, in "BrandingName Foo", the value is
"Foo".) Newline and other control characters are forbidden. Text
values must not be more than 55 characters long.

The meaning of each keyword is explained below.

BrandName: this is the name that the Eclipse platform was
installed under. For instance, WSDD might have:
    BrandName WebSphere Studio Device Developer

BrandVersion: this is the version that the Eclipse platform was
installed as. For instance, WSDD might have:
    BrandVersion 4.03

Note that BrandName and BrandVersion must not be used for anything
except display, as-is, to the user.

For instance, an install program might ask "Do you want to install
the new plugin in the WebSphere Studio Device Developer 4.03
directory?". However, it is forbidden from changing the install based
on internal computations with BrandName and BrandVersion.)

EclipseVersion: this is the name of the underlying Eclipse technology
(as specified by the Eclipse team). Platform providers are not
permitted to modify this field. Programs *may* use this field to
determine if the Eclipse platform is compatible with their plugin.
An instance of EclipseVersion might be:
   EclipseVersion: 1.0

PluginDir: this specifies where on the filesystem the Eclipse plugin
directory is located, relative to the installed location. For
instance, because the plugin directory for WSDD is located off of the
base install directory, its value will be:
    PluginDir plugin

If another platform chose to have the following directory structure:
MyPlatform
  Eclipse
    plugins

then its PluginDir should be:
    PluginDir Eclipse/plugins
if it is Unix-based, or
    PluginDir Eclipse\plugins
if it is Windows-based.

(Note that plugin.inf will be located in the MyPlatform directory,
because that is the base install directory.)

The PluginDir is operating-system specific, but must maintain case
for the directories it names. There is no trailing slash or backslash
permitted when specifying the plugin directory. Accessing the parent
or current directory
  (PluginDir Eclipse/../../MyPlatform/./Eclipse/plugins)
is forbidden.

2. If the user chooses to install the plugins (rather than installing
an entire copy of the Eclipse platform), the install program may
search the entire file system, or part of the file system (such as
/home/<user>), for plugin.inf files. These files may be presented
these to the user as potential places to install the plugins.
If the user chooses to install to a location, the plugin files are
copied to subdirectories of the PluginDir for that installation. It
is recommended that the installation program display to the user the
directory the plugin.inf file was found (the base install dir) as
well as the BaseName and BaseVersion.

If the install program finds plugin.inf files in a directory X and a
subdirectory of X, then the subdirectory must be ignored, and X
itself must be the only location presented as an install option to
the user.

        Andrew Jr.
======================================================================
Object Technology Inc. Technical Support        phone:  (602) 569-3322
11811 North Tatum Boulevard, Suite 2400           fax:  (602) 569-6300
Phoenix, Arizona, USA  85028-1614              e-mail: support@xxxxxxx
OTI is a wholly owned subsidiary of IBM Canada, Ltd.




_______________________________________________
platform-releng-dev mailing list
platform-releng-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-releng-dev