[platform-update-dev] How To Use Non-Plugin Feature Data

[Mark_Melvin@xxxxxxxx]

Hi There,

I have been building Eclipse features
and update sites for a long time, and I still don't understand the <data>
element of a feature.  I was hoping someone could explain this to
me and how it is used with an update site.  I'll give you a scenario.

We have an install handler that allows
for the installation of non-plugin files as part of a plugin/feature installation.
 Currently we package these as JAR files included with various plugins
and when our install handler sees one of these special JAR files when a
plugin is installed, it inflates it to the right spot and stores reference
counts in a simple file-based database so these files can be uninstalled
when the plugin is later disabled/uninstalled.  It all works great
but packaging the extra JAR file as part of our plugins cause me a lot
of pain because it introduces a lot of external (and invisible) dependencies
and plugin versioning can be hell.

So, I want to pull these JAR files out
of the plugins entirely, and just "attach" them to the top-level
features.  It looks like I can do that with the <data>
element of a feature.  But I am having a hard time seeing how this
is any different from just including a JAR file as part of your feature
payload using the bin.includes
part of build.properties.
 Why is this extra <data>
element needed and how does it help?  I mean, if I add a new data
archive using the feature manifest editor, I can only choose from files
in my feature anyway.  So how is this any different from just going
to the Build tab
of the feature manifest editor and checking it off there?  And if
I do add it as a <data>
element, do I need to include it in build.properties
as well?  If I don't - it doesn't get deployed with my feature as
part of the PDE build so I assume I have to do this, which seems to defeat
the purpose of the feature (if it is there for what I think it is there
for...).
But this brings me to my next problem.
 We originally included these archives in the features simply by deploying
them as another resource included in build.properties.
 This caused massive issues with our update site however because our
feature JAR's were quite large, and it seemed that when the update manager
queried for updates to installed features it downloaded the entire feature
JAR so it could unzip and read feature.xml,
and this resulted in multiple megabytes of data being downloaded everytime
the user checked for updates - which was totally unusable over a slow internet
connection.  This was why we moved these files into the plugins and
tweaked our install handler to begin with.

Anyway, assuming the
<data> element of the
feature is a way around the problem above (I assume that is one of the
reasons it is there), how does this tie in to the <archive>
element of the update site?  It looks to me from the docs that this
allows you to supply external archives in subfolders of the features/
folder in the update site to the update manager, and it seems to suggest
it is tied into the <data>
element of the feature, but how?  If your feature can only specify
<data>
elements for files that are part of the feature, AND in order to deploy
these files you need to include them in your feature's build.properties,
AND since features are built and deployed as single JARs when you export
an update site - well....I don't get it.

Can someone give me a working scenario
on how to use these two concepts together?  Does it allow me to accomplish
what I need to do here?

Thanks in advance,
Mark.
AMI Semiconductor - "Silicon Solutions for the Real World"
NOTICE: 
This electronic message contains information that may be confidential or privileged. The information is intended for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you received this electronic message in error, please notify the sender and delete the copy you received.