avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <j...@socialchange.net.au>
Subject Re: Depchecker.
Date Sat, 20 Apr 2002 07:51:51 GMT
On Fri, Apr 19, 2002 at 11:31:05PM +0900, Ryan Shaw wrote:
> Jeff Turner wrote:
> 
> > So you absolutely *need* isolation from external changes. Isolation is
> > necessary until the moment when you can say "yes my code works fine",
> > and can tick off that variable. Then, and only then, should you consider
> > the effects of other variable changes.
> > 
> > The build system supports this isolation principle in another way.
> > You'll notice that the default target is 'jar', which builds a jar in
> > build/lib/. However, the depchecking system runs the 'dist.lite' target,
> > which builds a jar in dist/, and this is where the "excalibur-*.jar"
> > properties point to.
> > 
> > The thinking behind this is that build/lib/*.jar will change on every
> > build, and it's API contracts are not stable enough even for other
> > subprojects to rely on. So there's a dist/ directory, whose jars are
> > *intended* to be relied on by other subprojects. They are relatively
> > stable, and only built on demand by other subprojects, instead of "by
> > accident" when the user types 'ant'.
> 
> I see what you saying. However, I think this increases the risk that
> people will check in broken code, because their code works with the
> "dist" jar, and they forget to check to see if it actually builds 
> with the latest "build" code.

Yes it does. Luckily we've got Gump. Broken code can go at most 6 hours
before a Gump run catches it.

> This is bad, because it means the people to discover this won't be
> the ones who understand how to fix it (the developers of the broken
> code).
>
> But, like I said, I see the isolation argument too. But can't this
> be achieved by not doing a CVS update when you have half-developed
> code in your source tree? Wait until the part you are actively 
> developing is stable. *Then* update, and rest assured that depchecker
> will verify that your new code works smoothly with the very latest
> CVS code before you checkin. Saves you getting scolded by GUMP later.

Yes, that would work. I suppose the question boils down to, what
semantics do you want to associate with 'cvs update'? Your way, every
'cvs update' implies "I trust this new code and wish to use it in all
projects". I don't think that's *always* what people think when they do
an update. Maybe they just want to look at the code, not use it. Maybe
they're just creatures of habit like me and unthinkingly type 'cvs
update' before starting any work.

I think the semantics of 'cvs update' should be "synch these files with
the repository"; nothing more. Then an extra step, 'ant dist.lite',
means "I trust this code enough to want to use it in other projects".
This is the way Jakarta Commons works.

So there's pros and cons. It boils down to what the regular committers
want (I'm not one). If any of them prefer less isolation, then speak up
and I'll see what can be done.


--Jeff

> Ryan
> 

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message