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]
