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
another.

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
>
>

Mime
View raw message