[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-update-dev] Install/Update questions
|
1) I understand the differences between the update and discovery tags. We
have been using these concepts from Eclipse 1.0 to ship and update our WSDD
4.0 product in the field. My concern here is that there is the need to
allow access to updates over the web and/or from a local location. In WSDD
4.0, I implemented this in a way where the user could define a local update
location. They could then toggle between this and the web update location.
We have found that users use both of these. Some will download updates from
the web, others (organizations) will download the updates from our website
as a zip, and then unzip the updates into a local spot to update from
(either on their machine, on their intranet or burn a CD). In the current
setup we cannot even ship with 2 default locations (one local and one on
the web).
2) I think that it is a fundamental flaw to not allow a feature that is
added by the update mechanism to understand where it is going to go. There
are many cases where products can be stand alone or be installed as an
extension into another product. In the case of WSDD this is extremely
crucial. There are features, that due to licence agreements we CAN NOT ship
on the same cd as the product, but they can be downloaded from the update
site. These MUST go into the same location where the rest of the features
for WSDD are installed. To have to try to tell the user to do this is, to
be blunt, pathetic. As well, it just will not work. Users will get it
wrong. There are least needs to be a way for a feature to say that it
'belongs' to the same family as another feature so we can find where to
install it. In the case of WSDD, we will always have our 'primary' WSDD
feature. All the other features that get downloaded need to be in the same
spot.
It seems to me that part of the problem is that there is an assumption that
all of the parts of the product/extension will be present when the product
is installed. This is absolutely NOT the case. As well, even though a
product like WSDD installs itself as an extension to another product, i.e.
WSAD, WSDD still has a concept of it's own product space where items that
belong to it need to go. As a default it is ok for a new feature to get
installed with the product, but we need the idea of ownership of features.
In this same vein I would like to see any extensions that are available to
the product to be shown in the locations list.
3) The problem here again is that a product like WSDD can install as a
product or as an extension. In either case, we need to find where we are
installed to find the rest of our WSDD data. This is very tightly tied to 2
above.
It sounds like finding a given feature plugin will give us the results we
need, assuming that we can control where our features get installed (i.e.
into the product or our extension)
Tim
klicnik@xxxxxxxxxx
Sent by: To: platform-update-dev@xxxxxxxxxxx
platform-update-dev-admin@ cc:
eclipse.org Subject: Re: [platform-update-dev] Install/Update questions
05/29/2002 09:47 AM
Please respond to
platform-update-dev
Tim, a bit more detail to your points:
1) Setting the update location in a feature.xml file.
The feature.xml can specify 2 kinds of urls ..... <update> and <discovery>.
In the current definition there is at most 1 <update> url, but there can be
many <discovery> URLs. The <update> urls is intended to be the location
where Eclipse will search for available updates by default. The <discovery>
url(s) are additional URLs that may be of interest to the user (other
location for updates, other related sites, etc). The <discovery> urls
appear in the "Sites to Visit" folder. The feature.xml file can specify
both <update> and <discovery> urls to point to the same place (the Alphabet
Soup example referenced by Christophe did this).
The "one-click" update wizard (Help>Software Updates>New Update) is the
default usage mode, and it searches only <update> sites. This is expected
to be the primary way of getting updates for most new users. The update
manager can be used by more experienced users to get more control over the
process. Users can navigate to specific sites and select the updates they
want (navigate using "Sites to Visit", explicitly created site bookmarks
(right click in Feature Updates, New..., Site Bookmark), drill down the
file system (incl. CD) using "My Computer"). Or users can search for
updates, but also have controls over the search scope. Eg. "Available
Updates" and control Scope Settings (incl. CD). It is also possible to
create new kinds of searches (right click in Feature Updates, New...,
Search) and control what you search for and where.
2) Install location
The [New...] button is in the wizard basically as an "escape clause". Under
normal circumstances users should just take the default. The default rules
for selecting locations are roughly as follows:
* updates to the product go by default into the product location (never
extension location)
* updates to an extension (linked) go by default into the same extension
location (never product or some other extension location)
* new features located on some site (not updates) go by default into the
product location (never some other extension location)
Since in the general case any of the default locations may not be writable
by the user, may be out of space, etc, the [New...] button allows an
alternate location to be selected. If the user creates an alternate
location, this is available (visible) only to his workspace .... ie. an
extension link is not created so the new location is not visible to other
users of the product.
3) Programmatically finding the feature install location
I think here the answer will depend on what you are trying to do. There are
a number of options available, but since I do not understand the details of
your product, I am not sure which to recommend. Also, the best answer may
depend whether you are after this information at runtime vs. install time.
* you can always get the product install location by
BootLoader.getInstallURL(). This one will tend to be the "most durable".
Seems like one solution would be to actually carve out the extra space you
need for non-plugin data there.
* at runtime you can in fact rely on the location of the feature plugin
instead of the feature (each feature supplies a plugin that carries its
attribution information, etc). If you use the runtime plugin registry,
lookup the feature plugin descriptor and get its install location. The
feature plugin is installed in the plugins/ directory in the same install
location as its feature (is in the features/ directory). This will give you
better performance than poofing up the feature model (not normally done at
runtime). Note that if you take this approach the install url you get from
the plugin descriptor user "platform:" protocol, so you'll need to make
calls to Platform.resolve() to get "real" urls.
* at runtime you can poof up the feature model by calling
org.eclipse.update.core.SiteManager.getLocalSite() and then walk it to get
information about the sites and features on each. This is a much more
heavy-weight operation than either of the above 2. [to traverse the model
call ILocalSite.getCurrentConfiguration(),
IInstallConfiguration.getConfiguredSites(),
IConfiguredSite.getConfiguredFeatures(), IFeatureReference.getFeature()]
* at install time, if you are in an install handler you have a reference to
the feature being installed so you can get its location url.
Hope one of the above will do the trick for you. Since to me it sounds like
you need to be making runtime decisions based on this information, the
first 2 approaches may be the best.
Tim_Koss@xxxxxxx
Sent by: To:
platform-update-dev@xxxxxxxxxxx
platform-update-dev-admin@e cc:
clipse.org Subject:
[platform-update-dev] Install/Update questions
05/28/2002 07:51 PM
Please respond to
platform-update-dev
(working in eclipse build: eclipse-SDK-20020528-win32)
We are testing the Update/Install mechanism for use with WSDD 5.0. As I
have mentioned in previous conversations, since WSDD 4.0 (where we
'enhanced the Eclipse 1.0 update mechanism based on Eclipse 2.0 plans), we
have ensured that ALL components of WSDD, whether they were laid down at
install time or not, would be available via the Eclipse Install/Update
Mechanism. Below are items that appear broken in the current drop of
Eclipse.
1) Setting the update location in a feature.xml file.
It seems that in the feature.xml file for a feature, that you can only have
one update entry.
In our case, we would like to have multiple locations for the update. The
simple case of this is where we ship the updates on a cd and we also have
them available on the web. How do we do set this up so both of these
locations are available under the "Sites to visit"? Is this the wrong way
to be thinking of this?
2) Install location
How is the user supposed to know what to do here? At first look, it seems
to us that this should be somehow tied to extensions. Is that true?
Otherwise, the ability to just create a new location and install into
there, seem to be useless, as the feature and plugins will be downloaded,
but the eclipse product will have no idea of the existence of this data as
there is no link file created. When we used the New... button on the
Install locations page, this would let us create a new location where
Eclipse happily downloaded the feature, but this was in no way linked back
to the Eclipse we were running
If it is the case that these locations are somehow related to extensions,
then there is another problem. If you create a product and add an extension
(using the link files), I would have expected to see the extension location
listed in the Install Locations. This was not the case. We only see the
location of the product we have installed.
What we need - In WSDD, all of our portions of our product, whether eclipse
plugins, or class library runtimes, are available via the update mechanism.
Only a portion of these features are installed when the user installs the
product. To get the rest, they can go to the eclipse updates and install
what they want. Due to third party licensing issues, some of these features
will be on the web and on the install cd, and others will only be available
on the web (this relates back to the question 1 above) We want to ensure
that if a user installs a 'new feature' that they go into the same
directory tree where the WSDD (product or extension) was originally
installed. How can we do this without having the user select this 'Install
Location' (which is VERY error prone).
3) Programmatically finding the feature install location
As Suyog requested in his posting, we need a way to determine where the
feature is being installed. We want the installer handlers to use this to
then navigate the directory tree to decided where to install the runtime
(non-eclipse) data. The location of this data need to remain consistent
based on where WSDD was originally installed. Therefore the location of
where new (but related) features are installed is very important to us - we
don not want the user to determine where to put a feature - for our
features they (unknowingly <g>) already decided this at install time.
Thanks
Tim
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-update-dev
