[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] policy.xml Replacement?


> So eclipse.org projects (post M7) should remove their <update> (and
> <discovery> too?) URLs in their feature.xmls?


I don't think projects should make such a last minute change in the Galileo release cycle. Conceptually, the problem with putting the data here is that it tightly couple's the feature producer's viewpoint into the feature. If someone else wants to redistribute that feature, but change the site their users obtain it from, they don't want this URL appearing to *their* users. We address this problem in p2 by not copying this URL into the p2 metadata for that feature. Thus someone can now redistribute that metadata without it being tainted with the producer's view of where updates should come from (we instead store that information as a property of the repository itself). However, this attribute in the feature.xml is still useful as a "hint" about where updates could come from. Some distributors may not care about overriding where the updates for that feature come from, so they would be happy to go with some reasonable default. If everyone removed these URL's from their features, we would need a replacement story about how to publish this information, which we don't have today. So, I wouldn't recommend people change anything here right now.

The other point you raise about 20+ URLs appearing in the Galileo repository is something we've struggled with. When we initially added all 20+ sites "for free", there was a huge cost to loading all those repositories when the user first opened a p2 wizard. This is why we created the "disabled" state as a compromise - the sites are available, but turned off by default until a user decides to enable it. We've made it a bit easier to "discover" these disabled sites in 3.5 by adding them to the auto-complete feature in the p2 install wizard. As you point out there's a tradeoff here -if we don't provide these URLs then end users have more difficulty tracking down the repository locations they need. If we do add them, it can be a bit overwhelming in the context of Galileo because there are so many of them. Any suggestions on how to improve this experience are welcome.

John




Nick Boldt <nickboldt@xxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

05/09/2009 05:47 PM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
Re: [p2-dev] policy.xml Replacement?





> I think that for the features you are in control of, it is a good
> practice to get rid of the URL in the features.

So eclipse.org projects (post M7) should remove their <update> (and
<discovery> too?) URLs in their feature.xmls?

How will those installed features know where to go for updates, if not
from the feature.xml? Will they simply refer back to the location from
which they were installed - be it http:, file: or jar: ?

If a project is installed from, say, the Galileo site initially - for
example, EMF 2.5.0 - and the user wants to update to 2.5.3, which is
released AFTER the Feb 2010 release of Galileo SR2, will the user have
to manually add that URL? If the installed features refer back to only
the location from which they were installed, updates on another site
will not be found.

Of course the bonus here is that upon searching the Galileo site the
first time, 20+ extra update sites won't magically appear in the list of
sites. Is that a bonus, or a tragic flaw? Is it better to force users to
hunt down URLs themselves, or to overpopulate their list w/ sites they
may never use?

Or have I completely misunderstood the rationale and effect of removing
these URLs?

--
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev