Re: [platform-update-dev] non-plugin data - what happens to it after an

[Patrick_Mueller@xxxxxxx]

Yikes!  OK ... getting there ... :-)

The CoreException bit, to leave early upon error, is a bit problematic for me.  How do I figure out which plugin to use?  Status doesn't appear to eat null or "" for the plugin id, and I don't have a plugin here, really.  I'll give it "update" for now to see how far it goes, but I think you need to help me build a CoreException, or perhaps you should define your own exception that lets me fill in the serverity/message fields.

Patrick Mueller
patrick_mueller@xxxxxxx

klicnik@xxxxxxxxxx Sent by: platform-update-dev-admin@xxxxxxxxxxx 05/14/2002 09:36 AM Please respond to platform-update-dev

To:        platform-update-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [platform-update-dev] non-plugin data - what happens to it after an install

Patrick, sorry for the delay in responding ....

The way this work is as follows:

The interface definition of IFeature abstracts the actuall details of the
internal packaging format the feature uses into IFeatureContentProvider
object. The feature we implement (the one you are getting by default)
implements such a content provider based on the packaging format we
document (feature .jar, plugin .jars, non-plugin files). The install
handler is passed reference to the feature that is being installed on
initialization. The BaseInstallHandler implementation saves it, so it is
available to you in the subsequent calls.

What you need to do is call feature.getFeatureContentProvider() and then
call provider.getNonPluginEntryArchiveReferences(...). The general form of
the API returns an array of references (beause different providers may
package <data> differently). However, in the current case of the default
feature (using the specified packaging format) there is exactly one file
(archive) that corresponds to the <data> tag so you will be getting an
array of 1 reference.

Once you have the reference (this is what you were looking for) you can use
the content consumer passed to the method to store the file, or just do
java I/O (which is likely your case).

There is an implementation of org.eclipse.update.internal.core.
DefaultInstallHandler that we intend to move to the examples plugin that
you can look at. It implements the verification and install handling
methods of the install handler. The install handling simply dumps
(optionally unzips) the data files into the features/<myfeature>/
directory. So the actual handling you want is different, but the
implementation should be a reasonable example to get you going.



You are obviously unpacking the feature and plugin jars correctly, so I
don't care about their names; however, for the non-plugin jar, how am I
ever suppsed to figure out this 'suffix', given all I got was the
identifier via INonPluginEntry.getIdentifier(), which returned the
identifier (file name) in the feature.xml file?  I think I either need this
relatively-qualified temp name, or you will need to rename it to the
identifier specifed in the feature.xml file.




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