Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] P2 Profiles and IDirector


In 3.4, PDE Build generate a p2 repository for the product, but did not automatically perform a p2 install which would result in the p2 folder.

To get this you would need to invoke the director yourself as a custom step at the end of the build.

There is an example of a 3.4 build here:
http://aniefer.blogspot.com/2008/06/example-headless-build-for-rcp-product.html



From: Pascal Rapicault/Ottawa/IBM@IBMCA
To: P2 developer discussions <p2-dev@xxxxxxxxxxx>
Cc: P2 developer discussions <p2-dev@xxxxxxxxxxx>, p2-dev-bounces@xxxxxxxxxxx
Date: 01/20/2010 12:25 PM
Subject: Re: [p2-dev] P2 Profiles and IDirector
Sent by: p2-dev-bounces@xxxxxxxxxxx





> We use the 'simple' PDE build to create an executable application.
> Thus we do not provide a profile name or create one.
  Since 3.4 PDE has the ability to create p2-enabled application and I think it is the default in 3.5. Exporting with PDE would generate you a profile automatically using the id of the product as profile id. To know if an application is p2 enabled, see if there is a p2 folder at the root of the install.

> that we have to work with RCP applications deployed in times where
> P2 did not exist. So the question is how can I use p2 to install or
> update these applications?
This is not an officially supported scenario but believe it should be possible. To avoid the cluttering of the config.ini with the list of all the bundles to be installed you will likely want to add to the application the org.eclipse.equinox.simpleconfigurator bundle. Note that it could be added on the first provisioning operation you are performing on the system. Make sure also to have the proper configuration unit to have simpleconfigurator started.
When there is no p2 profile, the first thing to do is generate one. This is done in two steps, 1) generate metadata for the installation (use the p2 publisher to do this, see for example the
FeaturesAction and BundlesAction classes) 2) take all the metadata generated and store it in the profile (this can be seen in the p2.afterthefact bundle). Of course you will need to have a profileRegistry to store your profile and you can choose to store whereever you like.


> This profile is typically located in <folder>/p2/
> org.eclipse.equinox.p2.engine/profileRegistry/<profileId> This
> folder should also be referenced from the application config.ini and
> so should be the profile id.
> That's a bit confusing. The way we managed to create a profile is:
>
> ...
> public void bindProfileRegistry(IProfileRegistry registry) {
> this.profileRegistry = registry;
> }
> ...
>
> String location = new File("/Users/me/Projects/P2/installdir", "testprofile"
> ).toString();
> Map<String, String> props = new HashMap<String, String>();
> props.put(IProfile.PROP_INSTALL_FOLDER, location);
> props.put(IProfile.PROP_CONFIGURATION_FOLDER, location);
> props.put(IProfile.PROP_CACHE, location);
> props.put(IProfile.PROP_SHARED_CACHE, location);
> // props.put
> (IProfile.PROP_ENVIRONMENTS,"osgi.os=win32,osgi.os=win32,osgi.arch=x86");
> props.put(IProfile.PROP_FLAVOR, "tooling");
> profileRegistry.addProfile("testprofile", props);
>
> So what I am looking for is a reliable possibility to find out the
> user's profile and the directory where I can install new features.
> Say I will install a new feature in a remote server application. How
> can I find out which profileID and install directory I have to use?
The complete logic would be:
1) find install folder
2) find the configuration/config.ini file
3) in config.ini, check the value of eclipse.p2.data.area and eclipse.p2.profile
3 a) if those properties are not set, it likely means that your application is not p2 enabled, so you will need to generate a p2 profile then go to 4)
3 b) if those properties are set, then go to 4)
4) get the
IProvisioningAgentProvider service, and create an agent at the location specified in eclipse.p2.data.are
5) now that you have an IProvisioningAgent, get the profile registry service and get the profile specified in eclipse.p2.profile


>From there on you get the planner and engine services from the provider.


>
> Am Jan 18, 2010 um 16:59  schrieb Pascal Rapicault:
>
> > 1. Profiles: how exactly do I use profiles for install procedures?
> > Say I have provisioned (not necessary with P2) my RCP application to
> > some customer PCs. Now I want to remotely update these RCP-clients
> > and e.g. install a new feature. Say I am able to connect with these
> > clients and execute remote calls.
> > - Is there a default profile each customer has where I have to
> > install my new features?
> Each application is the result of a provisioning operation that has
> happened at some point or another. For example if the user just
> unzipped a zip, this zip mostly likely result from a provisioning
> operation that occurred at build time, consequently it contains a
> profile. This profile is typically located in <folder>/p2/
> org.eclipse.equinox.p2.engine/profileRegistry/<profileId> This
> folder should also be referenced from the application config.ini and
> so should be the profile id.
>
> > - Or do I have to create a new profile for my new features I want to
> > add? If so, I do not know the customer's disk layout, so how do I
> > know where to create the new profile?
> If the installation did not had a profile, you could generate one
> profile on the fly but we usually don't recommend this approach as
> this usually leads to some loss of precision.
>
> > 2. IDirector and dependencies: To install a new feature I have to
> > provide the repository URL and the featureID:
> >
> > metadataRepositoryManager
> > .addRepository(new URI(repositorylocation));
> > artifactRepositoryManager
> > .addRepository(new URI(repositorylocation));
> >
> > ...
> >
> > Query query = new MatchQuery() {
> >
> > @Override
> > public boolean isMatch(Object object) {
> > IInstallableUnit candidate = (IInstallableUnit) object;
> > System.err.println(candidate.getId());
> > //  FEature to install
> > return candidate.getId().equals(
> > "org.eclipse.epp.usagedata.feature.feature.group");
> > }
> > };
> >
> > Collector collector = new Collector();
> > Collector test = metadataRepository.query(query, collector,
> > new NullProgressMonitor());
> >
> > ....
> >
> > In case my feature has dependencies to other plug-ins (not
> > features!) which are located in a different repository. When I
> > create a feature project I can define on the dependencies-tab which
> > plug-ins my feature depends on. How does P2 know where to download
> > these dependencies? Do I have to provide P2 an additional
> repositorylocation?
> The repositories needed must be added to the repository manager.
> However if these other repositories are referred to (and marked
> enabled) from the repository you initially add, then they will be
> automatically added to the repository manager. In the XML, it looks
> like that. This snippet causes the addition of a metadata repository
> (type = 1 and enables it options = 1) and then adds the artifact repository.
> <references size='4'>
> <repository url='' type='1' options='1'/>
> <repository url='' type='0' options='1'/>
> </references>
>
> Now if you are grabbing
http://download.eclipse.org/eclipse/
> downloads/drops/I20100115-1100/index.php you may want to look at the
> org.eclipse.equinox.p2.operations bundle which aims at simplifying
> the installation process. This build is the first one to contain our
> the first cut at an API. Feedback welcome.
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/p2-dev
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
>
https://dev.eclipse.org/mailman/listinfo/p2-dev_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev



Back to the top