Re: integrating qa build script into main build script

[Peter Firmstone <ji...@zeus.net.au>]

Jonathan Costers wrote:
> Why would we?
> The main build script is already pretty huge ... Adding the QA targets to it
> would make it even more massive and more difficult to understand.
> We have a clean separation between the actual River code and the QA code
> now, and I think that is just fine.
>
> 2010/10/31 Sim IJskes - QCG <si...@qcg.nl>
>
>   
>> Shall we integrate qa build script into the main build script?
>>
>> G.Sim
>>
>>     
>
>   
Can we make qa a separate build, and just use jar files from the main 
build as libraries?

My reasoning is that currently we're not testing binary compatibility 
only compile time compatibility (both are important), I've run into 
binary compatibility problems in the past because of the conjoined build.

 From what I've noticed, the tests change less than the build, both 
should be separate, not compiling the tests every time may save some 
time running the tests.

But every now and then both should be freshly compiled together to check 
for method signatures problems etc.

Just my 2 cents.

Cheers,

Peter.

Re: integrating qa build script into main build script

[Jonathan Costers <jo...@googlemail.com>]

It's not about "listening", really, but OK.
I gave my opinion, and that's just it, an opinion.

2010/11/1 Sim IJskes - QCG <si...@qcg.nl>

> On 01-11-10 15:11, Jonathan Costers wrote:
>
>> So .. we started this thread with a proposal to merge the two, and end up
>> with a proposal to further separate them ... ?
>> I'm not sure if I understand.
>>
>
> You were against merging them. I've listened.
>
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>

Re: integrating qa build script into main build script

[Sim IJskes - QCG <si...@qcg.nl>]

On 01-11-10 15:11, Jonathan Costers wrote:
> So .. we started this thread with a proposal to merge the two, and end up
> with a proposal to further separate them ... ?
> I'm not sure if I understand.

You were against merging them. I've listened.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

Re: integrating qa build script into main build script

[Jonathan Costers <jo...@googlemail.com>]

So .. we started this thread with a proposal to merge the two, and end up
with a proposal to further separate them ... ?
I'm not sure if I understand.

What we currently have is pretty separate. The QA build can be used
separately, running against an external binary River installation, for
instance (change property river.home to do that). This has been deliberately
foreseen.
The only thing the QA build depends upon is common.xml, so you could argue
we can remove that dependency. However, duplicate code has been factored out
of both build.xml files for a reason too.

I'm not sure what we are gaining here ... The build *works* and there are
many issues to solve elsewhere?



2010/11/1 Sim IJskes - QCG <si...@qcg.nl>

> On 01-11-10 01:39, Peter Firmstone wrote:
>
>> Can we make qa a separate build, and just use jar files from the main
>> build as libraries?
>>
>
> I was thinking about a qabuild with an optional setting to build the trunk.
> We could easily instead of recompiling the source, copy the binaries from
> the last snapshot. Maybe we would have some directory layout stuff to sort.
> But it doesn't look difficult to me.
>
>
>  My reasoning is that currently we're not testing binary compatibility
>> only compile time compatibility (both are important), I've run into
>> binary compatibility problems in the past because of the conjoined build.
>>
>
> Sounds reasonable. I'm in.
>
> Gr. Sim
>
> --
> QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>

revising build logic

[Sim IJskes - QCG <si...@qcg.nl>]

On 11/01/2010 09:15 PM, Peter Firmstone wrote:
> Sim IJskes - QCG wrote:
>> On 01-11-10 01:39, Peter Firmstone wrote:
>>> Can we make qa a separate build, and just use jar files from the main
>>> build as libraries?
>>
>> I was thinking about a qabuild with an optional setting to build the
>> trunk. We could easily instead of recompiling the source, copy the
>> binaries from the last snapshot. Maybe we would have some directory
>> layout stuff to sort. But it doesn't look difficult to me.
>
> I like the sound of that.

We could have a look at the complete build pipeline. We could let the QA 
build produce the daily snapshots, and have the river-trunk as our main 
ci build. No daily snapshot if qa fails. The ci-build we could tune to 
producing as much warnings as possible and let code quality plugins 
produce reports, and not minding about the produced artifacts.

Gr. Sim

Re: integrating qa build script into main build script

[Peter Firmstone <ji...@zeus.net.au>]

Sim IJskes - QCG wrote:
> On 01-11-10 01:39, Peter Firmstone wrote:
>> Can we make qa a separate build, and just use jar files from the main
>> build as libraries?
>
> I was thinking about a qabuild with an optional setting to build the 
> trunk. We could easily instead of recompiling the source, copy the 
> binaries from the last snapshot. Maybe we would have some directory 
> layout stuff to sort. But it doesn't look difficult to me.

I like the sound of that.

>
>> My reasoning is that currently we're not testing binary compatibility
>> only compile time compatibility (both are important), I've run into
>> binary compatibility problems in the past because of the conjoined 
>> build.
>
> Sounds reasonable. I'm in.
>
> Gr. Sim
>

Re: integrating qa build script into main build script

[Sim IJskes - QCG <si...@qcg.nl>]

On 01-11-10 01:39, Peter Firmstone wrote:
> Can we make qa a separate build, and just use jar files from the main
> build as libraries?

I was thinking about a qabuild with an optional setting to build the 
trunk. We could easily instead of recompiling the source, copy the 
binaries from the last snapshot. Maybe we would have some directory 
layout stuff to sort. But it doesn't look difficult to me.

> My reasoning is that currently we're not testing binary compatibility
> only compile time compatibility (both are important), I've run into
> binary compatibility problems in the past because of the conjoined build.

Sounds reasonable. I'm in.

Gr. Sim

-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397