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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Alex Chaffee mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
