Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-update-dev] How To Use Non-Plugin Feature Data

Exactly. Note that there is a default location for data jars. Here is the
snippet from the document linked below:

<quote>
When interacting with the update site, the feature implementation maps the
<plugin> and <data> elements into path identifiers used by the site to
determine the actual files to download and install. The default feature
implementation supplied by Eclipse constructs the path identifiers as
follows:

<plugin> element results in a path entry in the form
"plugins/<pluginId>_<pluginVersion>.jar" (for example,
"plugins/org.eclipse.core.boot_2.0.0.jar")
<data> element results in a path entry in the form
"features/<featureId>_<featureVersion>/<dataId>" (for example,
"features/com.xyz.tools_1.0.3/examples.zip")
</data>

This implies that you don't need to define 'archive' entries in the
site.xml as long as you place the data jars according to this convention.

Regards,

Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D1/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745  T/L 969-2745
Fax. 905 413-4850



                                                                           
             Mark_Melvin@amis.                                             
             com                                                           
             Sent by:                                                   To 
             platform-update-d         "Eclipse Platform Update component  
             ev-bounces@eclips         developers list."                   
             e.org                     <platform-update-dev@xxxxxxxxxxx>   
                                                                        cc 
                                                                           
             02/01/2007 09:27                                      Subject 
             PM                        Re: [platform-update-dev] How To    
                                       Use Non-Plugin Feature Data         
                                                                           
             Please respond to                                             
             "Eclipse Platform                                             
             Update component                                              
             developers list."                                             
             <platform-update-                                             
             dev@xxxxxxxxxxx>                                              
                                                                           
                                                                           




OK, so I read this as, if I want to deploy "my_data.jar":

- I should declare a "my_data.jar" data element in my feature
- I should build it outside of my feature

Which leads me to believe that I should also then (and I'm guessing here):

- *Not* include it in my bin.includes for my feature (i.e. PDE build knows
nothing about it)
- Ship it alongside my final "my_feature_vXXXX.jar"
- *If* I am using an update site, add <archive> path entry for it and
include it *somewhere*

Is this correct?

Thanks for the reply,
Mark.
----------------------------------------------------------



-----platform-update-dev-bounces@xxxxxxxxxxx wrote: -----


To: "Eclipse Platform Update component developers list."
<platform-update-dev@xxxxxxxxxxx>
From: Dejan Glozic <dejan@xxxxxxxxxx>
Sent by: platform-update-dev-bounces@xxxxxxxxxxx
Date: 02/01/2007 05:43PM
cc: platform-update-dev@xxxxxxxxxxx,
platform-update-dev-bounces@xxxxxxxxxxx
Subject: Re: [platform-update-dev] How To Use Non-Plugin Feature Data

You can start by reading the bottom of
http://help.eclipse.org/help32/topic/org.eclipse.platform.doc.isv/reference/misc/feature_manifest.html
.


Essentially features jars should be kept small. Any payload should be
outside. Features understand two types of payloads:

  Plug-ins
  Data archives

The difference is that feature know what plug-ins are and upon download,
they can proceed by installing them in the right place and updating the
platform configuration for them. In contrast, features know nothing about
data Jars. For this reason, they will download the JARs in a staging
location on your machine, then delegate to install handler to continue the
processing. For this reason, you should keep data archives separate from
features and build them separately. Consider these scenarios:

  Your feature contains a DLL that needs to be registered with the Windows
  registry as part of the installation.
  Your feature contains updates for non-Eclipse applications
  Your feature contains other information for updating the Windows
  registry etc.

Note also that all these things listed above must be done BEFORE you
restart Eclipse. If you carry data in a plug-in/bundle, they are not
installed yet at the time you need them, therefore you cannot call runtime
to give you their location and otherwise use runtime to give you resolved
paths.

Regards,

Dejan Glozic, Ph.D.
Manager, Eclipse Development 1A
D1/R0Q/8200/MKM
IBM Canada Ltd.
Tel. 905 413-2745  T/L 969-2745
Fax. 905 413-4850




            Mark_Melvin@amis.
            com
            Sent by:                                                   To
            platform-update-d         platform-update-dev@xxxxxxxxxxx
            ev-bounces@eclips                                          cc
            e.org
                                                                  Subject
                                      [platform-update-dev] How To Use
            02/01/2007 05:24          Non-Plugin Feature Data
            PM


            Please respond to
            "Eclipse Platform
            Update component
            developers list."
            <platform-update-
            dev@xxxxxxxxxxx>







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.
_______________________________________________
platform-update-dev mailing list
platform-update-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-update-dev


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

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.

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




Back to the top