Re: [p2-dev] P2 provisioning without existing profile

[Pascal Rapicault <pascal@xxxxxxxxxxxx>]

Unfortunately this represents a breaking change in the API which would affect a lot of clients including the SDK itself.
What I don't quite grasp is why can't you do the typical
	IProfile p = pr.getProfile("MyProfile");
	if (p == null)
		p = pr.createProfile("MyProfile");

Last summer I did some experiments in the space of "taking over" an existing instance that was not p2-ified (no profile / profile registry). Basically the idea was that a user would install the p2 bundles in a running osgi and would start using p2 to manage this instance. To do this, rather than modifying existing code I wrote a new bundle (1) which would create a p2 profile and populate the profile by reading what was installed in the OSGi. Once this operation was complete (which was more or less a one time shot), then any p2 operation could be done.
Some of the difficulties with this approach are:
- Finding the roots: is each a bundle a root? 
- Which locking policy to apply to the roots: are they marked optional or marked strict?
	- Those two combined affect the upgradeability.

Is this what you are after?

PaScaL

(1) org.eclipse.equinox.p2.afterthefact. CVS: /cvsroot/rt/org.eclipse.equinox/incubator/p2/bundles/org.eclipse.equinox.p2.afterthefact 
Note that this bundle compiles against HEAD however it may not run at all as I have not pursued this effort since last summer.


On 2010-05-20, at 3:15 AM, Todorova, Katya wrote:

> Hi guys, 
> 
> We are trying to install OSGi product using external p2 agent. The product initially doesn't have a profile. This causes a lot of issues during installation since the p2 infrastructure relies on profile existence. 
> Maybe in this case it's reasonable to start from empty profile and sequentially add each of the features which we would like the system to have. Thus after initial p2 installation we will end up with consistent profile describing the system. 
> It is very easy to integrate such change into currently existing code (it would affect just several lines in SimpleProfileRegistry):
> 
> public synchronized IProfile getProfile(String id) {
> 	Profile profile = internalGetProfile(id);
> 	//new code
> 	if (profile == null){
> 		try {
> 			return  addProfile(id);
> 		} catch (ProvisionException e) {
> 			return null;
> 			}
> 	}
> 	//end of new code
> 	return profile.snapshot();
> }
> 
> Of course, there may be other use cases in which the user would expect null when requested profile doesn't exist.
> So to handle both cases it is worth considering a new property or an additional parameter which is reponsible for that decision.
> 
> What do you think? 
> 
> Thanks in advance, 
> Katya
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev