river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Hobbs <tvho...@googlemail.com>
Subject Re: build mechanisms
Date Fri, 14 Jan 2011 14:39:26 GMT
I'm not sure I agree with the "it's not complex" bit.  It's not rocket
science, for sure, but it's not *simple* either.

There's clearly a lot of difference in opinion here, I think it's
probably sensible to let Peter and Dennis finish Maven-ising and
modularising the code in a branch.  We'd all be in a much better
position then to be able to compare the process of one tool/setup over

Maybe it's just me, but right now it feels like we're arguing about
whether or not the work is necessary.  If people are willing to do it
(in a branch) - and I think that they are - then the best thing to do
is to review what they've done when it's finished and vote on whether
or not that change should be moved into the trunk*.

Package names and build modularisation are both on our post-graduation
roadmap, after all.

I think that Peter and possibly others, have already said some of the
above.  I'm just wondering if we can accept that and draw a line
underneath this issue until they're ready for a show-and-tell of the
Maven jazz.

The above is my opinion only and subject to change without warning or
notice.  ;-)

* But only after the next release.

On Fri, Jan 14, 2011 at 2:28 PM, Sim IJskes - QCG <sim@qcg.nl> wrote:
> It is big, but not complex.
> Have a look at the png, you can see clear patterns here.
> http://people.apache.org/~sijskes/build.png
> It's a bit messy in the front (that was me, trying to maintain
> compatibility, to stay as less controversial as possible).
> But what is the process basically:
> - compile (ant supports compiling only changed files)
> - building deps (only those that need change)
> - building jars (only those that need change)
> We can reduce a lot of duplication by bundling those actions in single
> targets, and better uptodate checking. A number of macros should suffice.
> We can reduce a lot of variable definition, by specifiying them in the
> target where they are needed.
> Gr. Sim
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

View raw message