db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Single JDK14 compile model?
Date Tue, 08 Mar 2005 03:30:52 GMT
Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
> 
> 
>>Daniel John Debrunner wrote:
> 
> 
>>>Hopefully I made it clear in my other e-mail, but the issue is not how
>>>the code is laid out, but do we want to require Derby contributors &
>>>committers to download multiple JDKs to build Derby, or a single one?
>>>And how do I make progress on J2ME if developers cannot download a J2ME
>>>environment?
>>>
>>
>>I still see this as an effect of the one-jar-fits-all model that
>>requires everything to be built all the time.
> 
> 
> I think we are getting closer to understanding each other, I still
> disagree that it's a packaging issue, but it does arise from the
> requirement that a single compile environment produce all the code for
> all the platforms.
> 

:-)

> 
>>Under this model, I could do all my development and testing using 1.4
>>and the JDCB3.0 modules and you would do all your development and
>>testing using J2ME and the JSR169 modules. 
> 
> 
> So this would be a change from the current Derby model. I'm new to open
> source so I'm unclear how this would work in practise. If a contributor
> or committer working only in JDK 1.4 submits or commits a patch from
> that breaks the build in the JDK 1.3 and/or J2ME, what happens?
> 
> Would the patch be veto'ed until it compiles in all the environments? If
> so, then there is an implicit requirement for all developers to have all
> the compile environments and the process is more manual, thus more error
> prone.
> 
> Or is the build in the other environments simply broken until someone
> who cares about that platform fixes it? Bad for quality as other
> undetected problems can be added to that environment while the build is
> failing.
> 
> That situation cannot arise today because of the single compile model.
> 

Yes it is a change in the model.

It deals with the issue that many developers will not have access to all 
platforms or environments. Often they are working from a single machine 
(like now, all I have access to is a laptop) and that may not even run 
all environments.

Often the only way a change can be tested is for it to be committed and 
then built and run by some volunteer on a platform they own; a few core 
(tier 1) platforms may be available on a continuous basis (a la gump or 
continuum) but others may not be available until someone decides to 
download and test a beta release.

One factor here is the time "until someone who cares about that platform 
fixes it" is usually very very short - broken builds don't linger 
because its damned inconvenient and also rather embarassing. No veto is 
needed, its cultural. Usually the fix is done by the original developer.

Is quality affected? I don't believe so because everyone sees the 
problem and any defect is corrected quickly.

> 
> 
>>We take care in shared code
>>not to use features that are not available in the other platform. We
>>both make progress, and rapidly because we can concentrate on the
>>feature we're working on rather than the cross-platform build.
> 
> 
> Once you downloaded the initial requirements to build Derby, how much
> time have you spent worrying about the cross-platform build, which
> occurs automatically? Beyond the initial download I believe it is not a
> time drain.
> 

Once it's all up and running then things are fine. However, there is a 
fair bit of complexity in the build to deal with compiling specific bits 
for specific JVMs; as we do more and more to deal with J2ME issues or to 
leverage bits of 1.4 and 1.5 then this is only going to get worse. It 
may well be that eventually the everything-in-one-build model may not 
work at all - for example, is there even an J2ME or JDK1.5 JDK available 
for OSX (a platform used by a lot of open source developers)?

These types of issues affect all sizable open source projects and 
breaking them down into separately developable modules is very common 
practise - e.g. HTTPD, Tomcat/Jakarta Commons, Geronimo, Ant, Maven are 
examples just at Apache alone.

--
Jeremy

Mime
View raw message