avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [RT] Distilling the requirements for Block Support
Date Wed, 23 Apr 2003 14:17:46 GMT
Peter Donald wrote:
> On Wed, 23 Apr 2003 22:57, Berin Loritsch wrote:
>>Peter Donald wrote:
>>Or as I stated ages ago - thats the wrong way of thinking about things.
>>>Think of it this way
>>>DeployableUnit (DU): Contains configured components that can be deployed
>>>LibraryUnit (LU): Contains classes and resources but no configuration
>>>DUs can depend upon other DUs
>>>DUs can contain LUs
>>>LUs can depend upon other LUs
>>>Now that should be easy to do as it is basically what is in Phoenix atm.
>>>The trickyness comes when you introduce a few more concepts - namely;
>>>1. profiles/templates (ie information in LUs that can be used to
>>>autocreate a DU)
>>I think "autocreate" is the wrong term.  "Find" is the better term.
> Again I think you are mixing concepts of DUs and LUs. Find is only appropriate 
> for DUs or profiles/templates that can be used to autocreate DUs. Find has 
> far less meaning when applied to LUs.

Maybe I am confusing things.  However when I see "autocreate" it makes
me a little nervous.  I expect to distribute a package (if I have this
part right, a DU).  The application will be able to *use* the DU and
integrate it intelligently with the rest of the system, using any
declarations in the DU to help.

>>In essence, I want to use resources defined in another LU for in this
> Are you sure you do not want resources defined in another DU used byt this DU?

Either way ;P

To keep things clear, let's call DUs bundles and LUs jars.  That way
I think I can keep it clear.

If I want to look up a string resource, i.e. what the i18n
ResourceBundle does, how would it work?

I have a problem which needs a solution in this way:

GUIApp is being designed with i18n/l10n in mind.  I have reduced the
number of resource.properties files to one per JAR.  However because of
the static accessor nature of the typical Java i18n project, I cannot
cleanly access values from another JAR.

The guiapp.jar distributable has some resource entries that are fairly
common like "yes", "no", and other button names.  However, I cannot
really access those from my DemoApp.jar classes.  That has some of its
own entries, and unless I do some crazy stuff with the static accessors
of the resource utilities, it is hard to control the hierarchy of

What I would like to do is have a "ResourceFinder" component or
something like that that my components can use to get the resource
strings, images, etc. from.  By having a non-static way of getting
at the resources, I can more easily define how to access that
information.  For example, the GUIApp definitions would be accessed
last, allowing the DemoApp bundle to override some values or simply
use what is in the GUIApp archive.  Also, if bundles can refer to
other bundles, then I can have the resource finder automatically
grab those resources in a consistant manner.

>>>2. autoassembly (in combination with above)
>>In combination with DUs or LUs?
> LUs can never be autoassembled as they are never assembled because they are 
> librarys and not instances.


> I have not relly thought about a standard for DUs much. There is the "classic" 
> passive data-driven format ala .war and .sar files. There is also the active 
> code-driven format ala osgis bundles. I am also watching mavens plugin system 
> which I believe will evolve somewhere in between the two.

I prefer DUs to be declarative, or passive.  The active portion should
be in the API to access the contents of those DUs.

"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock

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

View raw message