db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dyre.Tjeldv...@Sun.COM
Subject Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine
Date Fri, 09 Jun 2006 17:20:27 GMT
Bryan Pendleton <bpendleton@amberpoint.com> writes:

>> Part of the problem depends on how much time developers are willing to
>> wait for a jar build. The time necessary to clobber, then copy, alter,
>> recompile the new source, and then package a 'production' build -  the
>> build that you are supposed to run your tests against - may increase
>> dramatically.

If I only needed to do this once, and maybe whenever I touch a
shared component, it would be ok. But if I'm forced to go through the
this loop just to get updated jar files, then I'm sceptical.

> Can we quantify this? In my environment, it takes under 2 minutes for the
> complete ant clobber/ant all/ant buildjars step. Given that derbyall takes
> 4 hours, 2 minutes is nothing.
>
> Even if it triples, say, to 6 minutes, it would still be nothing.

I always run all tests against the jars (not just derbyall), and I
build the jars so that I can distribute them to other machines and run
my tests there. And then it IS a big difference between 2 and 6
minutes.

>
> I'm just trying to say that it's hard to see build time as a problem right now,
> particularly if what we're talking about is "the build time before you run
> derbyall".
>
> If *every* routine development build increased dramatically in time, that
> would be more frustrating.

That would be the net effect for me.
I would like a lean jar build that I can use during development. This
target would build only the jars that need to be updated in the
fastest possible time, preferably figuring out any dependencies so I
wouldn't have to worry about having to run clobber.

Before the final derbyall, I don't mind running a heavy target that
builds everything...

>> another factor is how well these source modifications work with IDEs
>> that don't have knowledge of Ant or the source modifications for a
>> production build.
>
> This seems *much* more important to me. IDE productivity is key.
>
>> In the past, I've seen serious problems occur because of a disconnect
>> between development and production builds. So, I think we should
>> consider introducing any differences between the development and
>> production testing environments very carefully.
>
> 100% agree, especially given the roller-coaster ride that Andrew and I
> experienced with the sysinfo changes and how sensitive they were to the
> various different runtime configurations (classes, jars, different classpath
> orders, etc.).

Exactly. A quickbuildjars target would have been awesome...

-- 
dt

Mime
View raw message