Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cbi-dev] CBI work, relation to dash-dev and Minerva

Hi Paul,

Thanks again for your thoughts and input regarding the CBI.

Others have expertise far outstripping mine in some of these areas but I'll get things started by sharing my thoughts below.


On 12/16/2011 08:16 AM, Paul Webster wrote:
Hi all,

1) how is our task/goal here related to what they're doing in dash-dev?  I see that the Dash project has been working on a number of maven [1] related build [2] support tools.  The already have a git repo at with an default eclipse parent  pom and an eclipse-signing-maven-plugin  There's also which is mentioned on the dash-dev list, but I'm not sure if some or all of it has moved to the dash git repo.

I'm checking this out to look into it for myself. I encourage others to comment to share their thoughts.

2) Has CBI decided on a way to expose Igor's work on building on the eclipse hardware?

At the moment, we're working with git submodules as a way to aggregate the platform repositories. It seems to be working fairly well for now. Once I've reproduced Igor's build (working on it this week), we'll find an appropriate way to make this public so others can kick it too. Of course this early prototype won't be the production solution since a number of repositories are still in the process of migrating to git in time for Juno. We've wrapped these in git for now for our prototype. Once they're all on git, this should work well.

3) Is this something that will interact with the instance to share p2 repos as they are built?

TBD. I understand there's work to be done to make viable (or set something else up if not). This is something I'll be talking to the folks involved with it and exploring this week.

4) just a general comment.  As we've seen recently, sharing and/or promoting repos as part of the builds when Hudson is involved is quite convoluted/error prone.  But building a number of repos and sharing them either within one build or between multiple build jobs is a requirement (even now, and probably more important if we do get to break up the main Eclipse SDK build into smaller builds).   Should we be able to recommend a best practice for this on the Eclipse Foundation hardware?

I think so. It's early of course and thus I may eat my words later, but this seems to me to be something that makes sense to standardize and that we should be able to do so without too much pain. Vendor neutrality is important, and so is ensuring we have the right features we need.

I encourage you and others to help inventory some of the issues we've been facing to date here. That way we can plan for them and make sure they're covered.


Paul Webster
Hi floor.  Make me a sammich! - GIR

Back to the top