[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] P2 and Presence of site.xml


What Ian is talking about is just an optimization that p2 makes to avoid the cost of discovering the repository type. Determining the repository type can take several extra round-trips that we don't want to do on every repository interaction. Once p2 discovers the repository type, it "remembers" what type was found, and will try that format first on the next interaction with that repository. If the remembered repository type is not found, it resorts to doing a regular repository discovery again (iterate through the repository types until it finds a match). And yes, doing a "test connection" does throw away this cached information.




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

07/14/2009 02:19 AM

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

To
P2 developer discussions <p2-dev@xxxxxxxxxxx>
cc
Subject
Re: [p2-dev] P2 and Presence of site.xml





IMHO, searching site.xml BEFORE artifacts.xml/.jar & content.xml/.jar is
a bug, not a feature.

If it knows there's a site.xml at example.com, but the next time it
checks the site.xml is gone, will it then check for artifacts & content?
Or just give up?

If the end user hits 'Help > install new software > available software
sites > test connection' for the site, would that force p2 to check in
newest-format-then-oldest-format order?

N

Ian Bull wrote:
> Nick is almost right, but there is one small gotcha to watch out for.
>
> p2 loops through the different types of sites, in order (not sure
> exactly what that order is), but it gives precedence  to previous
> repository types it has seen.
>
> So if it has seen a site.xml at http://example.com before, then it will try
> http://example.com/site.xml first.  If this fails, then it will move on.
>
> cheers,
> ian
>
> On Mon, Jul 13, 2009 at 6:58 PM, Nick Boldt <nickboldt@xxxxxxxxx
> <mailto:nickboldt@xxxxxxxxx>> wrote:
>
>     Simply, if artifacts.{xml|jar} and content.{xml|jar} is found at the
>     URL, site.xml is ignored.
>
>     So you can have an Eclipse 3.4+ site in the same location as an
>     Eclipse 3.3- site, and control who sees what by virtue of the
>     version of Eclipse looking at the site.
>
>     To force an Eclipse 3.4+ user to see the 3.3- site, suffix the URL
>     w/ site.xml and they'll get that instead of artifacts and content
>     (.xml or .jar).
>
>
>     Mark Melvin wrote:
>
>         Hi There,
>
>         We are going to have to start thinking about our corporate
>         update site
>         soon and I just realized that we are going to have old, non-P2
>         installs
>         out there pointing to the same update URL as our new, P2-based
>         product
>         and I'm wondering what the side-effects are going to be for our
>         P2-based
>         product.  I seem to recall reading somewhere that P2 does "different
>         stuff" based on whether or not a site.xml is present.  In
>         particular, I
>         think what I read was something about how categories are shown
>         in the
>         UI.  I was wondering first of all, if this was true and second,
>         if there
>         are other bits of behaviour that will be different if P2 detects a
>         site.xml.
>
>         Also, is it possible to have a P2 repository located at the same
>         URL as
>         a legacy update site (containing a site.xml) where the P2 repositor
>         describes a completely different set of features and plugins as
>         the old
>         site-xml-based update site?  Or is the presence of a site.xml
>         going to
>         make P2 simply use it and ignore any P2 repository that may be
>         there.
>
>         I'm asking because it may be too late to change our URL in the
>         new P2
>         product, and I'll need to figure out a solution (perhaps moving
>         the old
>         site.xml-based update site and forcing legacy users to manually
>         enter a
>         policy file URL or something).
>
>         Thanks,
>         Mark.
>         _______________________________________________
>         p2-dev mailing list
>         p2-dev@xxxxxxxxxxx <mailto:p2-dev@xxxxxxxxxxx>
>         https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>
>     --
>     Nick Boldt :: http://nick.divbyzero.com
>     Release Engineer :: Eclipse Modeling & Dash Athena
>
>     _______________________________________________
>     p2-dev mailing list
>     p2-dev@xxxxxxxxxxx <mailto:p2-dev@xxxxxxxxxxx>
>     https://dev.eclipse.org/mailman/listinfo/p2-dev
>
>
>
>
> --
> R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
> http://eclipsesource.com | http://twitter.com/eclipsesource
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev

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