At 09:12 28/11/00 -0500, you wrote: >Peter Donald wrote: >> >> > I too am tired. For example, I know from past experience >> > that as a committer if I were to -1 this, my objection >> > would be ignored. >> >> Nope it wouldn't - at least not by me ;) Only one person >> has expressed a -1 so far (Connor IIRC) and > >Ok, for the record, -1.
okay ;) >It is also my reading of >http://jakarta.apache.org/site/decisions.html that one veto should be >sufficient, even if it is "only" Conor. ;-) yep - but if he doesn't keep responding to further queries/questions/suggestions it effectively goes to +/- 0 >> I have offered a solution that would solve your objections - >> what do you think about it? > >I'm sorry to say that for me, your proposal actually solves the wrong >problem. If there was some way to reliably determine what packages were >used to build the product, I have no problem with a build process producing >an installation image that exactly matches the build. Okay I guess I read your problem wrong ;) >What I would like to be able to do is easily and reliably control what >versions of dependent products are used in any particular build. For >background, most of my work to date has been involved with integrating >multiple products. (FYI - this is still true at this moment, but the >products are not Apache ones) This task is often difficult and the way I >like to proceed is to start with the source of every product and build them >as if they were a single product. This way when I find I have to debug a >problem, I can reliably bring up the source which matches my executable, >make a fix, build it, and run the results. Okay how about this. We make a directory lib/support and we place the jars in there. Instead of automatically including all these files we include only those files specified by a property variable. So we can do "-Djar.junit=/place/to/my/own/copy/of/junit.jar" on command line to change the junit from default ("./lib/optional/junit.jar") to another junit. As this is painful to place on command line you can simply add it to .ant.properties in directory you build jakarta-ant from. (.ant.properties is unversioned and ignored in updates). Thus .ant.properties would look like jar.parser=/xerces-1.123/lib/xerces.jar jar.jaxp= # Null as it is included in xerces jar.junit=/junit3.2dev/lib/junit.jar jar.whatever=/whatever-V301/lib/*.jar Would this suit your needs. It still makes it simple to build ant but if you really need to overide libraries you can Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
