| Eclipse 3.5 Update Site / p2 issues [message #69118] |
Mon, 27 July 2009 10:56  |
Eclipse User |
|
|
|
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
|
|
|
|
| Re: Eclipse 3.5 Update Site / p2 issues [message #600469 is a reply to message #69118] |
Mon, 10 August 2009 16:10  |
| Eclipse User |
|
|
|
1) The p2 update UI does read the old format (site.xml). The site.xml and p2 metadata repo can also coexist.
It is reasonably straightforward to create a p2 repo when building an update site (the PDE UI does this for you by default), you just need set a few more options for PDE build.
The p2 repo contains a lot more information than the site.xml, so there isn't any reason I can think of to NOT create it. If your project can be installed in Eclipse <3.4 you will need to provide a site.xml so that update manager can install it (p2 was added in 3.4)
2) You will need someone from p2 to answer you, so you might be better off trying their newsgroup.
3) Everything that is rebuilt will get a new qualifier, but I would expect there is a way to avoid buliding plug-ins that haven't changed. I don't know how to do this though, as I'm not very knowledgeable about PDE Build.
|
|
|
Powered by
FUDForum. Page generated in 0.03285 seconds
Home