| [platform-update-dev] R2.0 Startup / Launch point creation/configuration |
Some general questions first:
1. Under R2.0 semantics you say:
Consequently, the -application argument need not be specified. If it is specified, its value overrides the value set byDo you mean product configuration as in product.ini in the plugin identified as the feature?
install/ update in the platform configuration.2. The configuration argument - as in:
argument -configuration specifies the URL of the platform configuration file used to determine the location of the Eclipse platform, the matching set of org.eclipse.core.boot, org.eclipse.core.runtime and org.apache.xerces plugins to use (this information is maintained by the install/ update support), plus the plugin-path to all additional configured plugins
- Is this the platform.cfg file associated to the base eclipse install or one specific to a product launch point (which may identify the base install and another source for plugins)
- Are we allowed to create one as part of implementing a launch point? (I've done so - but stopped)
In general I'm confused as to what I should be doing (vs what I've
learned to do). An example, with a file system layout and the actual
'eclipse -feature xx -configuration xxx ...' command string that does something
useful would really help.
In the last week or so I have been working up launch points to better understand behavior and config options with an approach closer to 1.0, but with the use of multiple plugin directories.
At first I was editing platform.cfg to get what I want - then realized I should not do this, and have moved to an approach where I have an eclipse-like dir structure, a link file, /splash, and a /plugins which also includes the plugin that is my product branding (-feature).
One of the scenarios I have used so far:
d:\base\eclipse (full sdk unzip)
d:\myprod\eclipse which contains:This works, I can run myproduct, but I don't see yet how/if I can control access to features in the Workbench base.
myprod.exe (rebuilt .exe branded for my product)
startup.jar (seems to be required)\install\install.ini - file with the application and feature defaults
\splash\splash_full.bmp - my product splash (do we need/use a splash_basic.bmp anymore?)
\plugins\.... - my product plugins, included the plugin identified as the active feature as well as a copy of org.eclipse.boot.core (so it works)
\links\base.properties - a link to the d:\base\eclipse code.
---------------
More on launch point - there were three scenarios discussed in the R2.0
startup doc - not sure how well they fit what we have been trying to do
with respect to our WSWB-branded/extended Workbench. For WSWB I've
been working with the following objectives:
Installation Scenarios
Goal of this section is to capture the installation processing and
configuration management activities that occur on a target system as Workbench-based
products are installed and service is applied to both the Workbench-base
and products. By stepping through these scenarios we can validate
the expected capabilities of the platform provided Update Manager and implications
of certain product-packaging decisions.
The following terms/packages will be used to discuss the installation scenarios:
· Base The Workbench run-time platform, as silently installed, currently viewed as the equivalent of the unzipable WSWB SDK (platform, jdt, pde, gef, and all associated source) packaged as a set of features known to the platform on first launch, which will exist on the target system only once.Expectations and assumptions
· WS-A A WebSphere Studio family product (such as WebSphere Studio Site Developer)
· WS-B A WebSphere Studio family product (such as WebSphere Studio Application Developer)
· ISV-A An ISV product based on the Workbench
· ISV-U An ISV product that represents utility function. As a general-purpose enhancement to the Workbench base this function should be available in all installed products.
· First product installed triggers silent install of the Base
· An install of the Base will include the appropriate \install\feature\feature.xml files to enable service to the Base using Update Manager function.
· The multiple features included in the Base may be packaged in separate feature-specific \plugins directories to allow for controlled reuse/reference by products (using link files).
· All products, including the Base, are installed in their own directory (ISV-U may end up being installed in the Base\Plugins directory)
· All products use the Workbench Update Manager to configure their function as part of the Workbench. (ISV-U may not need to do this depends on if this update, made using the Base Workbench launch point, will then be available to all products that already reference the Workbench).
· All products implement a launch point with their brand (ISV-U may not need to do this as their launch point is any valid Workbench-based product).
· Maintenance applied to the Base will be available to all products, regardless of which product is was active when the maintenance to the base was installed.
· If products do not desire immediate (next launch) access to maintenance or upgrades added to the Base they need to code their plugin.xml requires tags to be version-specific. This means that maintenance applied to the Base will not be used until the product is maintained to change the version-specific requires tagging in the product plugin.xml files. (If multiple products are merged they may be required to follow a common approach to plugin.xml version-specific requires tagging.)
Management of Installed Plug-ins
There are several options:
· One common \plugins directory
Con: All plugins would be, by default, accessible by all configured launch points
Con: Detailed use of exclude lists would be required to remove any plug-in functions
Pro: Platform would be aware of all dependencies to any plugin that might be removed
Pro: Maintenance to plugin sets would only have to be applied to one location· Separate \plugins directories for every product
Pro: Product-level isolation
Con: Common plugin sets would have to be installed as part of each configuration
Con: Common plugin sets might be installed in multiple locations· Managed use of shared \plugins directories.
o Most products, including the Workbench, would have their own directory.
o A shared(common) plugin directory would be used as the install location for plugin sets that are designed to be available for all product launch points.Pro: Product-level isolation
Pro: Maintenance to plugin sets would only have to be applied to one location
Con: Platform would not be aware of all dependencies to any plugin that might be removed
(only those in the active configuration)· Separate \plugins directories for base Workbench feature. That is, platform, jdt, pde, help, GEF, and so on, in different directories in the workbench base, so that link files can be used to include appropriate features in a product-specific launch.
Pro: Ease of configuration when some features may not be used by all product stacks
(such as PDE or C++)
Con: Would required a structure that is different from the current Eclipse platform build.
Need to understand:
· Ability of Update Manager to support dynamic enablement of
features (is this configure/deconfigure?)
· How the existence of multiple product configurations would
impact serviceability goals
· How to restrict use of utility plugins from configurations
that do not require (or want) access to some or all of the common features
Scenario 1: Simple Install of a Workbench-based Product WS-A
Tasks and the end state of the system will be described for a simple install of WS-A.
Task 1: Install WS-A
a. WS-A install process determines that the Base is not installed and
runs the Base silent install
State:
· Base installed at d:\Base\eclipse\
.
· Base Launch point exits as d:\Base\eclipse\Base.EXE.
· Registry tree entry for Base, as installed by WS-A, added
to system
eclipse.org
/V2
/Workbench
/com.ibm.wswb
Note: The details of this registry entry are described in the Windows registry structure topic found on page 4.
· Branding exists as plugin in d:\Base\eclipse\plugins\com.ibm.wswb.sdk
· A Workbench install initialization file (install.ini) exists
in d:\Base\eclipse\install and contains something similar to:
feature.default.application=org.eclipse.ui.workbench
feature.default.id=com.ibm.wswb.sdk
b. WS-A install process continues and installs required plugins and product branding
State:
· WS-A installed at d:\WS-A\eclipse\
.
· WS-A Launch point exits as d:\WS-A\eclipse\WS-A.EXE.
· Launch point includes a link file d:\WS-A\eclipse\install\links\base.properties
with the following content:
path=rw d:\Base\eclipse\plugins\
Note the angle of the slash (\) required.
· Branding exists as plugin in d:\WS-A\Eclipse\Plugins\WS-A.plugin.id
· Registry entry tree for WS-A, as defined by WS-A, exists in
system
· A Workbench install initialization file (install.ini) exists
in d:\WS-A\Eclipse\Install and contains something similar to:
feature.default.application=org.eclipse.ui.workbench
feature.default.id=com.ibm.wssd
· Registry entry added in the Base registry tree to reflect the
existence of a product that depends on the Base installation
eclipse.org
/V2
/Workbench
/com.ibm.wswb
/com.ibm.wssd
Note: The details of this registry entry are described in the Product installation scenario topic found on page 5.
Task 1 Summary: The installation of the WS-A product included the install of the Base. Both can be launched. Each, when launched, can use the Update Manager to service the base (this is the expectation of what will be allowed when a Workbench base build provides a launch point that will identify the platform as a set of features).
Capabilities of installed software: There are two launch points, Workbench and the WS-A product
· Direct invocation of the d:\Base\Eclipse\Eclipse.exe will start the Workbench
After shutting down the launched workbench, a Workbench configuration
file (platform.cfg) will be created in d:\Base\Eclipse\Install and contains
something similar to:
# Sun Mar 31 23:18:02 EST 2002
version=1.0
stamp=-222457515
stamp.features=0
stamp.plugins=-222457515
site.0.url="" href="file:D:/Base/eclipse/">file:D:/Base/eclipse/
site.0.stamp=1065652238
site.0.stamp.features=0
site.0.stamp.plugins=-222457515
site.0.updateable=true
site.0.policy=USER-EXCLUDE
eof=eof
· The following command will launch the product branded Workbench
when the Eclipse.exe and startup.jar files are in d:\WS-A\Eclipse and the
splash file is in d:\WS-A\Eclipse\Splash:
eclipse -boot file:D:\Base\eclipse\plugins\org.eclipse.core.boot\boot.jar
-ws Win32 -feature com.ibm.wssd -data d:\WS-A\MyWorkspace
Notes:
o The location of the splash file may change. It is expected
to be part of the feature plugin content.
o The boot parm does not actually work right, unless the data parm
is provided a workspace directory is not created, but a .metadata directory
is created in the current directory.
Fix is to copy the plugin org.ecipse.core.boot to the branded launch
point plugin directory. Not sure of final solution at this time (-boot
may go away?).
After shutting down the launched workbench, a Workbench configuration
file (platform.cfg) exists in d:\WS-A\Eclipse\Install and contains something
similar to:
# Sun Mar 31 23:09:31 EST 2002
version=1.0
stamp=31739255861
stamp.features=0
stamp.plugins=31739255861
feature.default.id=com.ibm.wswb.sdk
feature.0.id=com.ibm.wswb.sdk
feature.0.application=org.eclipse.ui.workbench
site.0.url="" href="file:D:/Base/eclipse/">file:D:/Base/eclipse/
site.0.stamp=1065652238
site.0.stamp.features=0
site.0.stamp.plugins=-222457515
site.0.updateable=true
site.0.policy=USER-EXCLUDE
site.1.url="" href="file:D:/WS-A/eclipse/">file:D:/WS-A/eclipse/
site.1.stamp=30342733524
site.1.stamp.features=0
site.1.stamp.plugins=-31919501984
site.1.updateable=true
site.1.policy=USER-EXCLUDE
eof=eof
Issues with installed configuration: Any features installed/configured on to the base launch point are not available when using the product launch point unless the install target is the base plugin directory.
Scenario 2: Install of a Second Workbench-based Product WS-B
Tasks and the end state of the system will be described for a simple install of WS-B.
Task 2: Install WS-B
a. WS-B install process determines that the Base is installed and that
the prereq WS-A is also installed.
State:
· Base installed at d:\Base\eclipse\
.
· Base Launch point exits as d:\Base\eclipse\Base.EXE.
· WS-A installed at d:\WS-A\eclipse\
.
· WS-A Launch point exits as d:\WS-A\eclipse\WS-A.EXE.
· Registry tree entry for Base and WS-A, as previously installed,
exists in system
eclipse.org
/V2
/Workbench
/com.ibm.wswb
/com.ibm.wssd
Note: This entry identifies that WS-A (wssd) is dependent on the Base
(wswb).
c. WS-B install process continues and installs required plugins and product branding
State:
· WS-B installed at d:\WS-B\eclipse\
.
· WS-B Launch point exits as d:\WS-B\eclipse\WS-B.EXE.
· Launch point includes a link file d:\WS-B\eclipse\install\links\base.properties
with the following content:
path=rw d:\Base\eclipse\plugins\, rw d:\WS-A\eclipse\plugins\
Note the angle of the slash (\) required.
· Branding exists as plugin in d:\WS-B\Eclipse\Plugins\WS-B.plugin.id
· Registry tree entry for WS-B, as defined by WS-B, added to
system to reflect the existence of a product that depends on the WS-A installation
eclipse.org
/V2
/Workbench
/com.ibm.wswb
/com.ibm.wssd
/com.ibm.wsad
· A Workbench install initialization file (install.ini) exists
in d:\WS-B\eclipse\install and contains something similar to:
feature.default.application=org.eclipse.ui.workbench
feature.default.id=com.ibm.wsad
Task 2 Summary: The installation of the WS-B product included a second reference to the install of the Base and a reference to the WS-A install (another layer in the WS family Russian doll). All can be launched. Each, when launched, can use the Update Manager to service the base (this is the expectation of what will be allowed when a Workbench base build provides a launch point that will identify the platform as a set of features). Given that, the WS-A and WS-B launch points should be able to service themselves, and in the case of WS-B, also service WS-A.
Capabilities of installed software: There are three launch points, Workbench and both the WS-A and WS-B products.
Issues with installed configuration:
· Any features installed/configured on to the base launch point
are not available when using a product launch point unless the install
target is the base plugin directory.
· If features are installed, using the base, into the base plugin
directory, these features are available in a product launch, but not viewed
as installed features. The
· Any features installed/configured on to the WSSD launch point
are not available when using the WS-B launch point unless the install target
is the WS-A plugin directory.
Scenario 3: Install of an ISV Workbench-based Product ISV-A
Issues to be brought out:
· How to support standalone install vs merged install (could
be a simple user choice at install time, but what if they want both options)
· How to allow either ISV-A or WS-B to be the branded launch
point but have access to all WS-A and ISV-A function in either workbench
(how to merge function post install of a product)
· What service posture should be mandated, such as a requires
of:
<import plugin="com.xxx" version="1.0.*" match=compatible/>
Concerns as of today:
· How to allow customer to manage a merge of ISV-A and WS-A
after the formal install.
· How to dynamically enable/disable features if/when required,
across launch points.
Scenario 4: Install of an ISV Workbench-based Utility Product ISV-U
Issues to be brought out:
· How to install a product that does not have a launch point.
· How to dynamically enable/disable features if/when required,
across launch points.
Concerns as of today:
· How to allow customer to manage the install of a utility that
should be available on n launch points (but not by default for all workbench-based
tools). This means it cant be installed in the base plugin directory.
· How to dynamically enable/disable features if/when required,
across launch points.
Pat Mc.