You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Farr, Aaron" <Aa...@am.sony.com> on 2003/09/28 02:36:30 UTC
[merlin] .bar = block archive?
So, is a ".bar" file the merlin version of a ".sar" file?
.bar internals:
/META-INF
/bars
/blocks
/configs
/jars
/...
I'm guessing a .bar acts like a special repository there the various
internal directories are the 'types'.
Does this mean someday you could just drop your 'bars' into a merlin
'deploy' directory like you would for .wars or .ears?
Is there some sort of documentation on this?
J. Aaron Farr
SONY ELECTRONICS
DDP-CIM
(724) 696-7653
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] .bar = block archive?
Posted by Stephen McConnell <mc...@apache.org>.
Reposted with small correction..
Farr, Aaron wrote:
> So, is a ".bar" file the merlin version of a ".sar" file?
>
Yes and no.
Strictly speaking the ".bar" is an archive of a set of resources
relative to a repository group. The bar (block archive) enables the
packaging of an application context into a single unit for physical
deployment. For example if we want to construct a James application
(without breaking the notion of composite components), we need a
physical packaging solution within which Sun jar files (such as
activation.jar and mail-1.3.1.jar) can be included.
So, yes - a bar is equivalent to a sar in that it is a distribution
unit, but - no - the bar file is [not] intended to replicate a sar. One
important consideration here is that a bar cannot contain resources
relative to another group. This means that - for example in the casr of
the activation.jar and mail-1.3.1.jar resources, these are resources
located relative to the james project group. While this means that
there are potentially multiple version of such jars spewad across a
repository - its kind of academic because the instance of an
activation.jar under james/jars is the instance of activation.jar
license by Sun to the creator of the james application package in
accordance with Sun' license.
>
> .bar internals:
> /META-INF
> /bars
> /blocks
> /configs
> /jars
> /...
>
> I'm guessing a .bar acts like a special repository there the various
> internal directories are the 'types'.
>
The bar file structure is totally based on the repository structure.
Resources of the type ".jar" go under "/jars" etc. The action of
importing a package is simply the act of expaning the bar file into the
local repository relative to the group identified within the bar file
manifest.
>
>
> Does this mean someday you could just drop your 'bars' into a merlin
> 'deploy' directory like you would for .wars or .ears?
>
This would be trivial to implement - just setup a directory, a monitor,
and when required (a change event for example) - install the bar into
the local repository.
> Is there some sort of documentation on this?
>
Nope - and the reasons are:
1. insufficient time
2. has only been trialed against james and openim scenarios
3. needs more manifest content (e.g. dependent bars, main block, main
config, etc.)
4. raises the question about security and the need for authentication of
bars, jars, and security polices
5. goto point (1)
However - the key is that the bar file structure is nothing more than
the repository structure under a particular group + defintion of the
group under the bar file manifest.
Stephen.
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [merlin] .bar = block archive?
Posted by Stephen McConnell <mc...@apache.org>.
Farr, Aaron wrote:
>So, is a ".bar" file the merlin version of a ".sar" file?
>
Yes and no.
Strictly speaking the ".bar" is an archive of a set of resources
relative to a repository group. The bar (block archive) enables the
packaging of an application context into a single unit for physical
deployment. For example if we want to construct a James application
(without breaking the notion of composite components), we need a
physical packaging solution within which Sun jar files (such as
activation.jar and mail-1.3.1.jar) can be included.
So, yes - a bar is equivalent to a sar in that it is a distribution
unit, put - no - the bar file is intended to replicate a sar. One
important consideration here is that a bar cannot contain resources
relative to another group. This means that - for example in the casr of
the activation.jar and mail-1.3.1.jar resources, these are resources
located relative to the james project group. While this means that
there are potentially multiple version of such jars spewad across a
repository - its kind of academic because the instance of an
activation.jar under james/jars is the instance of activation.jar
license by Sun to the creator of the james application package in
accordance with Sun' license.
>
>.bar internals:
> /META-INF
> /bars
> /blocks
> /configs
> /jars
> /...
>
>I'm guessing a .bar acts like a special repository there the various
>internal directories are the 'types'.
>
The bar file structure is totally based on the repository structure.
Resources of the type ".jar" go under "/jars" etc. The action of
importing a package is simply the act of expaning the bar file into the
local repository relative to the group identified within the bar file
manifest.
>
>
>Does this mean someday you could just drop your 'bars' into a merlin
>'deploy' directory like you would for .wars or .ears?
>
This would be trivial to implement - just setup a directory, a monitor,
and when required (a change event for example) - install the bar into
the local repository.
>Is there some sort of documentation on this?
>
Nope - and the reasons are:
1. insufficient time
2. has only been trialed against james and openim scenarios
3. needs more manifest content (e.g. dependent bars, main block, main
config, etc.)
4. raises the question about security and the need for authentication of
bars, jars, and security polices
5. goto point (1)
However - the key is that the bar file structure is nothing more than
the repository structure under a particular group + defintion of the
group under the bar file manifest.
Stephen.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org