You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/04/18 18:35:51 UTC
Avalon Bundles (was Re: [RT] Distilling the requirements for Block
Support)
Leo Sutic wrote:
>
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>Out of all of them, I like Bundle the best.
>
>
> I'm fine with that one, too. I really like the way they
> work in OSX. So, let's go with "Bundle" then?
Cool, so what do you want to borrow from the OSX Bundle,
and what I outlined?
--
"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
Re: Avalon Bundles (was Re: [RT] Distilling the requirements for
Block Support)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
> I just realized I forgot the most important question:
>
> Just what are we going to use bundles for?
>
> Will it be for entire applications? For individual components?
In GUIApp, and I believe in Cocoon as well, that the bundle
is between an "entire application" and "individual components".
For example, I want to provide a "Report" bundle to separate
out the report generation stuff for apps that don't need it,
or make it available if apps do need it. Same with a
"User" bundle to have user management features on OSs w/o
a proper multi-user environment (or more commonly one OS
"user" for everyone).
So it is for Application _features_ that will be added in
as one whole bundle at a time.
--
"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
RE: Avalon Bundles (was Re: [RT] Distilling the requirements for Block Support)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
I just realized I forgot the most important question:
Just what are we going to use bundles for?
Will it be for entire applications? For individual components?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Avalon Bundles (was Re: [RT] Distilling the requirements for Block Support)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
In addition, I'd like the following:
Let's keep the bundles as standard JAR files.
I don't want another packaging format. Jar files with a
META-INF/avalon-bundle.xml is, I think, enough.
The issue is this: I'd like to have one and only one copy
of each bundle on my system.
Thus, I'd like to have a global "bundle location" configuration
file. Each container should use that file (like a classpath)
to find bundles. (bundlepath?)
bundlepath=http://cocoon.apache.org/serializer/1.0=lib/cocoon.serializer
.bundle:http://cocoon.apache.org/generator/1.0=lib/cocoon.generator.bund
le
?
/LS
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Avalon Bundles (was Re: [RT] Distilling the requirements for Block Support)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Cool, so what do you want to borrow from the OSX Bundle,
> and what I outlined?
(very long and incoherent text by me cut here.)
Let's keep it simple.
What we need dependency wise is this:
+ A way to declare that a bundle provides a certain interface
specification.
+ A way to declare that a bundle provides an implementation of an
interface
or set of interfaces.
+ A way to declare that a bundle provides an implementation of an
interface
defined by another bundle or set of bundles.
That's it. Anything else - how bundles are configured etc. is out of
scope.
Let's look at the use cases:
+ A bundle provides an interface specification:
Bundle http://cocoon.apache.org/serializer/1.0 provides a Serializer
interface for XML serialization.
+ A bundle provides an implementation of an interface specification:
Bundle http://xml.apache.org/fop/1.0 provides an implementation of
http://cocoon.apache.org/serializer/1.0 that serializes FO to PDF.
+ A bundle provides an implementation of an interface specification
not in another bundle:
Bundle http://xml.apache.org/fop/0.9 provides implementation of
the org.apache.cocoon.PrimitiveSerializer interface (and maybe more
interfaces).
The interface bundles are trivial. You have the interface classes, and
their associated metadata. (OK, so we need metadata to get this thing
going. Big deal.) The bundle lists what classes in it are Avalon
interfaces. For example:
Bundle http://cocoon.apache.org/serializer/1.0:
org.apache.cocoon.serialization.Serializer
org.apache.cocoon.serialization.SpecialSerializer
...
Possible this can be skipped - the classloader could check which
classes are Avalon interfaces, but let's keep it very simple and
stupid.
The implementation bundles are a bit tricker, but still simple.
Inside each bundle, you declare what Avalon component class provides
which interface from the interface bundle.
http://cocoon.apache.org/serializer/1.0/org.apache.cocoon.serialization.
Serializer=org.apache.fop.FOPSerializer
The component classes can then be loaded by the container. The component
class will then contain metadata about what interface bundles it must
be able to find in its ServiceManager.
The lacing together basically boils down to this:
For Bundle X, which is depndent on Interface Bundle Y, provide
implementation
via Bundle Z. Possibly, one could be even more fine-grained: For Bundle
X, which
is dependent on Interface Bundle Y, provide implementation of interface
Y1 via
Bundle Z and interface Y2 via Bundle U.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Avalon Bundles (was Re: [RT] Distilling the requirements for Block Support)
Posted by Peter Royal <pr...@apache.org>.
On Friday, April 18, 2003, at 12:35 PM, Berin Loritsch wrote:
> Leo Sutic wrote:
>>> From: Berin Loritsch [mailto:bloritsch@apache.org]
>>> Out of all of them, I like Bundle the best.
>> I'm fine with that one, too. I really like the way they
>> work in OSX. So, let's go with "Bundle" then?
>
>
> Cool, so what do you want to borrow from the OSX Bundle,
> and what I outlined?
An OSX bundle maps /really well/ to what you are describing.
It is a directory, rather than an archive. The OS just shows it as a
single unit (you can stil drop to the shell and 'cd' into it though).
On OSX you have:
Root
-Contents
-MacOS (binaries)
-Frameworks (libraries)
-Resources (images/other crap)
Info.plist (xml descriptor)
but I'll drop into the discussion more later, busy day here :)
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org