avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [RT] Converging our Concerns
Date Sun, 10 Aug 2003 13:05:59 GMT

Niclas Hedhman wrote:

><quote who="Stephen McConnell">
>>Niclas Hedhman wrote:
>>>Now, since I haven't 100% committed my products to Phoenix yet, should
>>>I reconsider at this point?
>>>I guess I have to dive into Merlin now...
>>Keep in mind that I've real busy getting 3.0 into shape.  The 3.0
>>content is basically all Leo's fault - refactioring of thingas to make
>>things cleaner and simpler.  I'm maybe 2 days away from finalizing that.
>> Impact on you should be nothing more than making things easier to work
>Well, I guess I asked the question the wrong way.
>I am embedding Phoenix into a complete DevKit for process control
>applications, and I have found that Phoenix is ideal for this world.
>The DevKit has "Create Block Spec", "Create Block Impl" and "Project
>Assembly" completely separated, and in the "Project Assembly" part, the
>DevKit takes all the used Blocks (packaged to my own standard :o(  ), with
>the UI part (Cocoon based) of each Block Impl (which may be inherited from
>the Block Spec) and creates either a CD for installation on the target
>system. That CD has an installation procedure to either;
>1. Install Project + Jetty/Cocoon in the same Phoenix container.
>2. Install the Project in Phoenix and run Jetty/Cocoon in separate JVM
>3. Install only Project in Phoenix.
>4. Install only Jetty/Cocoon.
>5. Install the JVM for the above.
>As you may understand, I am focusing on bring the "Best of Apache" into a
>single tool to increase efficiency and targetting an audience that is not
>inclined to "low-level Java hacking". Instead, I am trying to provide as
>many patterns and templates as possible, and basically documentation of
>steps to go through for each rather simple task. Later I was thinking to
>make those steps as a Wizard in Eclipse or Netbeans.
>NOW, (long explaination for a short question) as you can see, I can
>proceed with my plans and release all of the above by October or so, BUT
>if the long-term future is Merlin, at some point in the future, I will be
>faced with a migration problem of my customer's customer's systems(!!!).
>OR I can move what I have done so far, and use Merlin straight from the
>start, preventing future headaches.
>So I am not talking so much about Phoenix compatibility in Merlin, but
>shipping Merlin with the product, and has it running in "native mode".
>The only "pure Phoenix" feature that I am using so far, is the
>BlockListener concept.
>My use (not done yet though); A single listener check listens to all
>Blocks, and will transfer which blocks has been register to two particular
>Blocks, one for network connectivity and one for JavaBean Event wiring.
>Not even sure if this is the way I am supposed to do it... and assumes
>that there is some way in Merlin for one Block to find out what other
>blocks are installed.

There will be support for extensions that are provided with the full 
deployment model (based on the extension updates from Aaron). In the 
case your describing it would be possible to approximate a block 
listener by providing all of the components declare that they require 
the stage handled by the extension.  What would be even better is to 
simply add a listener to the container and act on deployment events 
(i.e. a container listener) - but that's something for post release 

>Should I go Merlin?

It's your call.  I think you will be able to do some really nice things 
in terms of automating the creation of deployment descriptors using the 
compostion API that would result a general platform easy to maintain. In 
other words, if you go with Merlin you will probably have some short 
term pain (a couple of months) followed by a lot more benefit downstream.


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


Stephen J. McConnell

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

View raw message