Hi, Ages ago when we were deciding on the format of the .sar file there was a number of proposals, questions and requests. I want to relook at our choices again because I think we may have made a mistake ;)
.bar vs .jar ------------ The question of whether block archives should be named <myarchive>.bar or <myarchive>.jar was asked. The first form was chosen because it allowed us to easily identify archives with blocks in them. However that information is already contained in the manifest of jar (namely Blocks are marked by Avalon-Block: true attribute). So in theory we could rename this to jar with little loss code-wise .... but do we loose anything conceptually. Personally I can see certain advantages of both ways (.bar is easily human distinguisable while .jar fits in with rest of java conventions) however I have no real opinion which is better. However 2 separate people have asked me to allow .bars to be named .jars recently so not sure. Thoughts? If we were to change this we could still do it in a backwards compatible way and just issue warnings that you are using .bar rather than .jar or whatever. SAR-INF vs not -------------- Originally we were also going to store a lot of the information in SAR-INF/lib, SAR-INF/blocks and SAR-INF/conf rather than lib/, blocks/ and conf/. At the time it was not obvious what the advantage would be other than matching the patterns already used in java. However I now see an advantage in using SAR-INF. The reason is that when expanding the .sar we could designate everything in SAR-INF/** as being not needed to be extracted. As SAR-INF only contains read-only data for application that is manipulated by kernel (and not directly by application) I can't see a negative. If you wanted data to be extracted when application is installed (maybe a database or set of data XML files) then you would not store them in SAR-INF and instead store them in base directory. Thoughts? I like it and would +1 this ;) If we change this it would be easy to do it in a backwards compatible manner. blocks/ vs lib/ --------------- Is there a need for two different directories? In effect they are not treated any different and merging them into on (say lib/) would simplify the deployment format. Again - this could be done in a backwards portable manner. Like this or not? (I think I do). If we were to accept all these changes then the deployment layout would be something like SAR-INF/lib/myBlockArchive.jar (note the .jar rather than .bar ending) SAR-INF/lib/mySupport.jar SAR-INF/conf/server.xml or SAR-INF/server.xml SAR-INF/conf/config.xml or SAR-INF/config.xml SAR-INF/conf/assembly.xml or SAR-INF/assembly.xml data/my-random-datafile.txt And only the last file would be expanded on filesystem. -- Cheers, Pete ---------------------------------------------------------------- Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982 ---------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
