avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Praher <jpra...@yahoo.de>
Subject Re: [RT] Distilling the requirements for Block Support
Date Wed, 23 Apr 2003 17:38:34 GMT
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 ).

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

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

> * 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 ;)

do you mean merlin - isn't maven the automated project management and
build tool based on jelly?

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

View raw message