[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Fw: [p2-dev] Using the new "sofware site" target provisioner

Others have a similar opinion. You can see a good discussion about this on 
the following bug:

        https://bugs.eclipse.org/bugs/show_bug.cgi?id=272750

Patches/comments are welcome.

Darin



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



I think the trick is to use the profile but skip the planner phase. This 
means that a the full closure of IU's must be computed in a different 
way but that's the only difference as far as I can tell. One simple way 
of doing the computation is to use the PermissiveSlicer to select the 
transitive closure of the selected top features. Once the set of IU's 
has been determined, an InstallableUnitOperand is created for each one 
and then the collect phase is executed as normal.

The result is an IBundleContainer that is polymorph, i.e. you don't need 
to reload it just because you change the target platform os/ws/arch.

The really interesting thing about this is that if such a container was 
present, there would be no need at all for the delta-pack. It would 
become obsolete in an instance. Just point to the platform repository at 
Eclipse.org and you're all set.

If you're interested, I can provide a patch that alters the current 
IUBundleContainer to do it this way. IMO, it would make the "Sofware 
site" provisioner a lot more useful.

- thomas


Darin Wright wrote:
> 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
>
>
>
> _______________________________________________
> 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