avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eung-ju Park" <co...@isoft.co.kr>
Subject Re: [phoenix] Relooking at distributions
Date Wed, 26 Sep 2001 00:44:25 GMT

----- Original Message -----
From: "Peter Donald" <donaldp@apache.org>
To: "Avalon Development" <avalon-dev@jakarta.apache.org>
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: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message