commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee / Purple Technology <g...@stinky.com>
Subject Re: import * vs explicit debate
Date Thu, 03 Apr 2003 17:49:26 GMT
Craig -

I'm not trying to be argumentative here, but I'd like to understand
your position (and clarify mine).

The situation I was describing was as follows:

Project A uses Library X.jar (v1.0).  Alphonse is a developer on
Project A.

Xavier is a developer on Project X.  He updates Project X and
publishes a new version of Library X.jar (v1.1).

Alphonse imports the new version of X.jar into Project A.  

Now, I think we'd agree that Alphonse should do a full build of
Project A before he checks in the new version of X.jar, right?

That's the stage I was talking about.  Since Alphonse had to
explicitly import the new version of X.jar, he has a pretty good idea
that any compile errors that say "ambiguous class involving
org.X.SomeClass" are due to interface changes introduced in the X.jar
he just imported.

Your argment seems to be that Xavier should not be responsible for
recompiling and fixing Project A (and all other clients of Library X).
I totally agree with you there.

But the Maven/Gump procedure is messing with that scenario a bit.  Are
you saying that it promotes *automatic* updates of all clients when a
library is updated?  In that world, Alphonse does not exist; he is
replaced by a script (or just an automatic Ant-based web download).  

This scenario is a little troubling, since it introduces the
possibility of semantic changes as well as syntactic ones.  This
transcends the import issue.  If this is so, is there a rationale for
it somewhere I can read up on?  

Note that I actually think this procedure is great, and can accelerate
development, as long as everyone involved understands the risks.

Cheers -

 - A


> > No; it's a reason for doing a full clean build and unit test run
> > before checking in any changes.
> >
> 
> That only works for code in your own packages -- not in packages you
> depend on from other people (especially those that you use binaries for,
> as things like Maven encourage you to do even if the underlying package is
> open source).
> 
> > This way whoever added org.apache.Thing, or updated the library that
> > added it, is responsible for not breaking everyone else's build.
> >
> 
> In other words, I (as the author of one or more commons components) is
> supposed to ask ***every*** user of that component "will adding a new
> class Foo in my package cause your build to break?"  Yah, right.
> 
> It's not my problem.  It's the problem of the person who used "*" imports.
> 
> Craig
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

-- 
Alex Chaffee                               mailto:alex@jguru.com
Purple Technology - Code and Consulting    http://www.purpletech.com/
jGuru - Java News and FAQs                 http://www.jguru.com/alex/
Gamelan - the Original Java site           http://www.gamelan.com/
Stinky - Art and Angst                     http://www.stinky.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message