| Eclipse 3.5 Update Site / p2 issues [message #599911] |
Mon, 27 July 2009 14:56 |
 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.01507 seconds
] 
Search
Help
Register
Login
Home
