Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » Eclipse 3.5 Update Site / p2 issues
Eclipse 3.5 Update Site / p2 issues [message #69118] Mon, 27 July 2009 14:56 Go to next message
Troy Nichols is currently offline Troy NicholsFriend
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

Report message to a moderator

Re: Eclipse 3.5 Update Site / p2 issues [message #479385 is a reply to message #69118] Mon, 10 August 2009 20:10 Go to previous messageGo to next message
Curtis Windatt is currently offline Curtis WindattFriend
Messages: 166
Registered: July 2009
Senior Member
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.

Report message to a moderator

Re: Eclipse 3.5 Update Site / p2 issues [message #600469 is a reply to message #69118] Mon, 10 August 2009 20:10 Go to previous message
Curtis Windatt is currently offline Curtis WindattFriend
Messages: 166
Registered: July 2009
Senior Member
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.

Report message to a moderator

Previous Topic:Re: Modifying plugin.xml
Next Topic:Support for other OSGi runtimes (Apache Felix, Knopflerfish, ...)
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Sat Apr 20 03:12:14 GMT 2024

Powered by FUDForum. Page generated in 0.03065 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly