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:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
