Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Obscure org.eclipse.platform dependencies? Where are they?


I just realized one big source of confusion here. I'm actually talking about the xproject-platform definitions, i.e. as imported in my project:

import -Declipse.download="file:/home/data/httpd/download.eclipse.org" "${checkout.location}releng/org.eclipse.amp.releng/releng/amp-platform.mspec"

while using the standard:

setpref targetPlatformPath="${WORKSPACE}/buildroot/target.platform"

as opposed to specifying an explicit pre-built target platform.

On Nov 18, 2010, at 4:29 PM, Miles Parker wrote:


Yes I agree with the central thrust of all of that, and take the point that the performance tradeoff for copying target platform isn't worth the cost. I'm really more concerned with the dependency issue and how we could share/integrate the work maintaining the Buckminster artifacts as much as possible.

I'd love to just worry about P2, but the issue that we've run into is that targetPlatform which orthogonal to IDE environment, is orthogonal to workspace and is orthogonal to dynamically obtained P2 update site dependencies and they are all provisioned in very different ways.  That sounds obvious, but as we've discussed on the Buckminster forum it creates a lot of opportunity for cognitive dissonance. And for Buckminster builds, it means that everyone needs to maintain a target platform cspec and rmap as well as their project specific artifacts, etc... (They can combine them of course but that isn't a great idea either.)

Just because a project is able to create a built P2 does not mean that you can create a runnable target platform from it when combined with your own target platform dependencies, and it is really difficult to diagnose problems when they don't match as I once again found.  For example, if I'm consuming BIRT from their P2 site to build something and ProjectX is also consuming BIRT but from a different targetplatform using a different rmap, then they could produce a good P2 site but that built site might not be consistent with the rmap I'm using or dependencies that BIRT has. Because different projects are building to different target platforms, unless you copy your donor's rmap you aren't going to end up with the same target dependencies, but if you do you have the possibility of inconsistent dependencies and editing everything to match. The bottom-line is that someone changes their platform rmap, I have to go and figure out how *their* build works in order to get mine working again. I've spent a *lot* of time looking through other project's cspecs and rmaps as well as their analogs in other build systems.

I'm not really arguing that we should force everyone to use the Buckminster technology as would be required if the whole chain were using rmap'd target platforms... I was thinking about something much less ambitious, for example, we could have target platforms that correspond to Eclipse downloads. So I could simply set as my target platform the "Eclipse Indigo Modeling" and have access to all of those core dependencies. Or high-level like EMF Core, M2T/TMF/MWE, BIRT, etc.. Again, that is what everyone does on desktop and it works pretty well.

Or it could be even simpler. Basically I want a build time analog to the P2 metadata, and I was thinking that RMAP and CPEC artifacts could provide that. A neat feature of CBI was that it allowed projects to easily emit psf files. Those files could then be used to figure out what was needed in the consuming project's maps. Couldn't we perhaps do something like that, where a Buckminster action produces a candidate rmap and cspec for the *built* artifacts for each I build of a given Hudson job?

On Nov 18, 2010, at 1:14 PM, Thomas Hallgren wrote:

On 2010-11-18 21:54, Miles Parker wrote:
But many of us do have extra target platform dependencies -- it should certainly be possible to duplicate a target platform to each project and then provision just the additional pieces, right? -- that's what we do for local provisioning after all and it works great. Do the Buckminster folks have any thoughts about this?

My personal opinion is that target platforms are less then ideal for sharing between builds. I think that p2 repositories is a much better vehicle for that. After all, provisioning a TP from a repository is a quick and painless unless you have a slow network sitting in between. So to me a TP is a very intermediate and somewhat opaque part of the build.

Indigo is a huge aggregate of builds produced in +0 to +n (currently n = 3) steps. It would be possible to draw the whole thing as an directed acyclic graph starting with the sources used for the +0 and ending with the complete Indigo. Let's assume that each build consumes p2 repositories for everything except their own source and produces p2 nothing but p2 repositories. Between each +x and +x+1 there would be a composite repository witch children from the previous step and the product of the current step. +3 would then see a composite consisting of the produced repositories from +0, +1, and +2. The +3 composite would more or less be the Indigo repository although in a somewhat non-validated state.

Once nice thing about this approach is that it doesn't impose any special build technology on the projects involved. All build-systems used in Indigo today can consume and produce p2 repositories.

Regards,
Thomas Hallgren

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


______________________________
Miles T. Parker
President and Chief Software Architect
Metascape, LLC
Project Lead
Eclipse Agent Modeling Project

tel: 509-643-4441
skype: milestravisparker
______________________________


Back to the top