| Update Site Issues in Eclipse 3.5 [message #337071] |
Sun, 26 July 2009 06:59  |
 Troy Nichols
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Copy/Pasting from original query in eclipse.platform since this might be
the better forum for these questions...
========
Hello!
We have a project that consists of one feature containing about 20 plugins
and we would like to provide an update site for distributing patches to
users. We have recently migrated the whole project from Eclipse 3.3 to
Eclipse 3.5, and have run into some issues with the p2 provisioning system
regarding how to make the update site work.
So I have 3 questions:
1. Are there any disadvantages to NOT using a p2 update site? Can we
continue to use the classic update site format (i.e. just site.xml +
features and plugins dirs) without any trouble, or is it a better idea to
just jump right into a p2 update site? What are some
advantages/disadvantages, if any?
2. We currently have a standalone installer that installs the product into
a so-called "extension location", which is linked to an eclipse instance
via .link files. It seems that post 3.4, update manager/p2 does not
support installing updates into extension locations (see:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=224145). Has anyone else
run into this problem? Is there some workaround to get this to work? Can
the provisioning system be extended to allow us to manage installation
locations as developers?
3. Each time we build the product in our automated build process, the
plugins/feature get a new qualifier version (e.g. 1.5.0.200907241000). So
if we update only one plugin (which in turn causes the containing feature
version to be bumped up, let's say from 1.5.0 to 1.5.1), is there some way
to configure the update manager to ignore differences in the qualifier,
such that if it finds version 1.5.0.200907241000 installed on the system
and 1.5.0.200907265000 available on the update site, it will NOT download
the changes? This is necessary because even though only one plugin really
changed, they ALL now have new qualifier numbers because they were *all*
rebuilt. In other words, I only want the update manager to be aware of
the a.b.c versioning, not the a.b.c.dddd versioning. Or is this something
that I need to enforce in the configuration of the feature?
Thanks for any advice on any of these topics!
Troy Nichols
|
|
|
|
Powered by
FUDForum. Page generated in 0.03184 seconds
] 
Search
Help
Register
Login
Home
