At 04:37 4/5/01 -0700, Craig R. McClanahan wrote:
>The fundamental organizing principle (common since almost the beginning
>with Jakarta releases) is that the version number is included in the name
>of the binary distribution packages (jakarta-foo-1.5.tar.gz) as well as
>the name of the directory into which those packages unpack themselves
>(jakarta-foo-1.5). This lets us define appropriate build.properties
>entries for your different projects:
Another "fundamental organizing principle" of jakarta present since almost
the begining is building into a cetralized directory - luckily that is no
longer the case.
> foo.jar=/usr/local/jakarta-foo-1.5/foo.jar
>
>where you need version 1.5, or (if you need 1.6):
>
> foo.jar=/usr/local/jakarta-foo-1.6/foo.jar
>
>Given that we have to do something like this even if I have foo-1.5.jar
>and foo-1.6.jar (in the same directory or not doesn't really matter),
>having the version numbers in the filename does not buy you anything.
Sure it does - you can now have
/opt/apps/cjan/foo-1.6.jar
/opt/apps/cjan/foo-1.5.jar
>> >I also note the precedent of standard Java packages -- take JAXP for
>> >example, where "jaxp.jar" and "crimson.jar" do not have version numbers in
>> >the filenames -- as well as many other packages (Xerces does the same
>> >thing).
>>
>> true - but how much pain did that cause?
>
>That didn't cause any pain. Changing the release file from "parserjar" to
>"crimson.jar" caused a small amount of pain (otherwise, I would have just
>needed to change my definition for "jaxp.home".
Thats not the part that caused issues it was the jaxp.jar file. People
persistently put the wrong one in classpath just to see if it would work
>Using .so files works because the OS supports symlinks, and conventional
>shared library installation leverages them -- which allow an application
>to use a non-versioned filename to get the default, and only have to care
>about version numbers if it wants to. Installing an updated library
>requires zero changes in the scripts for applications that simply
>use the defaults, courtesy of not having versions in the paths they use.
.so files and .dll files don't work via location alone they used a library
loader of some sort. This library loader can behave however it feels like -
it can map requests for foo.jar to foo-current.jar, foo-1.4-STABLE.jar or
whatever. True some library loaders use symlinks as a management
convenience - but it is not required.
As soon as cjan is in place it will become completely transparent to
developer. So...
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 |
*-----------------------------------------------------*
