You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2003/04/18 15:48:02 UTC
[RT] Distilling the requirements for Block Support
I want to come up with a base set of requirements to support "blocks".
A Block is defined as a functional peice of an application that is
comprised of one or more components. Examples of a block could be
encapsulating a particular class of logic like: automated support for
integrating with an FTP server, processing text based requests, or
simply adding functionality to an application.
All three of these projects (I am copying Vincent because he is on
the D-Haven team, but is experiencing temporary Email problems) have
a defined need for blocks.
For Cocoon, they want to allow one developer to supply support for
Forums, or some other pluggable application logic, and then another
developer to use that, and provide their own look and feel so that
it integrates with the whole site.
For GUIApp, they want to allow the developer to extend your average
application with encapsulated blocks and incorporate the new menu
items, task bar items, and screens into the application. The
requirements are somewhat different "Plug-ins" because it also
encapsulates fundamental things like Document Management or User
Management.
For Avalon, we need a consistent packaging for all our Excalibur
components so that both of these systems can automatically incorporate
those functions. Also by developing the basic mechanisms to make
these plugins function, we are able to set up some basic rules and
make the integration of blocks as smooth as possible.
Both Cocoon and GUIApp need to be able to do resource inheritance,
but that need is not well defined in Avalon. Although I think the
basic need for internationalization is a perfect example where Avalon
could set up the rules for resource inheritance.
There are different "plugin" mechanisms that we can learn from,
and adapt for our use. For example, both Eclipse and IDEA use
the same basic mechanism for adding functionality to the respective
IDEs. THere is a specified archive format (with JAR locations)
and a specified descriptor document.
You will find most plugin architectures similar. However, there
does arise a problem as Eclipse developers found out. How do you
handle the classloader needs when one plugin needs an incompatible
version of a library that another plugin provides--and still
integrate everything in the same user interface?
It's not an easy problem to solve, but using the versioning
specs in JARs we can at least catch conflicts. If the JAR developer
doesn't play by the rules, you can always override that information
in the descriptor file. That way we can manage JAR resources that
other folks release.
A common arrangement for plugin archives is like this:
JAR/
META-INF/
MANIFEST.MF
plugin.xml
lib/
classes/
It has its plusses and minuses, but it does deviate away from
how blocks should work. We could *refer* to libraries and
resolve them automatically, or we could include them inside
the jar in a BLOCK-INF/ directory (kind of like SARs).
There are two things that an Avalon Block must do: expose the
interfaces of services that it provides (or refer to them in
another block), and define the rules for integration.
I was thinking that if the Block archive has the interfaces
in a separate "interfaces" JAR, they can be exposed to the
kernel or other components more easily. Also if each Block
has a "BlockKernel" or embedded container, it can establish
the rules for accessing the components inside that block.
This includes the notion of block dependencies and block
services--which is an extension of the concepts we already
have for components. The only thing left would be "Block
Inheritance" if we feel that is a real need.
What are your thoughts?
--
"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
Re: [RT] Distilling the requirements for Block Support
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> I want to come up with a base set of requirements to support "blocks".
> A Block is defined as a functional peice of an application that is
> comprised of one or more components.
we should avoid overloading of terms "cocoon block (.cob)", "phoenix
block (.bar)", "phoenix application (.sar)", those are clear. We are now
looking at the common intersection between these, no?
How about we use "avalon assembly" for purpose of talking? This because
of the huge similarity between .net assemblies and what we want to do :D
alternative term would be "bundle".
<snip/>
> There are two things that an Avalon Block must do: expose the
> interfaces of services that it provides (or refer to them in
> another block), and define the rules for integration.
when you leave programming space, what is an "interface"? Some examples
of resources we want to manage are
- program components
- website and/or application "skins"
- i18n/i10n resources
- data (relational, filesystem, object-based)
what interface does a "skin" have?
> I was thinking that if the Block archive has the interfaces
> in a separate "interfaces" JAR, they can be exposed to the
> kernel or other components more easily. Also if each Block
> has a "BlockKernel" or embedded container, it can establish
> the rules for accessing the components inside that block.
>
> This includes the notion of block dependencies and block
> services--which is an extension of the concepts we already
> have for components. The only thing left would be "Block
> Inheritance" if we feel that is a real need.
>
> What are your thoughts?
throw out the assumptions and type more -- I have the hunch that I'm not
able to follow your thoughts completely. Are we to have some kind of
assembly facade which aggregrates resources in some way?
----
package org.apache.avalon.spearhead.assembly;
interface Assembly
{
InputStream getResource( String urn );
File getFile( String uri );
Object getComponent( String uri );
Configuration getConfigurationFile( String urn );
DataSource getData( String urn );
}
----
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Sat, 19 Apr 2003 01:42, Berin Loritsch wrote:
>
>>So is there anything in the concepts that I shared that you have a
>>problem with? Does it seem like a bunch of nothing? If so, I can
>>drop Avalon out of the discussions, and work with Cocoon on a D-Haven
>>block/component/plugin that will work with both Cocoon and GUIApp's
>>needs and Avalon will have to live without.
>
> I have talked about this extensively in the past and detailed very exacting
> requirements.
links? keywords? Didn't really find anything in the archives.
> The toolkit that supports these notions has been written and rewritten a
> couple of times by me.
is that public somewhere?
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 25 Apr 2003 00:51, Jakob Praher wrote:
> Am Don, 2003-04-24 um 07.59 schrieb Peter Donald:
> > I mean maven. Maven is being rebuilt around an avalon + aspect based
> > container that essentially turns maven into a generic plugin based Avalon
> > platform with a request based architecture. It is sorta ironic that the
> > most advanced and active Avalon container is not built by Avalon peeps.
>
> is there anything I can look at? [Design Document]
Unfortunately not. I believe most of the design conversations occur on IRC so
you may be able to get logs of that.
> is there already something in cvs?
Sortof. There is a maven-new in apache CVS or you can go to the plexus website
at http://plexus.werken.com/
--
Cheers,
Peter Donald
*---------------------------------------------*
| "There couldn't be a society of people who |
| didn't dream. They'd be dead in two weeks." |
| -William Burroughs |
*---------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block Support]
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 26 Apr 2003 19:23, Jakob Praher wrote:
> API Design [Active vs Passive]
>
> If I got that right, you mean that the class represenatatives of LUs and
> DUs should only contain the meta information (merely data), not
> algorithms how to do something with them, except very simple things.
> This is something you do with XxxService or XxxManager clases - right?
yep.
> Questions and Design discussion:
>
> * Library DUs
>
> LUs are loaded by DUs - period.
> Not all DUs provide all the LUs. (which mean contains).
Note that DUs never provide other DUs with LUs. LUs are just something that a
DU uses to do it's job. The LUs may be shared from a central directory (think
window/system/*.dll or /lib/*.so) or stored internally in the DU.
> Should there be a distinction between DUs that are mainly library DUs
> (kind of plugins) and DUs that are apps.
Not sure if there is a need to differentiate.
> If we don't support library DUs - should the model be that the first DU
> that contains a needed LU will be used to import/link to that LU?
Not sure what you mean. Each DU declares contained list of LUs. These LUs may
declare dependencies. These dependencies are attempted to be resolved by
searching for a way to satisfy the set of required LUs without having
conflicting LUs.
ie if LU A depends upon JAXP 1.0 and LU B depends upon JAXP 1.1 then the
container could choose to provide a Jaxp 1.1, Jaxp 1.2 or Jaxp 1.1.1 LU to
them. However it could not provide a Jaxp 2.0 LU (incompatible versions) or a
Jaxp 1.0 LU (incompatibel with LU B.
> * Dependant DUs
> I think it would make sense to be able to state that for instance the DU
> a.du depends on b.du to there. (dependency not only on a lu level)
yep.
> * Exportable/Unexportable LUs
> I think the DU should be able to declare whether certain contained LUs
> should be exportable. If a DU declares a LU to be exportable, other DUs
> can link to it. (code sharing)
I would HATE that as then if someone removes one DU it could zonk an innocent
bystanding DU.
> * Dependecy information
>
> Where should the LU dependency (which means depending on certain LUs) go
> to?
Optional Package spec is suitable.
> * DU usagae scenarios
>
> The question: Who uses as DU, and how?
> In my opinion: Depends on the environment. [As you said]
yep.
> What I would very much like here is also some kind of security
> information, for instance what permissions are used and which are needed
> in order for the DU to run.
It depends on the particular type of DU. Phoenix already provides this by
allowing develoeprs to define policy configuration for DU.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block
Support]
Posted by Stephen McConnell <mc...@apache.org>.
Jakob Praher wrote:
>As I've written in a previos mail, I would like to write a proposal in
>avalon wiki, concerning:
>
>* Deployment Techniques in Avalon Containers
>[ DUs, LUs, Bundles, Blocks, ... ]
>
>* Usage scenarios for DeployableUnits in container environemnts
>[ DUs in App-Containers, Cocoon, ... ]
>
>I hope that this pages document the efforts for dynamic loadable and
>adaptive DU support in containers.
>
>I will post more on this as soon as I have written something.
>
>Question: What's the best term to denote the features we are discussing
>regarding DUs:
>
>- Hot deployable [ this is probably to weak ]
>- Runtime Adaptable Containers [ is adaptable or adaptive the right
>term here? ]
>
...."Adaptive Containment"
Cheers, Steve.
>- ?
>
>
>
>Am Sam, 2003-04-26 um 23.25 schrieb Stephen McConnell:
>
>
>>Jakob Praher wrote:
>>
>>
>>
>>>Am Sam, 2003-04-26 um 17.35 schrieb Stephen McConnell:
>>>
>>>
>>>
>
>
>
>
>>Feedback welcome - I'm famouse for writing things that nobody
>>understands so feel free to put up suggestions for improvements.
>>:-)
>>
>>
>
>For me it was well written. Allthough I have to get to know some of the
>concepts and I hope to go through the example, at least I have
>successfully done a
>
>$ maven merlin-install
>
>and am now ready to do some testing with merlin. - I will use your block
>tutorial for getting started - so look out for my questions ;-)
>
><personal-interest>
>I noticed that earlier versions that you migrated towards maven - how
>tough was it - since its already a bigger project and you probably had
>to do some maven customization ... .
></personal-interest>
>
>
>
>>>
>>>
>>>
>>>
>>>>>Questions and Design discussion:
>>>>>
>>>>>
>>I think we can summarise it as:
>>
>> a) a container is responsible for the deployment of a DU
>>
>>
>yup.
>
>
>> b) a DU may declare logical and physical dependencies
>> c) logical dependencies are resolved by a container through
>>deployment of other DU
>>
>>
>yup.
>
>
>
>> d) physical dependencies are resolved by a container based on jar
>>opional extension dependency declarations
>>
>>
>exactly.
>
>
>>I.e. the distinction between a DU and an LU is that a DU should be
>>viewed as a computation unit whereas a LU is simply a physical artifact.
>>
>>
>>
>
>Ok this sounds good. I will try to work it into the wiki-draft.
>Allthough apps get deployed by the means of DUs the container
>loads services from LUs.
>I think hiding too much of LUs from the container makes the API too active
>again - What do you think?
>
>And there are many questions, how inter DU relationship should be modelled,
>as there are so many different scenarios - I will address these issues in
>another mail.
>
>
>
>>
>>
>>>Perhaps its also a good rule that DUs only contain that LUs that are
>>>specific to that LUs or LUs with which there are conflicts.
>>>
>>>
>>>
>>>
>>Maybe (but I have reervations). I do think there is scope for an
>>application bundle which can be condiered as a source for LUs and DUs -
>>for example, if I want to deploy James as a DU and lets imagine that
>>James has logical dependecies on a couple of Cornerstone DUs and
>>structural dependencies on a bunch of Excalibur LUs (jar files). It is
>>convinient if there is a application model that I can reference from
>>which I can get any unresolved Dus or LUs. Part of this is driven by
>>liucensing requirements - for example I can bundle the Java Mail API in
>>a James application bundle and I can deploy a James DU by pulling out
>>the Java Mail jar from the application bundle and I'm 100% legal.
>>
>>
>
>Perhaps we could do some meta tagging of DUs, that is left to interpretation
>for the container. For instance the packager could add his
>"intention" or packaging "strategy" like avoid licensing problems.
>Perhaps that makes sense.
>I will think about it more thoroghly. The question we have to ask here is
>what we gain by this packaging strategy. I can imagine in certain
>environments that this could be helpful.
>
>Dealing with base apis like javamail api or jaxp or sth like that deserves its own
>thoughts. hmmm.
>
>
>
>
>>>We could then say that contained LUs are loaded by a DU specific
>>>classloader, but then again linking to that LUs is problematic, hmmm.
>>>
>>>
>>>
>>Why problamatic? Having a classloader load LU physical dependencies is
>>not a problem. This is exactly the approach taken in the Assembly
>>package. A classloader is associated with a classpath (LUs) and the
>>classloader handles expansion of the LU[] to include all of the
>>dependent LUs. Once the classloader is established, the DU[] is
>>established and the assembly process kicks in.
>>
>>
>
>I thik it is ideal as long as DUs are kind of islands.
>As soon as inter DU usage is needed this could become a little bit problematic.
>
>If we divide the LUs in specs and impls and load the specs in a common class loader
>and the impl in the DU class loader would perhaps work out - whats your opinion on that?
>[since the spec has its own version, we'd only had to reload the specs when a new spec
>version is introduced ] - spec version incompatibilites are another story though. In this
>case we should establish another spec class loader.
>
>
>
>>>Given that hierarchical class loading model introduced by [Brach98] is a
>>>kind of problem. For instance the jboss people demand for a flat class
>>>loading space.
>>>
>>>
>>>
>>JBoss can improve!
>>
>>
>you couldn't bee more right, but I threw it up since they had lots of
>IllegalAccessExceptions because of the class loader model.
>Especially inter DU relationsships could be a pain here - since then you
>have several class loader sub-trees.
>
>
>
>>The hierarchical class loading modelis fine providing you overlay on
>>that a service model that is not subject to the same restrictions. For
>>example - in a classloader hierachy A-B-C, you may have a component in C
>>that is producing a service that can be used in A or B. That's
>>orthoginal to the notion of isolation which typically addresses
>>implementation classes. However - to do this sort of thing you really
>>need to get your impl/inferface seperation sorted - and this isn't a
>>general practice.
>>
>>
>>
>>>But at the other hand DUs should not interfere with one another and
>>>theretically, sharing certain libs is good, but I've also often burned
>>>my fingers when updating certain apps to a certain version of, for
>>>instance xalan ;-)
>>>
>>>
>>>
>>>
>>Yep.
>>
>>In effect you need a mechanism (maybe just a the DU level) that lets you
>>override jar dependency information. This is achivable if you have
>>control over the extension source within a particular classloader. For
>>example, I can declare a classloader that is associated with a set of
>>extension locations - these locations get searched before location in
>>the parent classloader. This lets me put in place an alternative LU
>>resolution to handle those cases where you need a special version of the
>>same version (I you know what I mean).
>>
>>
>>
>>>I understand. I have mixed concerns here. All I wanted to say is that
>>>all the deployed DUs together might not provide all the required LUs.
>>>
>>>For instance you deploy 2 DUs, A and B.
>>>A contains LU libA and links to libB.
>>>B consains LU libB and links to libC.
>>>
>>>Now I thought it would be interesting to keep some kind of repository
>>>where libs that are not provided by any DU might be worth to get from an
>>>open repo.
>>>
>>>
>>>
>>This is the direction Merlin is heading in.
>>
>>
>>
>great.
>
>
>>OK
>>This sounds similar to what David Bernard is working on (see posts on
>>users@avalon).
>>
>>
>
>sounds interesting. Will check it out.
>Is the info solely in the mail-archive? (or something in cvs already)
>
>
>>
>>
>>
>
><big-snip />
>I'll try to answer the rest of our conversation tomorrow.
>(looking forward to ;-) )
>
>-- Jakob
>
>
>>>
>>>
>>>
>>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements
for Block Support]
Posted by Jakob Praher <jp...@yahoo.de>.
As I've written in a previos mail, I would like to write a proposal in
avalon wiki, concerning:
* Deployment Techniques in Avalon Containers
[ DUs, LUs, Bundles, Blocks, ... ]
* Usage scenarios for DeployableUnits in container environemnts
[ DUs in App-Containers, Cocoon, ... ]
I hope that this pages document the efforts for dynamic loadable and
adaptive DU support in containers.
I will post more on this as soon as I have written something.
Question: What's the best term to denote the features we are discussing
regarding DUs:
- Hot deployable [ this is probably to weak ]
- Runtime Adaptable Containers [ is adaptable or adaptive the right
term here? ]
- ?
Am Sam, 2003-04-26 um 23.25 schrieb Stephen McConnell:
> Jakob Praher wrote:
>
> >Am Sam, 2003-04-26 um 17.35 schrieb Stephen McConnell:
> >
>
> Feedback welcome - I'm famouse for writing things that nobody
> understands so feel free to put up suggestions for improvements.
> :-)
For me it was well written. Allthough I have to get to know some of the
concepts and I hope to go through the example, at least I have
successfully done a
$ maven merlin-install
and am now ready to do some testing with merlin. - I will use your block
tutorial for getting started - so look out for my questions ;-)
<personal-interest>
I noticed that earlier versions that you migrated towards maven - how
tough was it - since its already a bigger project and you probably had
to do some maven customization ... .
</personal-interest>
> >
> >
> >
> >>>Questions and Design discussion:
>
>
> I think we can summarise it as:
>
> a) a container is responsible for the deployment of a DU
yup.
> b) a DU may declare logical and physical dependencies
> c) logical dependencies are resolved by a container through
> deployment of other DU
yup.
> d) physical dependencies are resolved by a container based on jar
> opional extension dependency declarations
exactly.
>
> I.e. the distinction between a DU and an LU is that a DU should be
> viewed as a computation unit whereas a LU is simply a physical artifact.
>
Ok this sounds good. I will try to work it into the wiki-draft.
Allthough apps get deployed by the means of DUs the container
loads services from LUs.
I think hiding too much of LUs from the container makes the API too active
again - What do you think?
And there are many questions, how inter DU relationship should be modelled,
as there are so many different scenarios - I will address these issues in
another mail.
>
>
> >Perhaps its also a good rule that DUs only contain that LUs that are
> >specific to that LUs or LUs with which there are conflicts.
> >
> >
>
> Maybe (but I have reervations). I do think there is scope for an
> application bundle which can be condiered as a source for LUs and DUs -
> for example, if I want to deploy James as a DU and lets imagine that
> James has logical dependecies on a couple of Cornerstone DUs and
> structural dependencies on a bunch of Excalibur LUs (jar files). It is
> convinient if there is a application model that I can reference from
> which I can get any unresolved Dus or LUs. Part of this is driven by
> liucensing requirements - for example I can bundle the Java Mail API in
> a James application bundle and I can deploy a James DU by pulling out
> the Java Mail jar from the application bundle and I'm 100% legal.
Perhaps we could do some meta tagging of DUs, that is left to interpretation
for the container. For instance the packager could add his
"intention" or packaging "strategy" like avoid licensing problems.
Perhaps that makes sense.
I will think about it more thoroghly. The question we have to ask here is
what we gain by this packaging strategy. I can imagine in certain
environments that this could be helpful.
Dealing with base apis like javamail api or jaxp or sth like that deserves its own
thoughts. hmmm.
>
> >We could then say that contained LUs are loaded by a DU specific
> >classloader, but then again linking to that LUs is problematic, hmmm.
> >
>
> Why problamatic? Having a classloader load LU physical dependencies is
> not a problem. This is exactly the approach taken in the Assembly
> package. A classloader is associated with a classpath (LUs) and the
> classloader handles expansion of the LU[] to include all of the
> dependent LUs. Once the classloader is established, the DU[] is
> established and the assembly process kicks in.
I thik it is ideal as long as DUs are kind of islands.
As soon as inter DU usage is needed this could become a little bit problematic.
If we divide the LUs in specs and impls and load the specs in a common class loader
and the impl in the DU class loader would perhaps work out - whats your opinion on that?
[since the spec has its own version, we'd only had to reload the specs when a new spec
version is introduced ] - spec version incompatibilites are another story though. In this
case we should establish another spec class loader.
>
> >Given that hierarchical class loading model introduced by [Brach98] is a
> >kind of problem. For instance the jboss people demand for a flat class
> >loading space.
> >
>
> JBoss can improve!
you couldn't bee more right, but I threw it up since they had lots of
IllegalAccessExceptions because of the class loader model.
Especially inter DU relationsships could be a pain here - since then you
have several class loader sub-trees.
>
> The hierarchical class loading modelis fine providing you overlay on
> that a service model that is not subject to the same restrictions. For
> example - in a classloader hierachy A-B-C, you may have a component in C
> that is producing a service that can be used in A or B. That's
> orthoginal to the notion of isolation which typically addresses
> implementation classes. However - to do this sort of thing you really
> need to get your impl/inferface seperation sorted - and this isn't a
> general practice.
>
> >But at the other hand DUs should not interfere with one another and
> >theretically, sharing certain libs is good, but I've also often burned
> >my fingers when updating certain apps to a certain version of, for
> >instance xalan ;-)
> >
> >
>
> Yep.
>
> In effect you need a mechanism (maybe just a the DU level) that lets you
> override jar dependency information. This is achivable if you have
> control over the extension source within a particular classloader. For
> example, I can declare a classloader that is associated with a set of
> extension locations - these locations get searched before location in
> the parent classloader. This lets me put in place an alternative LU
> resolution to handle those cases where you need a special version of the
> same version (I you know what I mean).
>
> >
> >I understand. I have mixed concerns here. All I wanted to say is that
> >all the deployed DUs together might not provide all the required LUs.
> >
> >For instance you deploy 2 DUs, A and B.
> >A contains LU libA and links to libB.
> >B consains LU libB and links to libC.
> >
> >Now I thought it would be interesting to keep some kind of repository
> >where libs that are not provided by any DU might be worth to get from an
> >open repo.
> >
>
> This is the direction Merlin is heading in.
>
great.
>
>
> OK
> This sounds similar to what David Bernard is working on (see posts on
> users@avalon).
sounds interesting. Will check it out.
Is the info solely in the mail-archive? (or something in cvs already)
>
>
>
<big-snip />
I'll try to answer the rest of our conversation tomorrow.
(looking forward to ;-) )
-- Jakob
>
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block
Support]
Posted by Stephen McConnell <mc...@apache.org>.
Jakob Praher wrote:
>Am Sam, 2003-04-26 um 17.35 schrieb Stephen McConnell:
>
>
>>Jakob:
>>
>>Have been busy on other things and havn't been able to get into this
>>thread too much - but I've been reading everything with interest. I've
>>included by Saturday afternoon 00.02 euros inline.
>>
>>Cheers, Steve.
>>
>>
>thanks Steve for joining, I have noticed your new tutorial of block
>composition - look forward to reading it ;-)
>
Feedback welcome - I'm famouse for writing things that nobody
understands so feel free to put up suggestions for improvements.
:-)
>
>
>
>>>Questions and Design discussion:
>>>
>>>* Library DUs
>>>
>>>LUs are loaded by DUs - period.
>>>
>>>
>>>
>>Ummmm - LUs basically equate to a jar file and a jar file can contain
>>declaration of dependencies. As such, the loading of LU1 may imply the
>>loading of LU2, LU3, LUx.
>>
>>
>
>the word loaded was wrong, sorry I meant *deployed* by DUs. And of
>course dependent loading (like every good loader/linker does) is
>important.
>
>
I think we can summarise it as:
a) a container is responsible for the deployment of a DU
b) a DU may declare logical and physical dependencies
c) logical dependencies are resolved by a container through
deployment of other DU
d) physical dependencies are resolved by a container based on jar
opional extension dependency declarations
I.e. the distinction between a DU and an LU is that a DU should be
viewed as a computation unit whereas a LU is simply a physical artifact.
>
>
>>>Example:
>>>the provides and depends would be implemented with the Java Optional
>>>Package Manifest entries.
>>>
>>>
>>>
>>>
>>>
>><snip manifest content>
>>
>>There are problems with putting stuff into manifests - basically there
>>are assumptions made in some of Sun's tools that result in you DU being
>>unusable in ap-plication scenarios. It's much better to implant the
>>logic into a internal descriptor - for example Merlin blocks (an example
>>of a DU) contain a block.xml descriptor that contains information about
>>dependencies and services but does it in a way that is indepenndent of
>>the manifest (BLOCK-INF/block.xml).
>>
>>
>
>LUs are jar files. Here it makes sence to state the dependency using the
>optional package Manifest attributes. One reason why I think this is
>important is, that for instance a LU could then be reused that was
>packaged using this Specification, which for LUs I think is at least the
>mimium:
> - The Specification and the version which it provides
> - The Implementation Id and the Version
> - Dependecy on other LUs
>
>On the DU side you are right. I think here an internal descriptor does
>make sense.
>
>
>
>>
>>
>>>If we don't support library DUs - should the model be that the first DU
>>>that contains a needed LU will be used to import/link to that LU?
>>>if yes, this probably means that for a DU to be sure it *must* contain
>>>all the linked/dependency LUs.
>>>
>>>
>>>
>>Using the optional extensions package (or a repository model or
>>combination of both) this is not an issue. DU and/or LU that embedd jar
>>files within themselves are problamatic because the JDK classloaders do
>>not recognize jar:<filename>!/something url - instead you have to put in
>>place a manual unpacking scheme which means that your model is no longer
>>open. It is better to avaide inclusion of jar files and instead work
>>with the optional extensions spec.
>>
>>
>
>I also think it is a rule to link not contain LUs.
>
I agree.
>Perhaps its also a good rule that DUs only contain that LUs that are
>specific to that LUs or LUs with which there are conflicts.
>
>
Maybe (but I have reervations). I do think there is scope for an
application bundle which can be condiered as a source for LUs and DUs -
for example, if I want to deploy James as a DU and lets imagine that
James has logical dependecies on a couple of Cornerstone DUs and
structural dependencies on a bunch of Excalibur LUs (jar files). It is
convinient if there is a application model that I can reference from
which I can get any unresolved Dus or LUs. Part of this is driven by
liucensing requirements - for example I can bundle the Java Mail API in
a James application bundle and I can deploy a James DU by pulling out
the Java Mail jar from the application bundle and I'm 100% legal.
>We could then say that contained LUs are loaded by a DU specific
>classloader, but then again linking to that LUs is problematic, hmmm.
>
Why problamatic? Having a classloader load LU physical dependencies is
not a problem. This is exactly the approach taken in the Assembly
package. A classloader is associated with a classpath (LUs) and the
classloader handles expansion of the LU[] to include all of the
dependent LUs. Once the classloader is established, the DU[] is
established and the assembly process kicks in.
>Given that hierarchical class loading model introduced by [Brach98] is a
>kind of problem. For instance the jboss people demand for a flat class
>loading space.
>
JBoss can improve!
The hierarchical class loading modelis fine providing you overlay on
that a service model that is not subject to the same restrictions. For
example - in a classloader hierachy A-B-C, you may have a component in C
that is producing a service that can be used in A or B. That's
orthoginal to the notion of isolation which typically addresses
implementation classes. However - to do this sort of thing you really
need to get your impl/inferface seperation sorted - and this isn't a
general practice.
>But at the other hand DUs should not interfere with one another and
>theretically, sharing certain libs is good, but I've also often burned
>my fingers when updating certain apps to a certain version of, for
>instance xalan ;-)
>
>
Yep.
In effect you need a mechanism (maybe just a the DU level) that lets you
override jar dependency information. This is achivable if you have
control over the extension source within a particular classloader. For
example, I can declare a classloader that is associated with a set of
extension locations - these locations get searched before location in
the parent classloader. This lets me put in place an alternative LU
resolution to handle those cases where you need a special version of the
same version (I you know what I mean).
>
>
>>>Perhaps we could solve this by using an apt-get like mechanism for
>>>fetching certain LUs, when not available locally from somewhere. [when
>>>the user deploys the DU and a LU dependency ]. Are those then DUs? And
>>>if yes Library DUs?
>>>
>>>
>>>
>>>
>>Not really undertanding the above sentence (what is apt-get ?).
>>My experience is that you need to have a resolution service that is
>>implememtation independent. For example - you need a diifferent
>>resolution mechanisms when working in a servlet as compared to working
>>in the scope of an application.
>>
>>
>
>I understand. I have mixed concerns here. All I wanted to say is that
>all the deployed DUs together might not provide all the required LUs.
>
>For instance you deploy 2 DUs, A and B.
>A contains LU libA and links to libB.
>B consains LU libB and links to libC.
>
>Now I thought it would be interesting to keep some kind of repository
>where libs that are not provided by any DU might be worth to get from an
>open repo.
>
This is the direction Merlin is heading in.
>Plus the linked LUs, I assume, are most of the time libraries that are
>not specific to a ceratin AP (like a JAXP or JAXM impl).
>
>
Yep.
>apt-get info:
>sorry here. apt-get is the debian Application Tree fetcher. You have an
>/etc/apt/sources.list which is a repository reference file. When you for
>instance want to install my-app, it also automatically updates and or
>newly installs all dependent packages:
>
>$ apg-get my-app
>my-app depends on "lib-myapp" "lib-xml" "lib-xslt"
>want you .... [Y/n]
>
>
>
OK
This sounds similar to what David Bernard is working on (see posts on
users@avalon).
>
>
>>>* Dependant DUs
>>>I think it would make sense to be able to state that for instance the DU
>>>a.du depends on b.du to there. (dependency not only on a lu level)
>>>
>>>
>>>
>>>
>>I see DUs as a specialization of LUs. In that context there are
>>"structural" dependencies at the LU level and "logical" dependencies at
>>the DU level.
>>
>>
>
>I think we gain more if we make them seperate entities.
>Why: LUs are merely code entities with templates that give hints about
>their configuration, and DUs are deployable packages that in my view
>should be configured and ready to be used. Although the configuration
>should be customizable during deployment.
>
I don't see a conflict here.
If you take a look at the
sandbox\merlin\merlin-smp\src\tutorial\composition package you will find
an example of the usage of a set of resources in both scenarios.
Assuming you have Merlin installed ...
$ cd tutorial
$ cd composition
$ ant install
This generates a services of jar files:
composition-api-1.0.jar
composition-application-1.0.jar
composition-location-1.0.jar
composition-publisher-1.0.jar
Of the above, composition-api-1.0.jar is a LU (its just a jar file).
The other three are DU but they can also be used as LUs. To see this
all in action as pure LUs, you can execute the following demo:
$ merlin src\config\block2.xml
[INFO ] (sys): initialization: localhost
[INFO ] (sys): commencing block assembly phase
[INFO ] (application): servicing application
[INFO ] (application.locator): location: Paris
[INFO ] (application.publisher): created
[INFO ] (application.publisher):
******************
* Paris
******************
[INFO ] (application): done
[INFO ] (sys): Block hierarchy established.
[INFO ] (sys): commencing decommissioning phase
[INFO ] (application): disposal
[INFO ] (application.locator): disposal
[INFO ] (application.publisher): disposal
[INFO ] (sys): bye
In this case the block2.xml is simply a directive telling Merlin what to
do with these LUs. Here is the content of block2.xml. It simply
declars a classloader (the engine directive) that contains the four jar
files and a single directive to fire up the application component.
<block>
<info>
<name>tutorial</name>
</info>
<implementation>
<engine>
<classpath>
<repository>
<resource id="tutorial:composition-api" version="1.0"/>
<resource id="tutorial:composition-location" version="1.0"/>
<resource id="tutorial:composition-publisher" version="1.0"/>
<resource id="tutorial:composition-application" version="1.0"/>
</repository>
</classpath>
</engine>
<component name="application"
class="tutorial.application.Application" activation="startup"/>
</implementation>
</block>
Compare the above to the following block.xml directive. The difference
is that there is only one LU in the classloader - the rest of the
directives are treating the last jar fiels as DUs,
<block>
<info>
<name>tutorial</name>
</info>
<implementation>
<engine>
<classpath>
<repository>
<resource id="tutorial:composition-api" version="1.0"/>
</repository>
</classpath>
</engine>
<include id="tutorial:composition-publisher" version="1.0"/>
<include id="tutorial:composition-application" version="1.0"/>
<include id="tutorial:composition-location" version="1.0"/>
</implementation>
</block>
The import lines above are the includes -- they are establishing a set
of services and Merlin is doing the work of assembly of the DUs so that
everything makes sense (for example - the application DU has service
dependencies on a location service and a publishing service). Merlin
ensures that these DU are wired together before deployment based on
service level dependency resolution. This is something that hapens
after physical/structural dependecy resoution with respect to a DUs role
as an LU.
Executing the above directive can be done by:
$ merlin src\config\block.xml
[INFO ] (sys): initialization: localhost
[INFO ] (sys): commencing block assembly phase
[INFO ] (sys): Block hierarchy established.
[INFO ] (location-block.location): location: Paris
[INFO ] (location-block): initialization
[INFO ] (publisher-block.publisher): created
[INFO ] (application-block.application): servicing application
[INFO ] (publisher-block): initialization
[INFO ] (publisher-block): initialization
[INFO ] (publisher-block.publisher):
******************
* Paris
******************
[INFO ] (application-block.application): done
[INFO ] (application-block): initialization
In the above example - "publisher-block" is a DU that is providing a
publishing service. Same case for "location-block" - and
"application-block" is hosting "application". All three are DUs. But
as you can see - that function perfectly as LUs as well.
>
>In my view you should be able to throw a DU into a container and work
>with it.
>
>
Absolutely.
>>>* Exportable/Unexportable LUs
>>>I think the DU should be able to declare whether certain contained LUs
>>>should be exportable. If a DU declares a LU to be exportable, other DUs
>>>can link to it. (code sharing)
>>>
>>>
>>>
>>>
>>I would prefer exportable LU to be maintained seeperate - i.e. just use
>>the optional extension mecahnism.
>>
>>
>I also favor the DU
>
Switching to your other email - yes - your interpritation is correct -
just use the optional extension loading mechanism. Anything else should
be stated elsewhere.
>
>
>>>* Dependecy information
>>>
>>>Where should the LU dependency (which means depending on certain LUs) go
>>>to?
>>>
>>>
>>>
>>Inside a descriptor - not in the manifest.
>>
>>
>Not using the Optional Package Manifest Attributes?
>
For an LU, it structural dependecies should be declared in the manifest.
For a DU the dependencies are functional (ie. service dependecies and so
on) and these should be included in a DU descriptor (e.g. block.xml).
>
>
>
>>>Does it make sense to put it in the DU meta descriptor?
>>>
>>>
>>>
>>Yes.
>>
>>
>Think so too.
>
>
>
>>>If DUs itself contain code (which is probably a hack anyway) yes,
>>>otherwise the LU dependency information should go into the LU.
>>>
>>>
>>>
>>DU dependency information should about services that are available from
>>another DU.
>>LU dependency information is structural and can be handled at the level
>>of extension dependecies.
>>
>>
>exactly.
>
>
>
>>>The DU can recursively question all its containing LUs which
>>>dependencies they have and so compile a list of depending LU for the
>>>whole DU.
>>>
>>>
>>>
>>>
>>This should not be the resolsibility of a DU. A container should be
>>taking a DU and/or LU information and resolving everything needed for
>>deployment. The DU itself should not be concerned as to the mechanisms
>>used to achieve this.
>>
>>
>>
>Ok this was a too active approach taken by me. Given the different
>container scenarios you are absolutely right here.
>
>
>
>>>Configuration: XML Schema/Profile Template language.
>>>[Implementation Note] This could get distilled from the @doclet tags.
>>>
>>>
>>>
>>Don't think so.
>>Defintion of a DU is a a lot more complex than a component type.
>>
>>
>Clearly, but a LU must offer some configuration templates, which when
>you build a DU, get compiled together to form a configuration meta
>information for this DU.
>
Yep. But keep in mind that your dealing with:
(a) type descriptors
(b) servive descriptors
(c) defaults associated with a type
(d) deployment templates
(e) deployment scenarios
(f) overriding configurations
So far, just doing (a-b) with javadioc tags is only OK for the simple
cases (but does cover probably 90% of real world requirements). My own
opinion is that interactive tools are things needed to support (c-f).
>Using this schema the DU packager can then state some configuration
>decisions, which go inside a meta descriptor (sth. like a xconf file on
>a per DU basis).
>
Just for reference - there is a tutorial specifically about handling
multiple configuration.
$ cd tutorial
$ cd includes
$ ant install
$ merlin src\config\block.xml
[INFO ] (sys): initialization: localhost
[INFO ] (sys): commencing block assembly phase
[INFO ] (test1): source: config.xml
[INFO ] (sys): Block hierarchy established.
[INFO ] (subcontainer.test2): source: config.xml
[INFO ] (subcontainer): initialization
[INFO ] (subcontainer.composite): initialization
[INFO ] (subcontainer.inclusion.test3): source: config.xml
[INFO ] (subcontainer.inclusion): initialization
[INFO ] (subcontainer.composite.inclusion.test3): source: config.xml
[INFO ] (subcontainer.composite.inclusion): initialization
[INFO ] (subcontainer.composite.test): initialization
[INFO ] (subcontainer.composite.test.inclusion.test3): source:
include-config.xml
[INFO ] (subcontainer.composite.test.inclusion): initialization
[INFO ] (sys): commencing decommissioning phase
[INFO ] (sys): bye
The above block.xml contains directives to use a variety of different
configuration sources - any you can see from the output that the source
of the configration for particular components is being overriden.
>The deployer then should have the means to override the default
>configuration in the DU.
>
Yep.
>Plus the packager could leave certain configurations open for the
>deployer which at packaging time can not be answered successfully (smtp
>host or sth. like this)
>
Yep.
E.g. James admin username and password - you want to package the
standard configuration as a application profile (block.xml) and then
override this with a couple of fragments (in Merlin these are referred
to as override Targets).
>
>GUI/Console UI support here would be great (something like debconf
>(debian configuration) mechanism.) It is important to also support
>console UI since ssh is a very popular deployment utility ;-).
>
>
Agreed.
>But once again, I think the LUs should contain the information, what
>*is* configurable.
>
>For instance take a service implemented by MyComponent that resides in
>xyz.lu (ending for clarity sake ;-) - should be jar).
>
>class MyComponent implements .. Configurable ..
>{
> public void configure( Configuration conf )
> throws ConfigurationExecption
> {
> /* conf here */
>
> }
>}
>
>this component should define, in a schema (which format is more or less
>a question of preference XSD, Relax, ...), which configuration settings
>there are:
>
><configuration-schema service="x.y.z.SuperService" >
>
> <xsd:element type="xsd:string" name="smtp-host" />
>
> <xsd:element name="prefereed-color">
> <xsd:simpleType>
> <xsd:restrition type="xsd:string">
> <xsd:enumeration value="blue" />
> <xsd:enumeration value="red" />
> <xsd:enumeration value="..." />
> </xsd:restriction>
> </xsd:simpleType>
> </xsd:element>
>
></configuration-schema>
>
>this is just to stress what I mean with configuration templates.
>
>
This is something I would like to see in Merlin - does not exist at the
moment. Merlin provides configuration profile but does not include
configuration meta information - i.e. no information about what is
allowable inside a configuration. It's about the only thing missing on
the (a-f) list mentioned above.
Cheers, Steve.
>
>-- Jakob
>
>--------
>[Bracha98] http://java.sun.com/people/gbracha/classloaders.ps
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for
Block Support]
Posted by Jakob Praher <jp...@yahoo.de>.
Am Sam, 2003-04-26 um 21.02 schrieb Jakob Praher:
> >
> > >* Exportable/Unexportable LUs
> > >I think the DU should be able to declare whether certain contained LUs
> > >should be exportable. If a DU declares a LU to be exportable, other DUs
> > >can link to it. (code sharing)
> > >
> > >
> >
> > I would prefer exportable LU to be maintained seeperate - i.e. just use
> > the optional extension mecahnism.
> I also favor the DU
sorry my answer is plain stupid. But how do you mean "just use the
optional extension mech." - I suppose you it meant that LU info should
use the optional extension mechanism, nothing more. Everything else
should be stated elsewhere?
[so in the DU meta descriptor - ?]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for
Block Support]
Posted by Jakob Praher <jp...@yahoo.de>.
Am Sam, 2003-04-26 um 17.35 schrieb Stephen McConnell:
> Jakob:
>
> Have been busy on other things and havn't been able to get into this
> thread too much - but I've been reading everything with interest. I've
> included by Saturday afternoon 00.02 euros inline.
>
> Cheers, Steve.
thanks Steve for joining, I have noticed your new tutorial of block
composition - look forward to reading it ;-)
>
> >
> >Questions and Design discussion:
> >
> >* Library DUs
> >
> >LUs are loaded by DUs - period.
> >
>
> Ummmm - LUs basically equate to a jar file and a jar file can contain
> declaration of dependencies. As such, the loading of LU1 may imply the
> loading of LU2, LU3, LUx.
the word loaded was wrong, sorry I meant *deployed* by DUs. And of
course dependent loading (like every good loader/linker does) is
important.
>
> >
> >Example:
> >the provides and depends would be implemented with the Java Optional
> >Package Manifest entries.
> >
> >
> >
> <snip manifest content>
>
> There are problems with putting stuff into manifests - basically there
> are assumptions made in some of Sun's tools that result in you DU being
> unusable in ap-plication scenarios. It's much better to implant the
> logic into a internal descriptor - for example Merlin blocks (an example
> of a DU) contain a block.xml descriptor that contains information about
> dependencies and services but does it in a way that is indepenndent of
> the manifest (BLOCK-INF/block.xml).
LUs are jar files. Here it makes sence to state the depenency using the
optional package Manifest attributes. One reason why I think this is
important is, that for instance a LU could then be reused that was
packaged using this Specification, which for LUs I think is at least the
mimium:
- The Specification and the version which it provides
- The Implementation Id and the Version
- Dependecy on other LUs
On the DU side you are right. I think here an internal descriptor does
make sense.
>
>
> >If we don't support library DUs - should the model be that the first DU
> >that contains a needed LU will be used to import/link to that LU?
> >if yes, this probably means that for a DU to be sure it *must* contain
> >all the linked/dependency LUs.
> >
>
> Using the optional extensions package (or a repository model or
> combination of both) this is not an issue. DU and/or LU that embedd jar
> files within themselves are problamatic because the JDK classloaders do
> not recognize jar:<filename>!/something url - instead you have to put in
> place a manual unpacking scheme which means that your model is no longer
> open. It is better to avaide inclusion of jar files and instead work
> with the optional extensions spec.
I also think it is a rule to link not contain LUs.
Perhaps its also a good rule that DUs only contain that LUs that are
specific to that LUs or LUs with which there are conflicts.
We could then say that contained LUs are loaded by a DU specific
classloader, but then again linking to that LUs is problematic, hmmm.
Given that hierarchical class loading model introduced by [Brach98] is a
kind of problem. For instance the jboss people demand for a flat class
loading space.
But at the other hand DUs should not interfere with one another and
theretically, sharing certain libs is good, but I've also often burned
my fingers when updating certain apps to a certain version of, for
instance xalan ;-)
>
> >
> >Perhaps we could solve this by using an apt-get like mechanism for
> >fetching certain LUs, when not available locally from somewhere. [when
> >the user deploys the DU and a LU dependency ]. Are those then DUs? And
> >if yes Library DUs?
> >
> >
>
> Not really undertanding the above sentence (what is apt-get ?).
> My experience is that you need to have a resolution service that is
> implememtation independent. For example - you need a diifferent
> resolution mechanisms when working in a servlet as compared to working
> in the scope of an application.
I understand. I have mixed concerns here. All I wanted to say is that
all the deployed DUs together might not provide all the required LUs.
For instance you deploy 2 DUs, A and B.
A contains LU libA and links to libB.
B consains LU libB and links to libC.
Now I thought it would be interesting to keep some kind of repository
where libs that are not provided by any DU might be worth to get from an
open repo.
Plus the linked LUs, I assume, are most of the time libraries that are
not specific to a ceratin AP (like a JAXP or JAXM impl).
apt-get info:
sorry here. apt-get is the debian Application Tree fetcher. You have an
/etc/apt/sources.list which is a repository reference file. When you for
instance want to install my-app, it also automatically updates and or
newly installs all dependent packages:
$ apg-get my-app
my-app depends on "lib-myapp" "lib-xml" "lib-xslt"
want you .... [Y/n]
>
> >
> >* Dependant DUs
> >I think it would make sense to be able to state that for instance the DU
> >a.du depends on b.du to there. (dependency not only on a lu level)
> >
> >
>
> I see DUs as a specialization of LUs. In that context there are
> "structural" dependencies at the LU level and "logical" dependencies at
> the DU level.
I think we gain more if we make them seperate entities.
Why: LUs are merely code entities with templates that give hints about
their configuration, and DUs are deployable packages that in my view
should be configured and ready to be used. Although the configuration
should be customizable during deployment.
In my view you should be able to throw a DU into a container and work
with it.
>
> >* Exportable/Unexportable LUs
> >I think the DU should be able to declare whether certain contained LUs
> >should be exportable. If a DU declares a LU to be exportable, other DUs
> >can link to it. (code sharing)
> >
> >
>
> I would prefer exportable LU to be maintained seeperate - i.e. just use
> the optional extension mecahnism.
I also favor the DU
>
> >* Dependecy information
> >
> >Where should the LU dependency (which means depending on certain LUs) go
> >to?
> >
>
> Inside a descriptor - not in the manifest.
Not using the Optional Package Manifest Attributes?
>
> >Does it make sense to put it in the DU meta descriptor?
> >
>
> Yes.
Think so too.
>
> >If DUs itself contain code (which is probably a hack anyway) yes,
> >otherwise the LU dependency information should go into the LU.
> >
>
> DU dependency information should about services that are available from
> another DU.
> LU dependency information is structural and can be handled at the level
> of extension dependecies.
exactly.
>
> >The DU can recursively question all its containing LUs which
> >dependencies they have and so compile a list of depending LU for the
> >whole DU.
> >
> >
>
> This should not be the resolvibility of a DU. A container shouold be
> taking a DU and/or LU information and resolving everything needed for
> deployment. The DU itself should not be concerned as to the mechanisms
> used to achieve this.
>
Ok this was a too active approach taken by me. Given the different
container scenarios you are absolutely right here.
>
> >Configuration: XML Schema/Profile Template language.
> >[Implementation Note] This could get distilled from the @doclet tags.
> >
>
> Don't think so.
> Defintion of a DU is a a lot more complex than a component type.
Clearly, but a LU must offer some configuration templates, which when
you build a DU, get compiled together to form a configuration meta
information for this DU.
Using this schema the DU packager can then state some configuration
decisions, which go inside a meta descriptor (sth. like a xconf file on
a per DU basis).
The deployer then should have the means to override the default
configuration in the DU.
Plus the packager could leave certain configurations open for the
deployer which at packaging time can not be answered successfully (smtp
host or sth. like this)
GUI/Console UI support here would be great (something like debconf
(debian configuration) mechanism.) It is important to also support
console UI since ssh is a very popular deployment utility ;-).
But once again, I think the LUs should contain the information, what
*is* configuratable.
For instance take a service implemented by MyComponent that resides in
xyz.lu (ending for clarity sake ;-) - should be jar).
class MyComponent implements .. Configurable ..
{
public void configure( Configuration conf )
throws ConfigurationExecption
{
/* conf here */
}
}
this component should define, in a schema (which format is more or less
a question of preference XSD, Relax, ...), which configuration settings
there are:
<configuration-schema service="x.y.z.SuperService" >
<xsd:element type="xsd:string" name="smtp-host" />
<xsd:element name="prefereed-color">
<xsd:simpleType>
<xsd:restrition type="xsd:string">
<xsd:enumeration value="blue" />
<xsd:enumeration value="red" />
<xsd:enumeration value="..." />
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</configuration-schema>
this is just to stress what I mean with configuration templates.
-- Jakob
--------
[Bracha98] http://java.sun.com/people/gbracha/classloaders.ps
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block
Support]
Posted by Stephen McConnell <mc...@apache.org>.
Jakob:
Have been busy on other things and havn't been able to get into this
thread too much - but I've been reading everything with interest. I've
included by Saturday afternoon 00.02 euros inline.
Cheers, Steve.
Jakob Praher wrote:
>hi Peter,
>hi all,
>
>for everyone joining the discussion:
>[LU .. Library Unit]
>[DU .. Deployable Unit]
>
>I distilled our ongoing discussion (which I find very constructive and
>interesting) about DUs and LUs in a new message to decrement the entropy
>level. [;-)]
>
>
>Regarding Bundles (Berin)
>
>I have followed the thread on Bundles with great interest, an am very
>glad that you brought up the discussion. I have looked at CFBundle and
>CFPlugin (which is a lightweight COM spec on top of CFBUndle). In
>Peter's terms CFBundle would be described as DU. [please correct me if I
>am wrong in your opion] - It can contain executable code, library code,
>configuration and resources (localizables and global resources). I think
>we could look at some of the structures (plist especially). I must
>confess I have never used the CFBundle API, but would like to by a
>Titanium, if I had enough money.
>
>
>API Design [Active vs Passive]
>
>If I got that right, you mean that the class represenatatives of LUs and
>DUs should only contain the meta information (merely data), not
>algorithms how to do something with them, except very simple things.
>This is something you do with XxxService or XxxManager clases - right?
>
>
>Questions and Design discussion:
>
>* Library DUs
>
>LUs are loaded by DUs - period.
>
Ummmm - LUs basically equate to a jar file and a jar file can contain
declaration of dependencies. As such, the loading of LU1 may imply the
loading of LU2, LU3, LUx.
>Not all DUs provide all the LUs. (which mean contains).
>Should there be a distinction between DUs that are mainly library DUs
>(kind of plugins) and DUs that are apps.
>
Why?
The notion of app is simply a DU that does not expose/export/publish a
service. That's not much of a distinction if you DU model supports
publication of 0..n services.
>
>Example:
>the provides and depends would be implemented with the Java Optional
>Package Manifest entries.
>
>
>
<snip manifest content>
There are problems with putting stuff into manifests - basically there
are assumptions made in some of Sun's tools that result in you DU being
unusable in ap-plication scenarios. It's much better to implant the
logic into a internal descriptor - for example Merlin blocks (an example
of a DU) contain a block.xml descriptor that contains information about
dependencies and services but does it in a way that is indepenndent of
the manifest (BLOCK-INF/block.xml).
>If we don't support library DUs - should the model be that the first DU
>that contains a needed LU will be used to import/link to that LU?
>if yes, this probably means that for a DU to be sure it *must* contain
>all the linked/dependency LUs.
>
Using the optional extensions package (or a repository model or
combination of both) this is not an issue. DU and/or LU that embedd jar
files within themselves are problamatic because the JDK classloaders do
not recognize jar:<filename>!/something url - instead you have to put in
place a manual unpacking scheme which means that your model is no longer
open. It is better to avaide inclusion of jar files and instead work
with the optional extensions spec.
>
>Perhaps we could solve this by using an apt-get like mechanism for
>fetching certain LUs, when not available locally from somewhere. [when
>the user deploys the DU and a LU dependency ]. Are those then DUs? And
>if yes Library DUs?
>
>
Not really undertanding the above sentence (what is apt-get ?).
My experience is that you need to have a resolution service that is
implememtation independent. For example - you need a diifferent
resolution mechanisms when working in a servlet as compared to working
in the scope of an application.
>
>* Dependant DUs
>I think it would make sense to be able to state that for instance the DU
>a.du depends on b.du to there. (dependency not only on a lu level)
>
>
I see DUs as a specialization of LUs. In that context there are
"structural" dependencies at the LU level and "logical" dependencies at
the DU level.
>* Exportable/Unexportable LUs
>I think the DU should be able to declare whether certain contained LUs
>should be exportable. If a DU declares a LU to be exportable, other DUs
>can link to it. (code sharing)
>
>
I would prefer exportable LU to be maintained seeperate - i.e. just use
the optional extension mecahnism.
>* Dependecy information
>
>Where should the LU dependency (which means depending on certain LUs) go
>to?
>
Inside a descriptor - not in the manifest.
>Does it make sense to put it in the DU meta descriptor?
>
Yes.
>If DUs itself contain code (which is probably a hack anyway) yes,
>otherwise the LU dependency information should go into the LU.
>
DU dependency information should about services that are available from
another DU.
LU dependency information is structural and can be handled at the level
of extension dependecies.
>The DU can recursively question all its containing LUs which
>dependencies they have and so compile a list of depending LU for the
>whole DU.
>
>
This should not be the resolvibility of a DU. A container shouold be
taking a DU and/or LU information and resolving everything needed for
deployment. The DU itself should not be concerned as to the mechanisms
used to achieve this.
>
>* DU usagae scenarios
>
>The question: Who uses as DU, and how?
>
DU can be used by people or applications that are assembly new components.
>In my opinion: Depends on the environment. [As you said]
>
>- ECM Style container environment:
>Most of the time use will stay within the DU itself. The only thing that
>occurs that some LUs are not contained but external used. Or on the
>other hand if the DU itself provides LUs to other DUs. (bidirectional)
>
>Here some kind of micro kernel would make sense.
>DU unloading/loading listeners would also make sense, which other DUs
>can subscribe to. [as you already said]
>
>- Cocoon/Webapp Style container environment:
>The Core framework, for instance Sitemap Processor, will use the DUs to
>satisfy requests.
>If every usage would be bounded to a request/response cycle, everything
>would be find, but: Session state! - Some classes of a DU/LU might get
>stored in a session state.
>
>* Configuration and Meta Data
>
>How should we define profiles/meta data?
>
>
Yes.
>Configuration: XML Schema/Profile Template language.
>[Implementation Note] This could get distilled from the @doclet tags.
>
Don't think so.
Defintion of a DU is a a lot more complex than a component type.
Cheers, SJM.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
Sent via James running under Merlin as an NT service.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
LUs,DUs,Bundles [Was: [RT] Distilling the requirements for Block
Support]
Posted by Jakob Praher <jp...@yahoo.de>.
hi Peter,
hi all,
for everyone joining the discussion:
[LU .. Library Unit]
[DU .. Deployable Unit]
I distilled our ongoing discussion (which I find very constructive and
interesting) about DUs and LUs in a new message to decrement the entropy
level. [;-)]
Regarding Bundles (Berin)
I have followed the thread on Bundles with great interest, an am very
glad that you brought up the discussion. I have looked at CFBundle and
CFPlugin (which is a lightweight COM spec on top of CFBUndle). In
Peter's terms CFBundle would be described as DU. [please correct me if I
am wrong in your opion] - It can contain executable code, library code,
configuration and resources (localizables and global resources). I think
we could look at some of the structures (plist especially). I must
confess I have never used the CFBundle API, but would like to by a
Titanium, if I had enough money.
API Design [Active vs Passive]
If I got that right, you mean that the class represenatatives of LUs and
DUs should only contain the meta information (merely data), not
algorithms how to do something with them, except very simple things.
This is something you do with XxxService or XxxManager clases - right?
Questions and Design discussion:
* Library DUs
LUs are loaded by DUs - period.
Not all DUs provide all the LUs. (which mean contains).
Should there be a distinction between DUs that are mainly library DUs
(kind of plugins) and DUs that are apps.
Example:
the provides and depends would be implemented with the Java Optional
Package Manifest entries.
LU: trax-Transformer-XYZ.lu { povides: trax-Transformer/1.0 }
trax-Using-App1.lu { provides: x.y.z/0.3; dependencies:
trax-Transformer/1.0 }
trax-Using-App1.du { libraries: { trax-Using-App1.lu} , conf: { } }
trax-Using-App2.lu { provides: foo-bar/0.5; dependencies:
trax-Transformer/1.0 }
trax-Using-App2.du { libraries: { trax-Using-App2.lu }, conf: { } }
If we don't support library DUs - should the model be that the first DU
that contains a needed LU will be used to import/link to that LU?
if yes, this probably means that for a DU to be sure it *must* contain
all the linked/dependency LUs.
Perhaps we could solve this by using an apt-get like mechanism for
fetching certain LUs, when not available locally from somewhere. [when
the user deploys the DU and a LU dependency ]. Are those then DUs? And
if yes Library DUs?
* Dependant DUs
I think it would make sense to be able to state that for instance the DU
a.du depends on b.du to there. (dependency not only on a lu level)
* Exportable/Unexportable LUs
I think the DU should be able to declare whether certain contained LUs
should be exportable. If a DU declares a LU to be exportable, other DUs
can link to it. (code sharing)
* Dependecy information
Where should the LU dependency (which means depending on certain LUs) go
to?
Does it make sense to put it in the DU meta descriptor?
If DUs itself contain code (which is probably a hack anyway) yes,
otherwise the LU dependency information should go into the LU.
The DU can recursively question all its containing LUs which
dependencies they have and so compile a list of depending LU for the
whole DU.
* DU usagae scenarios
The question: Who uses as DU, and how?
In my opinion: Depends on the environment. [As you said]
- ECM Style container environment:
Most of the time use will stay within the DU itself. The only thing that
occurs that some LUs are not contained but external used. Or on the
other hand if the DU itself provides LUs to other DUs. (bidirectional)
Here some kind of micro kernel would make sense.
DU unloading/loading listeners would also make sense, which other DUs
can subscribe to. [as you already said]
- Cocoon/Webapp Style container environment:
The Core framework, for instance Sitemap Processor, will use the DUs to
satisfy requests.
If every usage would be bounded to a request/response cycle, everything
would be find, but: Session state! - Some classes of a DU/LU might get
stored in a session state.
* Configuration and Meta Data
How should we define profiles/meta data?
Configuration: XML Schema/Profile Template language.
[Implementation Note] This could get distilled from the @doclet tags.
What I would very much like here is also some kind of security
information, for instance what permissions are used and which are needed
in order for the DU to run. [this information must be provided by LU
developer?, packaged with the LU metadata.]
In current environments (especially WAR) configuring the security.policy
is a pain since you don't know in adavnce what security dependencies
exist [I often end up giving a java.security.AllPermission.] This would
be a major relieve for the deployer/sysadmin.
-- Jakob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 25 Apr 2003 00:08, Jakob Praher wrote:
> What do you see is the Configuration of a LU?
Essentially I see LUs as not being configurable at all.
> -> I would think that a ceratin amount of configuraiton (for isntance
> default values, ... ) could be counted as LU also?
This is what I have been referring to as templates/profiles. Essentially it is
data that could be extracted from LU and be used to autocreate a DU.
> So do you think that DUs shouldn't contain code (or at least contain
> glue code?)
I am not sure. Ideally reusable code should be in LUs but several different DU
standards allow raw code in them. For example .sar files have
SAR-INF/classes, .wars have WAR-INF/classes etc
> How would this be packaged in practice?
>
> LU would be a jar files with a manifest that contains:
> -> version
> -> compatibilty information (in the simple case of the
> major.minor.micro the compaitibilty can be derived from the version )
Actually I would say it declares itself as an optional package. (See
guide/extensions/versioning.html in jdk1.3+ docs).
> DU would be a wrapper package (like the .war or [wsb]ar files), that
> contains:
yep.
> -> embedded LUs (you call it contains)
> (these are packaged within the DU, is it exportable then?)
not sure what you mean by "exportable"?
> -> linked LUs
> -> depency information (something like the plugin mechanism)
> So what I would like to have is a sort of design document, that stays in
> avalon-wiki, where we keep track the discussion. We can have differnent
> versions, but we should somehow document the effort. And I hope to play
> with some code really soon ;-)
kool!
> What about the loading mechanics?
Your design is an "active" design which is something I tend to avoid. In
general I would probably implement it by something like the following (Note
that Extension defines an optional package - see excalibur-extension package
for more details on that class). Librarys are fairly easy to model - see the
following;
class LibraryMetaData
{
File getLocation(); //Usually refers to jar but can refer to
//dir or xml descriptor
Extension getExtension();
Extension[] getAvailableExtensions(); //extensions we export
Extension[] getRequiredExtensions(); //extensions we import
ResourceMetaData[] getResourcess(); //resources we export
}
class LibraryEntry
{
LibraryMetaData getMetaData();
LibraryEntry[] getImports(); //list of librarys we actually import
ClassLoader getClassLoader();
}
interface LibraryLoaderService
{
LibraryMetaData loadLibrary( File location );
}
interface LibraryRepositoryService
{
LibraryRealm createRealm();
LibraryEntry resolveLibrary( LibraryRealm realm, LibraryMetaData library );
}
Deployable units are much harder to model and I don't really know how to do
it. I have tried a few approaches but it is hard to get a model that is
generic enough to satisfy all of our demands. Essentially I think we will
have to build sepcific deployer/DU Manager for each different DU type (ie cob
vs maven plugin vs .sar file).
> Only DeployableUnits will be *deployed* (hence their name - or?)
yep.
> [LUs will be loaded by the means of DUs - or am I misinterpreting
> something ?]
nope - your on the money. LUs will be loaded as a side-effect of DUs loading.
> How does the container manage updates?
In Phoenix each of the DUs are isolated from other DUs and thus can be
unloaded and reloaded at will. When you have one DU depending on another DU
then it is impossible to unload/reload safely unless there is isolation
between the two DUs. In which case you can sorta get away with it.
The way you get away with it is the following;
* create an interceptor between inter-DU service calls.
* Consider case where component in DU1 makes call on service in DU2. If DU2 is
to be reloaded then we tell the interceptor to suspend calls. So any calls to
DU2 will be suspended until DU2 is reloaded.
* we unload old DU2 and reload new DU2
* we tell DU1 that DU2 is reloaded (if it had registered a listener for that
event)
* we unsuspend the interceptor and calls continue as usual
> It is very important look at the client side too:
>
> What the container/its client want is a way to access these resources
>
> Say Client C wants a reference to Service MyService:
>
> MyService s = container.lookup( MyService.ROLE );
>
> the container in turn will look through the registered/available DUs,
> and checks whether someone exports this component.
Again - I think it depends on the particula DU being created because in some
cases (think .sar or .war) this makes no sense. In others such as osgi or
Cocoon it does make sense.
> <myview>
> Deployment of Units is more or less a user triggered action, like moving
> the mouse or pressing the keyboard, since the sysamdin or deployer, at
> any given time, choses to update or replace a deployed unit.
agreed.
> Of course ther is much more to say on this topic. I would really like to
> get a written spec out of these discussions someday ;-).
kool. Feel free to start it in wiki and I will try to add to it when I can.
> > It is sorta ironic that the most advanced and
> > active Avalon container is not built by Avalon peeps.
>
> But on the other hand shows that Avalon is used and extended by various
> Apache (and of course non Apache) projects, I think thats quite good, as
> long as the changes get merged into Avalon (if they are worth it) [ or
> else we have too much friction in the container landscape ]
I doubt that the container parts will ever get merged back into Avalon
regardless of merit. But given the path that Avalon is now taking I think you
will see more friction in the container landscape anyways so I don't think
thats an issue.
--
Cheers,
Peter Donald
*--------------------------------------------*
| "You can't fight in here! This is the war |
| room!" -Dr. Strangelove |
*--------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Leo Simons <le...@apache.org>.
take a look at the maven-new cvs module in apache cvs and the
plexus-container-new module in plexus cvs. Talks are on the plexus-dev
mailing list (see plexus.codehaus.org) and the maven-dev list.
There's no design documents archived I think.
cheers,
- Leo, lurks on mentioned lists :D
Jakob Praher wrote:
> Am Don, 2003-04-24 um 07.59 schrieb Peter Donald:
>
>>I mean maven. Maven is being rebuilt around an avalon + aspect based container
>>that essentially turns maven into a generic plugin based Avalon platform with
>>a request based architecture. It is sorta ironic that the most advanced and
>>active Avalon container is not built by Avalon peeps.
>
> is there anything I can look at? [Design Document]
> is there already something in cvs?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Jakob Praher <jp...@yahoo.de>.
Am Don, 2003-04-24 um 07.59 schrieb Peter Donald:
>
> I mean maven. Maven is being rebuilt around an avalon + aspect based container
> that essentially turns maven into a generic plugin based Avalon platform with
> a request based architecture. It is sorta ironic that the most advanced and
> active Avalon container is not built by Avalon peeps.
>
is there anything I can look at? [Design Document]
is there already something in cvs?
thanks
--Jakob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Jakob Praher <jp...@yahoo.de>.
Am Don, 2003-04-24 um 07.59 schrieb Peter Donald:
>
> > What would be great is if it would be possible that you are able to
> > deploy your units not only in the root ( like the war model - yes I am
> > talking about DUs right now ) but along the sitemap tree, so that you
> > can isolate the other application from updates in one subsitemap and so
> > on.
>
> agreed. I think for at least the near future this will be a cocoon-specific
> need that we facilitate but I believe that hierarchial components partitions
> (which is what each sitemap is essentially) will form an integral part of
> Avalon. However we are way of implementing that in a clean way atm.
>
> > > * FOPUnit is a LU
> > > * FOPUnit ConfigurationA is a DU that contains/links the FOPUnit LU and
> > > depends upon FOPSerializer ConfigurationA
> > > * FOPUnit ConfigurationB is a DU that contains/links the FOPUnit LU and
> > > depends upon FOPSerializer ConfigurationB
> > > * FOPUnit ConfigurationC is a DU that contains/links the FOPUnit LU and
> > > depends upon FOPSerializer ConfigurationC
> >
> > perhaps you can give me some more hints about that?
> I am not sure what you want. Explain what you find unclear.
>
What do you see is the Configuration of a LU?
-> I would think that a ceratin amount of configuraiton (for isntance
default values, ... ) could be counted as LU also?
So do you think that DUs shouldn't contain code (or at least contain
glue code?)
How would this be packaged in practice?
LU would be a jar files with a manifest that contains:
-> version
-> compatibilty information (in the simple case of the
major.minor.micro the compaitibilty can be derived from the version )
DU would be a wrapper package (like the .war or [wsb]ar files), that
contains:
-> embedded LUs (you call it contains)
(these are packaged within the DU, is it exportable then?)
-> linked LUs
-> depency information (something like the plugin mechanism)
So what I would like to have is a sort of design document, that stays in
avalon-wiki, where we keep track the discussion. We can have differnent
versions, but we should somehow document the effort. And I hope to play
with some code really soon ;-)
What about the loading mechanics?
Would you design/architect it in the spirit of classloaders, like I
could imagine:
interface LibraryUnit {
Version getVersion( );
Class loadClass( String ) throws ...;
/* ...
}
interface DeployableUnit {
Version getVersion( );
/* should there exist a fine grained class level
import method like laodClass or only component/service
level lookups ? */
Class loadService( String role ) throws ... ;
Dependencies getDependencies( );
/* this might not be that important */
LibraryUnit[] getContainedLibs( );
LibraryUnit[] getReferencedLibs( );
LibraryUnit[] getLibraryUnits( );
}
because of the fact that the LoadableUnit and the DeployableUnit are to
distinct entities, I think we should not root them in one Unit entity -
does not make sense or?
But we need an interface to the resources (classes, ... ). Here the
question of how a resource gets loaded into the container is important:
Only DeployableUnits will be *deployed* (hence their name - or?)
[LUs will be loaded by the means of DUs - or am I misinterpreting
something ?]
How does the container manage updates?
-> new requests for a component get the new interface, whereas old ones
reference the old objects
-> unit unloading would be interesting too (like in oberon), perhaps we
should keep a reference whenever a component is requested, so that we
can tell when an old version of a unit is not needed anymore ( I know
class unloading in java is a kind of black magic, since it is totally vm
dependent, but I think it could be interesting to at least be able to
unload a unit, that is not needed anymore ... )
class UnitLoader {
/* ... */
}
interface UnitLifecycle {
void deployed( ... );
void updated( ... ) ;
void undeployed( ... );
}
It is very important look at the client side too:
What the container/its client want is a way to access these resources
Say Client C wants a reference to Service MyService:
MyService s = container.lookup( MyService.ROLE );
the container in turn will look through the registered/available DUs,
and checks whether someone exports this component.
<myview>
Deployment of Units is more or less a user triggered action, like moving
the mouse or pressing the keyboard, since the sysamdin or deployer, at
any given time, choses to update or replace a deployed unit.
So dealing with deployment actions should be modelled best with events
like in the gui world.
</myview>
So when MyService is updated, or replaced by some better unit, the next
request for MyService.ROLE gets the new MyService:
D:
MyService service = container.lookup( MyService.ROLE );
Granted, if you use delegating dynamic proxies, you exchange the service
for all users, but that's probably too slow on a fine grained scale -
what's your opinion on that? (Micro Kernel design ... )
Of course ther is much more to say on this topic. I would really like to
get a written spec out of these discussions someday ;-).
> > do you mean merlin - isn't maven the automated project management and
> > build tool based on jelly?
>
> I mean maven. Maven is being rebuilt around an avalon + aspect based container
> that essentially turns maven into a generic plugin based Avalon platform with
> a request based architecture.
Sounds very interesing. I haven't looked at the sources for some months
(lack of time) now.
> It is sorta ironic that the most advanced and
> active Avalon container is not built by Avalon peeps.
>
But on the other hand shows that Avalon is used and extended by various
Apache (and of course non Apache) projects, I think thats quite good, as
long as the changes get merged into Avalon (if they are worth it) [ or
else we have too much friction in the container landscape ]
-- Jakob
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 24 Apr 2003 03:38, Jakob Praher wrote:
> > * FOPSerializer is a LU
> > * FOPSerializer ConfigurationA is a DU that contains/links the
> > FOPSerializer LU
> > * FOPSerializer ConfigurationB is a DU that contains/links the
> > FOPSerializer LU
> > * FOPSerializer ConfigurationC is a DU that contains/links the
> > FOPSerializer LU
>
> From a containers perspective this is right, and I think too that the
> cocoon proposal mixes concerns in the respect that not every block is a
> deployable unit ( as you call it ).
yep.
> What would be great is if it would be possible that you are able to
> deploy your units not only in the root ( like the war model - yes I am
> talking about DUs right now ) but along the sitemap tree, so that you
> can isolate the other application from updates in one subsitemap and so
> on.
agreed. I think for at least the near future this will be a cocoon-specific
need that we facilitate but I believe that hierarchial components partitions
(which is what each sitemap is essentially) will form an integral part of
Avalon. However we are way of implementing that in a clean way atm.
> > * FOPUnit is a LU
> > * FOPUnit ConfigurationA is a DU that contains/links the FOPUnit LU and
> > depends upon FOPSerializer ConfigurationA
> > * FOPUnit ConfigurationB is a DU that contains/links the FOPUnit LU and
> > depends upon FOPSerializer ConfigurationB
> > * FOPUnit ConfigurationC is a DU that contains/links the FOPUnit LU and
> > depends upon FOPSerializer ConfigurationC
>
> perhaps you can give me some more hints about that?
I am not sure what you want. Explain what you find unclear.
> do you mean merlin - isn't maven the automated project management and
> build tool based on jelly?
I mean maven. Maven is being rebuilt around an avalon + aspect based container
that essentially turns maven into a generic plugin based Avalon platform with
a request based architecture. It is sorta ironic that the most advanced and
active Avalon container is not built by Avalon peeps.
--
Cheers,
Peter Donald
"All my life I wanted to be someone; I guess I should have been more
specific."
-- Jane Wagner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Jakob Praher <jp...@yahoo.de>.
Am Mit, 2003-04-23 um 00.35 schrieb Peter Donald:
> On Mon, 21 Apr 2003 22:39, Leo Sutic wrote:
> > > From: Peter Donald [mailto:peter@realityforge.org]
> > >
> > > The problem with the Cocoon proposal was that it mixed concepts
> > > of Deployable Units (think .war files), Library Units (think
> > > .jar files) and template/profiles.
> >
Ok I think so too.
> 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 data
>
Some weeks ago I tryied to work out cocoon block support, and am very
glad that the avalon spends some cylces on this topic - I think the
whole dynamic, hot deployable containers are a very intersting topic.
> DUs can depend upon other DUs
> DUs can contain LUs
> LUs can depend upon other LUs
>
> * FOPSerializer is a LU
> * FOPSerializer ConfigurationA is a DU that contains/links the FOPSerializer
> LU
> * FOPSerializer ConfigurationB is a DU that contains/links the FOPSerializer
> LU
> * FOPSerializer ConfigurationC is a DU that contains/links the FOPSerializer
> LU
>
>>From a containers perspective this is right, and I think too that the
cocoon proposal mixes concerns in the respect that not every block is a
deployable unit ( as you call it ).
<sidenote>
But cocoons way of opertion is strongly tide to the sitemap construct.
For instance what I have found interesting is a kind of hierachical
deployment along the sitemap structures, so for instance, it is, thanks
to the good design of the sitemap, possible to mount subsitemaps, which
in my view are a kind of reuse/app boundaries right now.
What would be great is if it would be possible that you are able to
deploy your units not only in the root ( like the war model - yes I am
talking about DUs right now ) but along the sitemap tree, so that you
can isolate the other application from updates in one subsitemap and so
on.
</sidenote>
But I think we should go into the discussion very empirically:
- What is the problem with cocoon and ecm right now, that makes
deployment of blocks not feasible? [ and please note: I am not talking
about what could be possible, but what is done right now .. ]
-> the configuration of the ecm hapens in one .xconf file
-> this .xconf file is loaded at startup
-> changing the .xconf requires a restart ?! ( is this true in every
respect )
What are the requirements: (I talk in next terms (bundles))
* detect bundles and mount or set them up ( like the webapp context
things )
* detect changes (removal, .. ) of bundles and act correnspondingly
* ...
Perhaps the equinox project (at eclipse) is some reference we should
keep warm ( they are trying to get hot deploying plugins for eclipse,
but not until the end of summer )
- We should use whatever avalon container that is right now the best
suitable for getting our hands dirty ( I have merlin very much on top of
my list of things I would to get to know more ) and experiment wiht it
(merlin?!)
> * FOPUnit is a LU
> * FOPUnit ConfigurationA is a DU that contains/links the FOPUnit LU and
> depends upon FOPSerializer ConfigurationA
> * FOPUnit ConfigurationB is a DU that contains/links the FOPUnit LU and
> depends upon FOPSerializer ConfigurationB
> * FOPUnit ConfigurationC is a DU that contains/links the FOPUnit LU and
> depends upon FOPSerializer ConfigurationC
perhaps you can give me some more hints about that?
> Anyways FWIW people may want to watch maven evolve as it has many of the same
> issues and is not as hampered by backwards compatability as some other
> containers. So if someone were to go go help the maven team develope their
> plugin layer and then backport the ideas then that would be great ;)
<naive-mode>
do you mean merlin - isn't maven the automated project management and
build tool based on jelly?
</naive-mode>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Leo Simons <le...@apache.org>.
Okay, I need some more concrete stuff to keep track of what we're
talking about.
Attached zip is the result of stripping one of my container ideas down a
little and renaming thigns to talk about "bundle" (ie the DU). No notion
of LU neccessary in the basic kernel. No idea if it works. Note the huge
similarity to phoenix with s/Application/Bundle/. Also note I decided to
allow for active Bundles. Don't trip over the interceptor or classworld
stuff; it's nonvital to these talks and I think I may have messed up the
use of xinvoke.
still thinking...
cheers,
- Leo
Re: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 24 Apr 2003 00:17, Berin Loritsch wrote:
> 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.
thats fine. But in some cases you want to define prfiles/templates/instance
defs and store them in LUs. Then when the container to use these
profiles/templates/instances to autocreate a configured instance of the LU
that is ready for deployment.
People have asked for this to be implemented in phoenix before and I believe
Merlin may implement it but the problem is basically finding a way to enable
this but not create a mountain of complexity.
> To keep things clear, let's call DUs bundles and LUs jars. That way
> I think I can keep it clear.
okies.
> 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.
This is just a resource access concern. Imagine the DemoApp had a descriptor
like
<resources version="1.0" cascades="GUIApp">
<!-- declare some resource types -->
<type shortname="image" uri="..."/>
<!-- declare some instances of above resource types -->
<image key="okButton" resource="/images/okButton.png"/>
</resources>
And then the descriptor for GUIApp was something like
<resources version="1.0">
<!-- declare some resource types -->
<type shortname="image" uri="..."/>
<type shortname="string" uri="..."/>
<!-- declare some instances of above resource types -->
<image key="okButton" resource="/images/okButton.png"/>
<image key="cancelButton" resource="/images/cancelButton.png"/>
<string key="okMsg" resource="/resources/GUIApp"/>
<string key="cancelMsg" resource="/resources/GUIApp"/>
</resources>
So let us assume you want okButton image from within context of "DemoApp". You
ask for the resource with key name "okButton" of type "<insert uri here>".
This would search in DemoApp and find that resource and return the DemoApp
specific resource. However if you would search for cancelButton image then it
would go back to GUIApp bundle to grab it.
For more control over the order that searches are performed in then you need
allow "import" directives in "<resources>" sections.
Of course if the resources need to be grouped and cascaded/imported as a group
(say for themes) then you introduce a whole other layer of complexity.
> > 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.
I used to think it was the only way to be given that data-driven formats are
way more extensible, maintainable etc. But I can see a lot of advantages of
having at least hooks into format to make it somewhat active and
self-controlling. Though implementing this is a PITA.
> The active portion should
> be in the API to access the contents of those DUs.
Again - I think resources access is a completely different concern.
--
Cheers,
Peter Donald
*--------------------------------------------*
| "You can't fight in here! This is the war |
| room!" -Dr. Strangelove |
*--------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
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
>>>data
>>>
>>>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
>>one.
>
>
> 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
resources.
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.
Ok.
> 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
Re: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
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
> > data
> >
> > 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.
> In essence, I want to use resources defined in another LU for in this
> one.
Are you sure you do not want resources defined in another DU used byt this DU?
> > 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.
> > 3. classloader isolation of impls but sharing of instances. The traversal
> > of the classloader lattice is very very tricky.
>
> Perhaps we can have a solution that does not isolate the classloaders
> for bundles? Or perhaps we can extract the resources into a temprory
> directory and return resources from that?
This does not make sense in the context of DU vs LU.
> Right. Those concerns belong in an extension to the basic bundle API,
> but my basic thought is that for a GUIApp environment, there would be
> only one DU that identifies what the bundles would be (i.e. finding the
> correct "theme" bundle). All other DUs/LUs exist to add functionality
> to the core system.
Does not compute. DUs can depend on other DUs and LUs can depend on other LUs.
The dependency can be typed (ie LU can depend on "abstract type" of LU). This
is already done and a standard exists for dependencies between LUs (ie
Optional Package Spec).
What you want is two things. A standard for DUs and a standard for resource
access. I am working on resource access in that toolkit I have already
mentioned and given links to concepts.
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.
> > (2) is something I have implemented in Phoenix before but never actually
> > committed because of the instability it would bring (requires many more
> > unit tests than is currently in place). It is a bit of work but not that
> > hard. See archives for discussion about it.
>
> Is it something that can be developed and released independently of
> Phoenix? I.e. in Sandbox?
AutoAssembly? Yes it could but it relies on CK which was moved from sandbox
into Phoenix. In a few months I plan to start extracting that to be reusable
in other contexts but I will probably migrate it out to Spice.
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
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 data
>
> 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.
In essence, I want to use resources defined in another LU for in this
one.
I have not created a new LU, just used an existing resource.
> 2. autoassembly (in combination with above)
In combination with DUs or LUs?
> 3. classloader isolation of impls but sharing of instances. The traversal of
> the classloader lattice is very very tricky.
Perhaps we can have a solution that does not isolate the classloaders
for bundles? Or perhaps we can extract the resources into a temprory
directory and return resources from that?
> 4. instance based resources access. (ie DUs that contains skins or other
> resources that can cascade/inherit etc).
>
> (1) sounds easy but it actually can become hell for the user unless there is
> some very clear directives that can be used to select the correct
> profile/template.
Right. Those concerns belong in an extension to the basic bundle API,
but my basic thought is that for a GUIApp environment, there would be
only one DU that identifies what the bundles would be (i.e. finding the
correct "theme" bundle). All other DUs/LUs exist to add functionality
to the core system.
> (2) is something I have implemented in Phoenix before but never actually
> committed because of the instability it would bring (requires many more unit
> tests than is currently in place). It is a bit of work but not that hard. See
> archives for discussion about it.
Is it something that can be developed and released independently of
Phoenix? I.e. in Sandbox?
> (3) is possible but requires a ****lot**** of work.
But the payoff would be tremendous.
--
"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: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Mon, 21 Apr 2003 22:39, Leo Sutic wrote:
> > From: Peter Donald [mailto:peter@realityforge.org]
> >
> > The problem with the Cocoon proposal was that it mixed concepts
> > of Deployable Units (think .war files), Library Units (think
> > .jar files) and template/profiles.
>
> Hm.
>
> That does seem to be a major problem. I kept coming back to something
> like that when I spewed out my reply to Berin - how do you handle
> the case where one unit requires another? Do you deploy them
> side-by-side
> or do you wrap one in the other?
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 data
DUs can depend upon other DUs
DUs can contain LUs
LUs can depend upon other LUs
* FOPSerializer is a LU
* FOPSerializer ConfigurationA is a DU that contains/links the FOPSerializer
LU
* FOPSerializer ConfigurationB is a DU that contains/links the FOPSerializer
LU
* FOPSerializer ConfigurationC is a DU that contains/links the FOPSerializer
LU
* FOPUnit is a LU
* FOPUnit ConfigurationA is a DU that contains/links the FOPUnit LU and
depends upon FOPSerializer ConfigurationA
* FOPUnit ConfigurationB is a DU that contains/links the FOPUnit LU and
depends upon FOPSerializer ConfigurationB
* FOPUnit ConfigurationC is a DU that contains/links the FOPUnit LU and
depends upon FOPSerializer ConfigurationC
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)
2. autoassembly (in combination with above)
3. classloader isolation of impls but sharing of instances. The traversal of
the classloader lattice is very very tricky.
4. instance based resources access. (ie DUs that contains skins or other
resources that can cascade/inherit etc).
(1) sounds easy but it actually can become hell for the user unless there is
some very clear directives that can be used to select the correct
profile/template.
(2) is something I have implemented in Phoenix before but never actually
committed because of the instability it would bring (requires many more unit
tests than is currently in place). It is a bit of work but not that hard. See
archives for discussion about it.
(3) is possible but requires a ****lot**** of work.
(4) is being developed (see the link I sent the otherday).
Anyways FWIW people may want to watch maven evolve as it has many of the same
issues and is not as hampered by backwards compatability as some other
containers. So if someone were to go go help the maven team develope their
plugin layer and then backport the ideas then that would be great ;)
--
Cheers,
Peter Donald
*------------------------------------------------*
| Those who know how to think need no teachers. |
| - Gandhi |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[RT] Bundles (was Re: [RT] Distilling the requirements for Block
Support)
Posted by Berin Loritsch <bl...@apache.org>.
Leo Sutic wrote:
>>From: Peter Donald [mailto:peter@realityforge.org]
>>
>>The problem with the Cocoon proposal was that it mixed concepts
>>of Deployable Units (think .war files), Library Units (think
>>.jar files) and template/profiles.
>
>
> Hm.
>
> That does seem to be a major problem. I kept coming back to something
> like that when I spewed out my reply to Berin - how do you handle
> the case where one unit requires another? Do you deploy them
> side-by-side
> or do you wrap one in the other?
>
> Unit FOPSerializer requires FOP (using Avalon Archives, .aar):
>
> Side by side:
>
> fopserializer.aar fop.aar
> +--------------------+ +----------+
> | FOPSerializer Unit | | FOP Unit |
> +--------------------+ +----------+
> | ^
> +--------------------+
> Tied together via
> container magic.
I prefer side by side--although the FOP jars itself should be simply
specified. I also think that the FOPSerializer Bundle above should
have the ability to provide the version information for FOP if FOP
does not provide it for their JAR file.
Also the Bundle API should be able to detect version incompatibilities,
as much as possible. That way the user/developer will know if their
application is required to have conflicting JARs in the classpath.
If the class paths could be made separate (with classloader magic),
then the affects of the mismatch would be minimized, but FOP and
Batik (a pair at this point) are hefty JARs, not something you really
want multiple versions of if you can help it.
> Wrapped:
>
> fopserializer.aar
> +--------------------+
> | FOPSerializer Unit |
> | |
> | libs/fop.aar |
> +--------------------+
>
> Both have problems regarding pluggability. For the side-by-side version,
> you can easily swap the fop.aar in and out. With the wrapped version it
> is more difficult.
It is more difficult, yes. Essentially the container/bundle manager
would have to choose one of those FOP JARs to use.
--
"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: [RT] Distilling the requirements for Block Support
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> The problem with the Cocoon proposal was that it mixed concepts
> of Deployable Units (think .war files), Library Units (think
> .jar files) and template/profiles.
Hm.
That does seem to be a major problem. I kept coming back to something
like that when I spewed out my reply to Berin - how do you handle
the case where one unit requires another? Do you deploy them
side-by-side
or do you wrap one in the other?
Unit FOPSerializer requires FOP (using Avalon Archives, .aar):
Side by side:
fopserializer.aar fop.aar
+--------------------+ +----------+
| FOPSerializer Unit | | FOP Unit |
+--------------------+ +----------+
| ^
+--------------------+
Tied together via
container magic.
Wrapped:
fopserializer.aar
+--------------------+
| FOPSerializer Unit |
| |
| libs/fop.aar |
+--------------------+
Both have problems regarding pluggability. For the side-by-side version,
you can easily swap the fop.aar in and out. With the wrapped version it
is more difficult.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 19 Apr 2003 01:42, Berin Loritsch wrote:
> So is there anything in the concepts that I shared that you have a
> problem with? Does it seem like a bunch of nothing? If so, I can
> drop Avalon out of the discussions, and work with Cocoon on a D-Haven
> block/component/plugin that will work with both Cocoon and GUIApp's
> needs and Avalon will have to live without.
I have talked about this extensively in the past and detailed very exacting
requirements. The problem with the Cocoon proposal was that it mixed concepts
of Deployable Units (think .war files), Library Units (think .jar files) and
template/profiles. All of the discussion is of course in the archives.
The toolkit that supports these notions has been written and rewritten a
couple of times by me. You can see part of the initial idea for the initial
version at
http://jira.codehaus.org/secure/ViewIssue.jspa?key=SPSITE-8
Not representative of what it does now but you get the idea. This definition
of course just defines the resources that a LibraryUnit exports. To set up
relationships between librarys there was discussion along the lines of
http://jira.codehaus.org/secure/ViewIssue.jspa?key=PNIX-28
But most of the meat is in the archives.
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Distilling the requirements for Block Support
Posted by Daniel Krieg <dk...@kc.rr.com>.
Not familiar with OSX -- "Bundle" not confused with "ResourceBundle" ??
On Fri, 2003-04-18 at 11:35, 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?
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
Daniel Krieg <dk...@kc.rr.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 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
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
Avalon Bundles (was Re: [RT] Distilling the requirements for Block
Support)
Posted by Berin Loritsch <bl...@apache.org>.
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: [RT] Distilling the requirements for Block Support
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> 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?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
Out of all of them, I like Bundle the best.
Daniel Krieg wrote:
> Perhaps "Module" -- used in NetBeans to describe a plugin that could
> consist of multiple services/components.
>
> On Fri, 2003-04-18 at 11:05, Leo Sutic wrote:
>
>>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>
>>>Now, you objected to the term Block for what I was proposing.
>>
>>I'd like to suggest the term "Assembly". It is what is used in
>>.Net, and, I understand it to have a similar meaning.
>>
>>Another term, taken from Mac OSX is "Bundle".
>>http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bun
>>dles/index.html
>>
>>This would eliminate any confusion for Phoenix users.
>>
>>/LS
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
>>For additional commands, e-mail: dev-help@avalon.apache.org
--
"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: [RT] Distilling the requirements for Block Support
Posted by Daniel Krieg <dk...@kc.rr.com>.
Perhaps "Module" -- used in NetBeans to describe a plugin that could
consist of multiple services/components.
On Fri, 2003-04-18 at 11:05, Leo Sutic wrote:
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> >
> > Now, you objected to the term Block for what I was proposing.
>
> I'd like to suggest the term "Assembly". It is what is used in
> .Net, and, I understand it to have a similar meaning.
>
> Another term, taken from Mac OSX is "Bundle".
> http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bun
> dles/index.html
>
> This would eliminate any confusion for Phoenix users.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
--
Daniel Krieg <dk...@kc.rr.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Distilling the requirements for Block Support
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> Now, you objected to the term Block for what I was proposing.
I'd like to suggest the term "Assembly". It is what is used in
.Net, and, I understand it to have a similar meaning.
Another term, taken from Mac OSX is "Bundle".
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bun
dles/index.html
This would eliminate any confusion for Phoenix users.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Ulrich Mayring <ul...@denic.de>.
Berin Loritsch wrote:
>
> Now, you objected to the term Block for what I was proposing. Fine.
> However, Cocoon and GUIApp have similar needs, as I am sure many
> other applications will. If we don't call it a Block we can call it
> a Plugin, or some other name--I don't care what its called. I just
> care that we have something that works.
A German saying goes: Names are just sound and smoke. Umberto Eco sees
it differently. Take your pick :)
Personally, I think the term "block" should be avoided like all terms,
which refer to something that actually exists and is used. Otherwise
we'll later talk about "Avalon blocks" vs. "Phoenix blocks" vs. "Cocoon
blocks" and things become fuzzy.
Ulrich
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Sat, 19 Apr 2003 01:31, Berin Loritsch wrote:
>
>>Peter Donald wrote:
>>
>>>org.apache.avalon.phoenix.Block
>>
>>I'm still not getting any details, so I am assuming that Block as
>>defined there will be adjusted to fit all our needs?
>>
>>Seriously, a little dialog will help. A deprecated interface name
>>doesn't help me. Assume I think Phoenix is Mozilla's browser. What
>>correlations of the Phoenix Block are there with what I proposed,
>>what were the lessons learned, what can we leverage, etc.
>
> Seriously I think you are being a PITA. Block is a term that has existed for a
> long time in Avalon (way before you were apart of Avalon). It has essentially
> meant a "large" component with no other meaning and there is a lot of
> documentation and code to that effect. You want to invent a new meaning for
> the term and change waht a lot of existing users and developers mean by the
> term Block then you are going to hurt Avalon.
Ok, maybe I am being a PITA. I will calm down, and maybe we can get
somewhere. But please understand that one line answers without
addressing anything I talked about then I have to dig a little deeper
to find out what is the problem.
Now, you objected to the term Block for what I was proposing. Fine.
However, Cocoon and GUIApp have similar needs, as I am sure many
other applications will. If we don't call it a Block we can call it
a Plugin, or some other name--I don't care what its called. I just
care that we have something that works.
So is there anything in the concepts that I shared that you have a
problem with? Does it seem like a bunch of nothing? If so, I can
drop Avalon out of the discussions, and work with Cocoon on a D-Haven
block/component/plugin that will work with both Cocoon and GUIApp's
needs and Avalon will have to live without.
--
"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: [RT] Distilling the requirements for Block Support
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> Seriously I think you are being a PITA.
Seriously I think you're not being constructive, nor polite here.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 19 Apr 2003 01:31, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Sat, 19 Apr 2003 01:22, Berin Loritsch wrote:
> >>Seriously, if what I defined as a "Block" is not what everyone is
> >>concidering a block,
> >
> > org.apache.avalon.phoenix.Block
>
> I'm still not getting any details, so I am assuming that Block as
> defined there will be adjusted to fit all our needs?
>
> Seriously, a little dialog will help. A deprecated interface name
> doesn't help me. Assume I think Phoenix is Mozilla's browser. What
> correlations of the Phoenix Block are there with what I proposed,
> what were the lessons learned, what can we leverage, etc.
Seriously I think you are being a PITA. Block is a term that has existed for a
long time in Avalon (way before you were apart of Avalon). It has essentially
meant a "large" component with no other meaning and there is a lot of
documentation and code to that effect. You want to invent a new meaning for
the term and change waht a lot of existing users and developers mean by the
term Block then you are going to hurt Avalon.
--
Cheers,
Peter Donald
*------------------------------------------------*
| Trying is the first step to failure. |
| So never try, Lisa - Homer Jay Simpson |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Sat, 19 Apr 2003 01:22, Berin Loritsch wrote:
>
>>Seriously, if what I defined as a "Block" is not what everyone is
>>concidering a block,
>
>
> org.apache.avalon.phoenix.Block
I'm still not getting any details, so I am assuming that Block as
defined there will be adjusted to fit all our needs?
Seriously, a little dialog will help. A deprecated interface name
doesn't help me. Assume I think Phoenix is Mozilla's browser. What
correlations of the Phoenix Block are there with what I proposed,
what were the lessons learned, what can we leverage, etc.
--
"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: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 19 Apr 2003 01:22, Berin Loritsch wrote:
> Seriously, if what I defined as a "Block" is not what everyone is
> concidering a block,
org.apache.avalon.phoenix.Block
--
Cheers,
Peter Donald
*-----------------------------------------------------------*
"I like nonsense, it wakes up the brain cells. Fantasy is a
necessary ingredient in living, it's a way of looking at life
through the wrong end of a telescope and that enables you to
laugh at life's realities." -Dr. Seuss
*-----------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Fri, 18 Apr 2003 23:48, Berin Loritsch wrote:
>
>>What are your thoughts?
>
>
> That Block is already a term that has long been used to refer to something
> else.
I'm not hearing any details, so I guess you thought everything was
brilliant and will have it completed by tomorrow, right? :P
Seriously, if what I defined as a "Block" is not what everyone is
concidering a block, exactly WHAT are the differences, and how
should we move forward?
--
"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: [RT] Distilling the requirements for Block Support
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 18 Apr 2003 23:48, Berin Loritsch wrote:
> What are your thoughts?
That Block is already a term that has long been used to refer to something
else.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
Vincent tencé wrote:
> There seem to be interest in the block concept at avalon-dev as well, which
> is rather good news. But where do we go from there? What actions should we
> take to bring it one step further? Unless it's already been thought/written
> by some Peter out there ;-)
I think everyone at Avalon agrees that there is a need, but the name
should be changed to "Bundle" or "Assembly" or something like that.
I personally prefer Bundle.
> Serioulsy, I'd like to make that a reality because I think it's vital to
> GuiApp. I don't think it can wait too long either. Maybe it's something we
> should experiment on our own and then adapt to Avalon specs when they come
> out. Stefano seems to have great interest in this as well for Cocoon. Maybe
> he already has something working?
:) Well we could do that. Stefano has a general concept, but I am not
sure they have it working fully, yet.
> Do you have any action plan? Anyway I need to think about this myself and
> see what would be my requirements.
One resource that would be good to look at is here:
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bundles/index.html
or in PDF form here:
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/SystemOverview.pdf
I would like to extract what makes sense and ignore what doesn't.
I like the simplicity of how Bundles are supposed to work. Apple
provides an API to access the bits in the bundle, which would be
a good thing. That way as the contents/layout of bundles change,
we can still get at them.
Also we need to look at things like Eclipse plugins or IDEA plugins
for integrating UI elements together as one cohesive whole--without
requiring the plugin writer to have a bunch of management code. I.e.
as declarative as possible.
--
"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
Re: [RT] Distilling the requirements for Block Support
Posted by Berin Loritsch <bl...@apache.org>.
Vincent tencé wrote:
> There seem to be interest in the block concept at avalon-dev as well, which
> is rather good news. But where do we go from there? What actions should we
> take to bring it one step further? Unless it's already been thought/written
> by some Peter out there ;-)
I think everyone at Avalon agrees that there is a need, but the name
should be changed to "Bundle" or "Assembly" or something like that.
I personally prefer Bundle.
> Serioulsy, I'd like to make that a reality because I think it's vital to
> GuiApp. I don't think it can wait too long either. Maybe it's something we
> should experiment on our own and then adapt to Avalon specs when they come
> out. Stefano seems to have great interest in this as well for Cocoon. Maybe
> he already has something working?
:) Well we could do that. Stefano has a general concept, but I am not
sure they have it working fully, yet.
> Do you have any action plan? Anyway I need to think about this myself and
> see what would be my requirements.
One resource that would be good to look at is here:
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Bundles/index.html
or in PDF form here:
http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/SystemOverview.pdf
I would like to extract what makes sense and ignore what doesn't.
I like the simplicity of how Bundles are supposed to work. Apple
provides an API to access the bits in the bundle, which would be
a good thing. That way as the contents/layout of bundles change,
we can still get at them.
Also we need to look at things like Eclipse plugins or IDEA plugins
for integrating UI elements together as one cohesive whole--without
requiring the plugin writer to have a bunch of management code. I.e.
as declarative as possible.
--
"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