----- 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]
