Stefano Mazzocchi wrote:
Descriptive Block metadata --------------------------
The descriptive block metadata that we currently include is:
<name>***</name>
<description href="...">***</description>
<license href="..."/>***</license>
<author href="...">***</author>
where:
*** -> short text ... -> URL for reference
NOTE: I want to keep the above super simple. I know that <author> can be generic and mapped to a person or group or entity... but at this point, I think it's useless complexity.
This data will be used by the block librarian and by the block deployer to catalogue and provide more information about this block. that's all.
I can't think of anything else I would like to know when choosing for a block in a library of blocks.
Ah, remember that "certification" or any other metadata on the "status" of the block is time dependent and therefore should *NOT* be included in this file.
If you think you'd need more info, this is a good time to speak up.
Don't know, if it fits into this file but here is some more information I can think of:
* Version number
* Release date
Exposing classes ----------------
Stephen proposed to separate the classes to expose in a different jar and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks, I propose to extend the block FS layout so that we have
for individual classes and resources: /classes /classes/public /classes/private
for jars: /lib /lib/public /lib/private
the block manager will tranparently make available the classes found in the "public" folders to the blocks that depend on this block (and *ONLY* to those! classloading isolation is very important to achieve hot deployment functionality without impacting the performance of a running system too much)
the classloader will also check for conflicts: in fact, it will be considered an error to depend on two blocks that provide one or more classes with the same absolute name.
What do you think?
That's a very simple and easy-to-understand approach. It does just what you need without hidden magic. I like it :-)
-- Stefano.
Bye, Andreas
