----- Original Message ----- From: "Peter Donald" <[EMAIL PROTECTED]> To: "Avalon Development" <[email protected]> Sent: Wednesday, September 26, 2001 3:14 AM Subject: [phoenix] Relooking at distributions
> 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. +0 > > 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. -1. Is configuration is read-only? > > 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). +0. > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
