[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] ECF build v2 -- Build easier
- From: Ted Kubaska <ted.kubaska@xxxxxxxxx>
- Date: Mon, 13 Jul 2009 13:10:18 -0700
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=H4fzLo1jtnrSVyw6M0xd3jaSuV5Y4BJgvmzhW1mN0URtWGOUa+RVLbny2kMdVvzx9b x7pKTkhcXzEqN2f0EA5exJfN8GWMW1DIzhv7bAysLte1LvBchmCUREsCGVU1MqI68+N9 3t9hoe6RgjABTaHwUqwJkhriZFkvICaBRR5fc=
Oh, I just saw Scott's message about discussing elsewhere. Sorry. I'll
post off this list in the future on this issue.
On Mon, Jul 13, 2009 at 1:08 PM, Ted Kubaska<ted.kubaska@xxxxxxxxx> wrote:
> I agree with Scott ... it's always a bunch of work no matter what
> technology one uses.
> I would like to use a build technology that others in Eclipse have
> used successfully so that we can share problems and solutions.
> Currently, we maintain our own build machine at OSU. Oregon State has
> been very helpful and supportive. They host our hw for us, which is
> excellent. But we have to use our own donated hardware. And getting hw
> that is strong enough to do builds and testing is difficult. OSU has
> told us that we need at least a dual-core P4. I spent some time last
> week on a donated 600MHz P3, which we are grateful to have, but
> unfortunately it does not meet our needs.
> Currently we are using Cruisecontrol/Ant which although working, is
> showing its age. Updating the build configuration involves careful
> editing of ant and bash scripts which is tedious and error-prone.
> We need IMO a build system that lets us
> 1. build automatically on a CVS checkin
> 2. build on demand
> 3. build daily whether or not there are CVS updates
> 4. optionally runs tests on a build
> 5. sends out email notifications on success/failure and makes logs
> available to members of the list
> 6 . makes a P2 repository
> 7. optionally signs jars with the Eclipse certificate
> 8. deploys zips (we need control of the zip name) to our own website
> and to dev and deploys a P2 repo.
> 9. update the build configuration easily
> 10. and there are more than one build ... we build from different
> branches in our CVS repository for different deployments. We also
> build from different CVS repositories. We have a CVS repository
> maintained at OSU for plugins still in develoment that have not yet
> gone through IP.
> Whether this is Maven or Hudson or something else does not matter. But
> whatever we use is a big commitment on our part. It takes a lot of
> time and effort to set it up and so we don't want to start down a path
> that we later find out is not the way to go.
> On Mon, Jul 13, 2009 at 12:15 PM, Scott Lewis<slewis@xxxxxxxxxxxxxxxxx> wrote:
>> Hi Arvind,
>> Arvind Gupta wrote:
>>> Have we thought about maven?
>> (Scott speaking for himself) Yes sure, I've thought of Maven. I'm
>> personally not convinced it's the way to go, however. My previous
>> experiences with doing OSG-bundle build/deploy with Maven were less than
>> optimal. I understand that Maven's OSGi support has probably come a long
>> way, but frankly it's been a long time since I've worked with it very much
>> myself...and I know exactly nothing about how/whether it creates/edits p2
>> repos, etc (which is where we will want to go).
>> Also, there is (and should be I think) some momentum here for working with
>> Eclipse Foundation technologies and projects...e.g: Equinox, PDE, PDE
>> build, Buckminster, p2, and ECF (!), EMF/Nick/Denis/Build Harder effort...in
>> the name of cross-project collaboration and cooperatively sharing build
>> infrastructure (my personal dream :).
>> But as with most things in ECF, the 'decision' about what technologies to
>> use (to build ECF) is mostly going to be based upon who among us is willing
>> and able to put in the energy to make it a reality. So if you have an idea
>> about a build technology to use (anything we can actually get our hands
>> on/use for an open source project), please bring it up on this list...or
>> even better take the ECF projects/features and get a build running :).
>> With the build system, I would love to have a single technology solution
>> result in dramatically less work on the ECF build/deploy
>> infrastructure...but frankly I don't ever expect this to happen...and I'm
>> somewhat suspicious of 'silver bullet' arguments (just use this tech and all
>> build/deploy work will magically disappear).
>> Rather I expect that there will continue to be significant work in
>> building/deploying ECF (whether that work is development of Buckminster
>> modules/extensions, ant scripts, OS shell scripts, maven configuration,
>> Hudson config, ECF features refactoring, etc). Of course I would like to
>> minimize this work with good technologies, and I would also like to spread
>> it around among ECF committers and contributors as much as possible...just
>> so it doesn't overload or burnout anyone.
>>> On Mon, Jul 13, 2009 at 11:38 PM, Chris Aniszczyk <zx@xxxxxxxxxxxxxxxxx
>>> <mailto:zx@xxxxxxxxxxxxxxxxx>> wrote:
>>> On Mon, Jul 13, 2009 at 12:21 PM, Scott Lewis
>>> <slewis@xxxxxxxxxxxxxxxxx <mailto:slewis@xxxxxxxxxxxxxxxxx>> wrote:
>>> In broad strokes, we need to:
>>> 1) Add bundle signing (for dev.eclipse.org
>>> <http://dev.eclipse.org> build)
>>> 2) Setup/refactor the features so that we can build
>>> a) weekly platform integration builds (i.e. filetransfer and
>>> ECF core)
>>> b) auto, daily, integration and release builds (on-demand
>>> for release...others can be automated)
>>> 3) Add a builder for the features/bundles at OSU OSL
>>> (including JMS/ActiveMQ, Yahoo provider, TweetHub (product),
>>> and perhaps other things...e.g. SOC student work)
>>> 4) Add automated junit testing
>>> 5) Add support for Markus' work on distributing testing framework
>>> 6+) The million other things that have to be done for 'build
>>> system care and feeding' :)
>>> 7) The other things that I've forgotten
>>> Before we hastily move to Buckminster, please note that the Athena
>>> common build system supports most of these things. I'm going to CC
>>> Nick Boldt to give some input. In PDE, we recently setup a build
>>> for some incubator code using Athena and it was easy.
>>> -- Chris Aniszczyk | EclipseSource Austin | +1 860 839 2465
>>> http://twitter.com/eclipsesource | http://twitter.com/caniszczyk
>>> ecf-dev mailing list
>>> ecf-dev@xxxxxxxxxxx <mailto:ecf-dev@xxxxxxxxxxx>
>>> ecf-dev mailing list
>> ecf-dev mailing list