[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[p2-dev] Re: [cross-project-issues-dev] Question concerning feature update site URLs...

Sorry, should have been more clear. JBoss Tools is *NOT* part of Helios. We're downstream from Web Tools, TPTP, BIRT & m2eclipse.

I'm only pointing out what we do from an ease of use / maintenance point of view, because these URLs are not even seen until AFTER the features are installed, and because by providing them they stick around forever (and must therefore be maintained too).

Since the platform provides the URL for Helios, and since you're in Helios, there's no reason to provide the same information again.

Even if you wanted to force a particular feature to believe that it should be updated from some other site than whence it came, I'm fairly certain that if you have multiple update sites listed in Eclipse, and each site contains a given feature update on them (eg., Helios official one, Your Project official one, someone else's patched version), p2 will read all the enabled sites and present you the latest version, regardless of what the installed feature's feature.xml says is its One True Update URL. I don't believe p2 has a notion of site or package version "priority", a la Debian's apt-get [1].


So if you wanted to install an update to the Foo Feature from the official Helios 1.0.0 version to 1.0.1.patched.by.someone.else, you'd have to first disable the Helios and project sites, then run an update from that single site. Or, if using install instead of update, you could uncheck the "Contact all update sites" box so only the single site would be seen.

Copying the p2-dev list for comment in case I'm way off kilter here.


On 04/22/2010 09:13 AM, Eric Gwin wrote:

So the discovery and update URLs aren't required for Helios? I only
included them because it seemed they were for Galileo, and there was
some policy regarding where they should point - something like: update
to Galileo P2, and discovery to project update but I cannot find the

If these are only utilized by the install, then it sounds like it would
be completely unused for an RT library (target platform), so I should
probably simply drop them as well.


Nick Boldt wrote:
We recently dropped both <update> and <discovery> from our features in
JBoss Tools, because in order to have the user see these URLs, they
have to first install the feature (from a mirror site or zip), thus
negating the need to advertise where the feature came from.

<discovery> gets added *when the feature is fully installed* as a
_disabled_ update site

<update> gets added *when the feature is fully installed* as an
_enabled_ update site; if it's the same URL as the site from which the
feature was installed, it's therefore redundant.

A better approach, if you want to force the user to get p2 repos added
as associate sites *when reading the repo*, rather than *after
installing the feature*, then read this:


The actual magic is simply to append some information into the
content.xml file - see "add.associate.sites" task in


On 04/20/2010 10:56 AM, Eric Gwin wrote:

I'd like to ask a few questions to the group regarding P2 repo and
feature generation:

What are the expected values for the repo URLs used in the features?
<update label="%updateSiteName" url="%primaryUpdateURL"/>
<discovery label="%secondaryUpdateSiteName" url="%secondaryUpdateURL"/>
From experience it can be any valid URL, and specifically a valid
update site. I'm asking what I should
be putting in there since I am only generating the features once and the
repos are mirrored from our
project update site(s) to our simultaneous release update site.

-- Nick Boldt :: http://nick.divbyzero.com Release Engineer :: Eclipse Modeling & Dash Athena