Re: Fw: [p2-dev] Using the new "sofware site" target provisioner

[Darin Wright <Darin_Wright@xxxxxxxxxx>]

I agree with your points - PDE could provide a better multi-platform 
deployment story.

Just to clarify - the software site target provisioner is providing new 
function that simplifies certain development scenarios. It does not solve 
the multi-platform deployment problem. Simply changing the target 
provisioner to use a "repo2runnable, non-p2-profile implementation" does 
not solve the problem either. There are other pieces of the problem that 
need to be solved - for example, root files that the delta-pack currently 
contains. Moving forward (read post 3.5), enabling the software site 
provisioner to download all fragments for all OS's (and NL's, etc.), 
likely will be part of the overall solution of a better multi-platform 
deployment story.

Darin 



From:
Thomas Hallgren <thomas@xxxxxxx>
To:
P2 developer discussions <p2-dev@xxxxxxxxxxx>
Date:
05/01/2009 05:27 AM
Subject:
Re: Fw: [p2-dev] Using the new "sofware site" target provisioner
Sent by:
p2-dev-bounces@xxxxxxxxxxx



Hi Darin,
I think the current approach has some implications that are hard to 
overcome. An example:

The org.eclipse.jdt.launching.macosx bundle is not part of the delta-pack. 
It is however included in of one of my features. If the "Software site" is 
controlled by a profile, then it becomes impossible for me to build a 
target definition that includes this bundle unless I perform some fairly 
tricky acrobatics.

The same is of course true for all platform specific bundles and fragments 
that are not included in the delta pack. A "Software site" becomes useless 
in a multi-platform scenario unless all plug-ins and fragments can be 
copied regardless of the current platform settings. Well, regardless of 
filtering in general actually, since we also want all language fragments 
etc.

IMO, there should be very little difference between what a developer and a 
build-meister can accomplish. The tools now provided out-of-the-box makes 
it possible for any developer to publish a P2 site. That makes the Multi 
Platform scenario a very common case. I would therefore strongly suggest 
that the "Software site" logic changes approach and instead uses the one 
taken by the repository tool 'repo2runnable' used by the releng team. Not 
doing so will limit its usefulness in a way that is unfortunate.

As a side-note, Buckminster just went through the same motions after 
discovering the limitations in using a profile when doing the target 
platform provisioning. We now mirror all artifacts and we don't consider 
the meta-data at all.

Regards,
Thomas Hallgren


Darin Wright wrote: 
Hi Darin,
I tested this and made the following observations:

I stared by trying to add a "Sofware Site". I deliberately omitted to 
specify os/ws/arch. The result of this omission was that my platform 
defaults were used. That's not what I wanted. I need a platform that I 
can use for publishing features into a P2 repository. The features 
includes fragments from all possible platforms.
 

A target definition referencing software sites is backed by a p2 profile. 
A profile is os/ws/arch specific. A target *definition* can take on a 
specific os/ws/arch by specifying them explicitly or it can take on the 
settings of the os/ws/arch it is installed in (by leaving them 
unspecified). A target *platform*, or state (the result of resolving a 
target definition) is os/ws/arch specific, as it always has been.

 
Although you write that it doesn't make much sense, I still attempted to 
 

 
complement my target platform with a "Directory" where I had the 
delta-pack feature and tried again. Now, when it loads things from the 
"Software Site", I can see that it downloads the artifacts that are 
already present in the delta-pack (I can see them by checking the "Show 
Plug-in Content"). Wouldn't it be more efficient to let all types share 
a common bundle pool?
 

The delta pack works as before - you add it as separate directory. It is 
true that there is some duplication between the delta pack and what gets 
downloaded to the bundle pool. This was causing some trouble when 
launching targets in the M7 test pass build (but has been fixed - see bug 
274225). When resolving a target platform (i.e. build state) from a 
definition, duplicate bundles are now rolled into one. The net result is 
that a definition can point to arbitrary sources of bundles where 
duplicates exist, but the resulting target state will only contain one.

The profile maintained for a target definition only contains IU's that are 

specified from software sites. The additional locations (directories, 
etc.), are not installed into the profile since we do not (necessarily) 
have metadata to install them.

 
Using a profile to manage a target platform doesn't sound right to me 
but perhaps I got it all wrong in respect to how to set up a target 
platform. What is the recommended approach given my requirements?
 

The end result is that we use a profile to manage the software sites 
contained in a definition - the entire target is not maintained in a 
profile. For this reason, you use the delta pack the same as before.

Moving forward, perhaps we can find some better ways to manage the 
multi-platform scenarios. However, I think there is a difference between 
development and deployment that should be noted here. Developers often use 

target definitions/platforms to develop for a specific platform, whereas 
build-meisters want to use them to deploy for all platforms.

Darin

_______________________________________________
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