Re: [pde-dev] Target Platform question

[Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>]

The scenario that drove the addition of the check box was essentially what I said previously: mimic the zip files. In that scenario, picking from a range or getting things that are not included in the zip does not make sense. I completely agree that, for example, doing multi-platform means that requirements are not followed is a bummer. It would be great to work towards that in Indigo. As mentioned, the PDE guys are likely up for that discussion soon after Helios (I'm speaking out of turn but am hopeful :-)

As for the use of ranges for includes, I think this will be a problem going forward.  For example, Helios ships.  The repo has one version of the EMF bundles (say that EMF uses this "includes a range" approach).  You install EMF 2.6.0 in your IDE.  In Sept we ship Helios SR1 and EMF has a new version of some bundles, say 2.6.1. If the EMF 2.6.0 feature IU had requirements using a non-exact range, then users doing any provisioning operation will likely end up with an update of EMF content even though the EMF feature may not get updated. Or similarly, someone installing EMF 2.6.0 the day before SR1 will get a different install than someone installing that same exact feature the day after SR1. In short, our installs will not be reproduceable.

I'm hoping I'm missing something as this seems like a pretty bad problem.  It basically means that we can never operate reliably in an environment were there are multiple versions in a repo. 

Jeff

On 2010-05-28, at 4:20 PM, Thomas Hallgren wrote:

> Hi Jeff,
> 
> I understand the need to support conventions that has been around for a very long time. I'm not at all suggesting that this should stop. My reaction is more to why this has to dictate the behavior for a brand new target platform provisioning in a way that prevents us from exploiting p2 beyond what the old UM could do. I don't think it needs to be that way.
> 
> The problem as I see it is twofold. One is the phrasing "Include required content", the other is the assumption derived from the strict version ranges. I understand that the latter was added as a best guess to accomplish the former.
> 
> To me, the checkbox is about planning strategy. I.e. should the p2 planner be used, or a permissive slicer. The choice for me has always been the latter because that's the only way that allows me to provision a platform independent target. I couldn't care less about if the original requirement stems from a feature, a bundle, or something else. So to me it's a real bummer that this choice also implies that only strict dependencies are traversed.
> 
> I would like a choice that results in use of the permissive slicer with the considerOnlyStrictDependency = false and I think that will work very well for most people. Sure, the resulting target platform might contain some bundles that are not strictly needed for a build, but then again, it's very likely that you do need them in order to run self-hosted. I think such a choice would be a much better compromise then the current one until a more elaborate solution has been put in place. It makes no assumptions about conventions used when publishing. It just works. Both for running self-hosted and for publishing platform independent sites.
> 
> Going forward, I think we should make use of the greedy attribute. I can't really see the reason why we don't use that for feature requirements.
> 
>> For context, do you know of many projects other than the EMF folks who are using this approach of mapping inclusions to version ranges?
>> 
>>   
> All projects built using Buckminster can use this approach. I know for sure that Buckminster itself does. As does b3. I think some modeling projects still do. For projects outside of Eclipse, I don't know.
> 
> I know that all epp projects switch from using includes to using requires because they wanted the products to be updatable using p2. I've encountered that argument many times over the past year. You don't want your feature to freeze what's there and in case of common components, you want to avoid conflicts.
> 
> - thomas
> 
> _______________________________________________
> pde-dev mailing list
> pde-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pde-dev