[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [p2-dev] P2 and Presence of site.xml
|
Thanks for the responses, guys. I'll obviously do
some testing, but it sounds like I don't need to change my URL at the last
minute (which is a good thing!). Our support for the old update manager
will be very short-lived anyway now that we're onto P2.
Regards,
Mark.
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