Ryan wrote:
> Very cool! Thanks for the detailed instructions. I'm amazed
> it is as easy as that...are you sure this is an Open Source
> project? You're supposed to just say, "Read the source!" :^)
I'm v/interested to know if everything goes as easily
as documented. It should do. The primary goal was to deliver
drop-dead-simple component/service management.
Cheers, Steve.
> Ryan
>
> Stephen wrote:
>
> |||
> ||| Yep, it's totally feasible all you need is a little magic
> ||| from Merlin :-)
> |||
> ||| 1. Checkout org.apache.avalon-apps/enterprise/tools
> ||| 2. $ cd <your-directory>/enterprise/tools
> ||| 2. $ ant dist
> ||| 3. $ ant export
> ||| 4. and the following to your project's build file
> |||
> ||| <target name="demo">
> ||| <taskdef resource="merlin.properties"/>
> ||| <load target="com.whatever.YourBlock"
> ||| priority="DEBUG" disposal="TRUE" verbose="TRUE">
> ||| <fileset dir="${dist}">
> ||| <include name="*.jar"/>
> ||| </fileset>
> ||| </load>
> ||| </target>
> |||
> ||| - target is any class that has a corresponding .xinfo file.
> ||| - priority value is either INFO, ERROR, WARNING, DEBUG ... i.e.
> ||| logging level.
> ||| - disposal id TRUE simply terminates the run, or FALSE lets it
> ||| live on as a server
> ||| - verbose if TRUE provides debug level info about what the container
> ||| is doing with your components
> ||| - configuration is an optional attribute you can provide that
> references
> ||| a configuration file or you can include a default <configuration/>
> ||| statement in your .xinfo file (see package demo for example)
> ||| - you can have multiple fileset declarations - this basically
> ||| populates the classloader and sets up a registry of available
> ||| services if the target component needs them based on supplied
> ||| jar files containing block manifest entries
> ||| - check package documentation for lots of additional details
> |||
> ||| Note - the "$ ant export" statement above will put a copy of
> ||| avalon-frameork.jar, logkit.jar and merlin.jar into your Ant lib
> ||| directory. After that your ready to roll.
> |||
> ||| Cheers, Steve.
> |||
> |||
> ||| > -----Original Message-----
> ||| > From: Paul Hammant [mailto:[EMAIL PROTECTED]]
> ||| > Sent: Wednesday, 13 March, 2002 08:35
> ||| > To: Avalon Developers List
> ||| > Subject: Re: Using cornerstone blocks without phoenix?
> ||| >
> ||| >
> ||| > Ryan,
> ||| >
> ||| > >How feasible is it to use cornerstone services/blocks
> without phoenix?
> ||| > >
> ||| > Blocks? Yes it shold be doable. All you have to do is
> instantiate a
> ||| > block and decorate it with it's IoC requirements in the
> same way that
> ||| > Phoenix does. What you might end up with would be a
> microPhoenix. Hmm
> ||| > that rings a bell.
> ||| >
> ||| > - Paul
> ||| >
> ||| >
> ||| > --
> ||| > To unsubscribe, e-mail:
> ||| > <mailto:[EMAIL PROTECTED]>
> ||| > For additional commands, e-mail:
> ||| > <mailto:[EMAIL PROTECTED]>
> ||| >
> |||
> ||| --
> ||| To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
||| For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
|||
|||
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
