Eclipse Community Forums: Equinox » Equivalent of Update Policy for 3.4 & P2

Help

Home

Home » Eclipse Projects » Equinox » Equivalent of Update Policy for 3.4 & P2

Show: Today's Messages :: Show Polls :: Message Navigator

Equivalent of Update Policy for 3.4 & P2 [message #111816]

Thu, 12 June 2008 16:29

Miles Daffin

Messages: 86
Registered: July 2009

Member

Hi All,

In 3.2 & 3.4 I can use an update policy to control where an eclipse
install can obtain updates. We use this to ensure that all updates come
from our internal update sites. How do I do this in 3.4 with P2?

Also, I want to control the list of update sites that a user can see in
the update manager's list. (For 3.2 and 3.3 my custom ant installer
removes the discovery elements from all feature.xml files post install. It
then adds a bookmarks.xml file to
$ECLIPSE_HOME/configuration/org.eclipse.update. This contains links to our
internal sites.) How would I achieve this with 3.4 and P2?

Thanks,

Miles

Report message to a moderator

Re: Equivalent of Update Policy for 3.4 & P2 [message #111856 is a reply to message #111816]

Fri, 13 June 2008 01:58

Pascal Rapicault

Messages: 333
Registered: July 2009
Location: Ottawa

Senior Member

In p2 these two problems no longer occur because the provenance of an
InstallableUnit (the entity you install even though it still looks like a
feature) has nothing to do with where you need to get the update from. For
example I can install something from server X and find update on another
one, or never see again any update for it if I'm not connected to any site
containing relevant installation for it since IUs don't explicitly refer to
a site like feature use to.

So to control where the updates can be obtained, you just need to control
the set of repositories made available to your users. For now this is stored
as configuration level preference.

As for cleaning up features, this is no longer necessary since as I said IUs
don't have this information in them. That said you may want to check the
repositories resulting from the metadata generation since for backward
compatibility reason we had to gather the URLs specified in features and add
them to the repo (a repo can point at other repos). So in short you may have
to do some clean-up there.

Also if you want to control your users environment you may be interested in
not shipping with the reconciler.dropins which is implements the discovery
behavior (find plug-ins in dropins, etc).

PaScaL

"Miles Daffin" <miles.daffin@morganstanley.com> wrote in message
news:462f54e5904309855898b64a56e8722e$1@www.eclipse.org...
> Hi All,
>
> In 3.2 & 3.4 I can use an update policy to control where an eclipse
> install can obtain updates. We use this to ensure that all updates come
> from our internal update sites. How do I do this in 3.4 with P2?
>
> Also, I want to control the list of update sites that a user can see in
> the update manager's list. (For 3.2 and 3.3 my custom ant installer
> removes the discovery elements from all feature.xml files post install. It
> then adds a bookmarks.xml file to
> $ECLIPSE_HOME/configuration/org.eclipse.update. This contains links to our
> internal sites.) How would I achieve this with 3.4 and P2?
>
> Thanks,
>
> Miles
>

Report message to a moderator

Re: Equivalent of Update Policy for 3.4 & P2 [message #112017 is a reply to message #111856]

Fri, 13 June 2008 08:49

Miles Daffin

Messages: 86
Registered: July 2009

Member

Pascal,

Thanks for the information. I have a couple of questions.

> So to control where the updates can be obtained, you just need to control
> the set of repositories made available to your users. For now this is stored
> as configuration level preference.

How can I control this preference? Where is it stored? Can I modify it
programmatically?

> As for cleaning up features, this is no longer necessary since as I said IUs
> don't have this information in them. That said you may want to check the
> repositories resulting from the metadata generation since for backward
> compatibility reason we had to gather the URLs specified in features and add
> them to the repo (a repo can point at other repos). So in short you may have
> to do some clean-up there.

Where/what would I clean up and how?

Thanks,

Miles

Report message to a moderator

Re: Equivalent of Update Policy for 3.4 & P2 [message #112085 is a reply to message #112017]

Mon, 16 June 2008 02:02

Pascal Rapicault

Messages: 333
Registered: July 2009
Location: Ottawa

Senior Member

"Miles Daffin" <miles.daffin@morganstanley.com> wrote in message
news:a7604afb79d680b0f3d8074ebedec204$1@www.eclipse.org...
> Pascal,
>
> Thanks for the information. I have a couple of questions.
>
>> So to control where the updates can be obtained, you just need to control
>> the set of repositories made available to your users. For now this is
>> stored as configuration level preference.
>
> How can I control this preference? Where is it stored? Can I modify it
> programmatically?

It is stored in the configuration scope. See
MetadataRepositoryManager#restoreFromPreferences() and
ArtifactRepositoryManager#restoreFromPreferences(). However note that this
is not API :-)

>> As for cleaning up features, this is no longer necessary since as I said
>> IUs don't have this information in them. That said you may want to check
>> the repositories resulting from the metadata generation since for
>> backward compatibility reason we had to gather the URLs specified in
>> features and add them to the repo (a repo can point at other repos). So
>> in short you may have to do some clean-up there.
>
> Where/what would I clean up and how?

In the metadata repository file (e.g. content.jar / content.xml), see if
there is a reference section resembling this:
<references size='64'>

<repository url='http://download.eclipse.org/dsdp/dd/updates' type='1'
options='0'/>

<repository url='http://download.eclipse.org/dsdp/dd/updates' type='0'
options='0'/>

<repository url='http://download.eclipse.org/datatools/updates' type='0'
options='0'/>

<repository url='http://download.eclipse.org/datatools/updates' type='1'
options='0'/>

<repository url='http://download.eclipse.org/webtools/updates/' type='1'
options='0'/>

<repository
url=' http://download.eclipse.org/modeling/gmf/update-site/release s/site.xml'
type='0' options='0'/>

<repository
url=' http://download.eclipse.org/modeling/gmf/update-site/release s/site.xml'
type='1' options='0'/>

and for artifact repository (if you want to control the server from which
the bytes are obtained) see the artifacts.jar / artifacts.xml file and
search for a property named "p2.mirrorsURL" (e.g.a<property
name='p2.mirrorsURL'
value=' http://www.eclipse.org/downloads/download.php?file=/releases /ganymede/&format=xml&protocol=http'/>)

In this case you may want to replace the specified server by one of yours.

PaScaL
>
> Thanks,
>
> Miles
>

Report message to a moderator

Re: Equivalent of Update Policy for 3.4 & P2 [message #112597 is a reply to message #112085]

Thu, 26 June 2008 16:36

Miles Daffin

Messages: 86
Registered: July 2009

Member

>>> So to control where the updates can be obtained, you just need to control
>>> the set of repositories made available to your users. For now this is
>>> stored as configuration level preference.
>>
>> How can I control this preference? Where is it stored? Can I modify it
>> programmatically?

> It is stored in the configuration scope. See
> MetadataRepositoryManager#restoreFromPreferences() and
> ArtifactRepositoryManager#restoreFromPreferences(). However note that this
> is not API :-)

OK. Sorry to be so obtuse, but I do not know how to interpret your
references. Is this documentation? Where do I look?

Thanks,

Miles

Report message to a moderator

Re: Equivalent of Update Policy for 3.4 & P2 [message #113684 is a reply to message #112597]

Wed, 09 July 2008 03:23

Pascal Rapicault

Messages: 333
Registered: July 2009
Location: Ottawa

Senior Member

Sorry this is referring to classes#methods in the p2 code.
It is in the org.eclipse.equinox.p2.metadata.repository plugin

"Miles Daffin" <miles.daffin@morganstanley.com> wrote in message
news:98070f9a8be372e69ed54bf38158ff00$1@www.eclipse.org...
>>>> So to control where the updates can be obtained, you just need to
>>>> control the set of repositories made available to your users. For now
>>>> this is stored as configuration level preference.
>>>
>>> How can I control this preference? Where is it stored? Can I modify it
>>> programmatically?
>
>> It is stored in the configuration scope. See
>> MetadataRepositoryManager#restoreFromPreferences() and
>> ArtifactRepositoryManager#restoreFromPreferences(). However note that
>> this is not API :-)
>
> OK. Sorry to be so obtuse, but I do not know how to interpret your
> references. Is this documentation? Where do I look?
>
> Thanks,
>
> Miles
>

Report message to a moderator

Previous Topic:	[p2] Updating while keeping constraints satisfied
Next Topic:	[P2] Provisioning the target

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 14:08:04 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter