On Fri, 2002-01-25 at 08:15, Erik Hatcher wrote: > From: "Andrew C. Oliver" <[EMAIL PROTECTED]> > > > Most Jakarta projects currently do it differently that Lucene's current > > > procedure, so I'm not proposing anything unusual. > > > > > > > IMHO They are wrong. > > :) At least we all have our own strong opinions on this issue. > > > -1.. Yes.. Think of the situation where you have two unknown versions > > of the jar... It is very easy to cause the java version of DLL hell. > > Yet by simply looking at the jar in your classpath or web container you > > can see which one to zap or rename to mud. > > > > This doesn't solve the problem but it sure as heck makes it obvious. > > Version information can be embedded inside the JAR as a properties file or > in the manifest, so its would be easily identifiable. > > I certainly can see both sides of this issue, but my overriding thoughts are > that upgrading to a new version of Lucene should be as easy as pointing a > build to a new directory and not dealing with JAR file name changes too. I > believe classpaths should be tightly controlled and using Ant this means > that a <path> is constructed pointing to exact JAR files (and not to include > "*.jar"). > > Suppose I have a project that is using Lucene and, of course, is using an > Ant build. How should my build be flexible enough to handle the upgrade of > a new version of Lucene without the build file itself having to be modified? > I'm curious how you handle this situation. I have a technique that I've > developed that works nicely, even with Lucene's scheme (because at least its > JAR file name is the same as distribution directory name) but it works even > nicer with JAR's named the same. >
I'm not quite as familiar with POI's new Apacheized (we've adapted the same standard build as Avalon, Cocoon and other projects with minor improvements), but until recently at least we've used a command line parameter. I'll have a different opinion on this once there is *real* versioning introduced into the jar/jdk. (I could have sworn I saw a JSR on this), until then... I like knowing what I have just by looking at it. -ACO > Erik > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- www.superlinksoftware.com www.sourceforge.net/projects/poi - port of Excel format to java http://developer.java.sun.com/developer/bugParade/bugs/4487555.html - fix java generics! The avalanche has already started. It is too late for the pebbles to vote. -Ambassador Kosh -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
