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.
Andrew
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 git.eclipse.org/gitroot/dash/org.eclipse.dash.maven.git
with an default eclipse parent pom and an eclipse-signing-maven-plugin
There's also http://wiki.eclipse.org/Minerva
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 maven.eclipse.org
instance to share p2 repos as they are built?
TBD. I understand there's work to be done to make maven.eclipse.org
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.
[1] http://dev.eclipse.org/mhonarc/lists/dash-dev/msg01170.html
[2] http://dev.eclipse.org/mhonarc/lists/dash-dev/msg01191.html
--
Paul Webster
Hi floor. Make me a sammich! - GIR
|