You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by J Aaron Farr <fa...@apache.org> on 2003/11/05 04:58:59 UTC

Re: Merging plan (was Build process in maven?)


On Tue, 2003-11-04 at 23:02, Stephen McConnell wrote:

> >
> >>Just the sort of thing I should be adding to the JIRA roadmap for Merlin!

Agreed.  I can't wait for JIRA roadmaps for Avalon. :)

> >
> >NEWS FLASH From Colorado Software Summit!  It exists!  Dion Gillard's
> >presentation on Jelly noted to major things:
> >
> >  1) There is an Avalon Service for integrating Jelly
> >     into an Avalon container.
> >
> >  2) Jelly also has support for delegating to BSF.
> >
> >This means that you could pickup the Jelly service for Merlin, and integrate
> >it at a deep level so that we can use it for component testing, using Jelly,
> >BSF supported languages, etc.
> >
> >Right now the Avalon Jelly service is in Jelly's CVS module (Jakarta
> >Commons).  Depending upon what you need to do it to (I haven't looked),
> >perhaps you might want to talk about adopting it officially into the Avalon
> >project.
> >
> >	--- Noel

I thought about doing a generic Jelly service, but it was such a back
burner issue I never had time to do it.  This could be really cool!

Couldn't this be used for some of the scriptable components Leo was
interested in?

-- 
 jaaron  <http://jadetower.org>


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


Re: Merging plan (was Build process in maven?)

Posted by Shash Chatterjee <sh...@badfw.org>.
Minor typo with major impact: I meant BSF not BSH.  Sorry!

Shash Chatterjee wrote:
> If it is useful for anybody, in Keel (http://www.keelframework.org) we 
> have an Avalon script service, with two implementations of the service 
> interface: Jelly and BSH (I have tested JavaScript, NetRexx, and TCL). I 
> have attached the service interface.
> 
> This interface (as I would expect other similar services to do), exposes 
> arbitrary objects to the underlying script engine.  Leo's concern in a 
> separate post about the script causing havoc is very valid, depends on 
> what is exposed!
> 
> On a separate but related topic, we seem to have the same needs and
> also reinventing the wheel, given the number of Jelly service 
> implementations we  have.  This is at least one of the major issues that 
> COP was intended to solve, or so I thought!  We talk about component 
> repositories, but I think something that might help is an Avalon/Apache 
> hosted project of Avalon service interfaces (roles), that could then be 
> augmented with a directory that would point to all the available 
> implementations.  There are a plethora of "lightweight" IOC containers 
> that can manage different components with varied configuration (i.e. 
> instantiate a bean, provide different config to each instance), which 
> Avalon can do as well.  But Avalon containers are among a much smaller 
> set that allow looking up of multiple implementations of the same 
> interface, as well as configuring them differently.  We should take more 
> advantage of that, and avoid 1:1 relationships of 
> interfaces/implementations.
> 
> Shash
> 
> Stephen McConnell wrote:
> 
>>
>>
>> David Worms wrote:
>>
>>> I have an updated version of jelly working inside Merlin. I'll be 
>>> happy to share it. From what I remember, I haven't changed the code, 
>>> just added meta information, separated in to maven project (api/impl) 
>>> and added a simple test to it. 
>>
>>
>>
>>
>> How about we put it in the sandbox?
>> I'd like to take a loook at it.
>>
>> Steve.
>>
> 
> 
> ------------------------------------------------------------------------
> 
> /*
>  * Copyright (c) 2002, The Keel Group, Ltd. All rights reserved.
>  *
>  * This software is made available under the terms of the license found
>  * in the LICENSE file, included with this source code. The license can
>  * also be found at:
>  * http://www.keelframework.net/LICENSE
>  */
> package org.keel.services.script;
> 
> /**
>  * This is the interface for services that are able to execute some form 
>  * of an interpreted scripting language.  Java objects can be passed
>  * to the script from Keel services, and visa-versa.
>  * 
>  * @version	$Revision: 1.2 $	$Date: 2003/07/03 15:49:32 $
>  * @author Shash Chatterjee
>  * Created on Jun 14, 2003
>  */
> public interface Script {
>     
>     /**
>      * The Avalon role name for the Script service
>      */    
>     public static String ROLE = Script.class.getName();
>     
>     /**
>      * Expose a Java object to the script context
>      * @param o The object to expose
>      * @param name The name the object will be referred to by
>      * @throws ScriptException Error when the object cannot be exposed
>      */
>     public void expose(Object o, String name) throws ScriptException;
>     
>     /**
>      * Expose a java object to the script context, with a scoped name
>      * @param o The object to expose
>      * @param name The name the object will be referred to by
>      * @param scope The scope for the name
>      * @throws ScriptException Error when the object cannot be exposed
>      */
>     public void expose(Object o, String name, String scope) throws ScriptException;
>     
>     /**
>      * Get an object from the script context
>      * @param name The name of the object to retrieve
>      * @return The retrieved object
>      * @throws ScriptException Error when the object cannot be retrieved
>      */
>     public Object retrieve(String name) throws ScriptException;
>     
>     /**
>      *  Get an object from the script context, with a scoped name
>      * @param name The name of the object to retrieve
>      * @param scope The scope for the name
>      * @return The retrieved object
>      * @throws ScriptException Error when the object cannot be retrieved
>      */
>     public Object retrieve(String name, String scope) throws ScriptException;
>     
>     /**
>      * Delete an object from the script context
>      * @param name The name of the object to delete
>      * @throws ScriptException Error when the object cannot be deleted
>      */
>     public void remove(String name) throws ScriptException;
>     
>     /**
>      * Delete an object from the script context, with a scoped name 
>      * @param name The name of the object to delete
>      * @param scope The scope for the name
>      * @throws ScriptException Error when the object cannot be deleted
>      */
>     public void remove(String name, String scope) throws ScriptException;
>     
>     /**
>      * Run the script in the named file
>      * @param script The file name of the script
>      * @throws ScriptException Error from the scripting engine
>      */
>     public void execute(String script) throws ScriptException ;
> 
> }
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------------------------
> 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: Merging plan (was Build process in maven?)

Posted by Shash Chatterjee <sh...@badfw.org>.
If it is useful for anybody, in Keel (http://www.keelframework.org) we 
have an Avalon script service, with two implementations of the service 
interface: Jelly and BSH (I have tested JavaScript, NetRexx, and TCL). 
I have attached the service interface.

This interface (as I would expect other similar services to do), exposes 
arbitrary objects to the underlying script engine.  Leo's concern in a 
separate post about the script causing havoc is very valid, depends on 
what is exposed!

On a separate but related topic, we seem to have the same needs and
also reinventing the wheel, given the number of Jelly service 
implementations we  have.  This is at least one of the major issues that 
COP was intended to solve, or so I thought!  We talk about component 
repositories, but I think something that might help is an Avalon/Apache 
hosted project of Avalon service interfaces (roles), that could then be 
augmented with a directory that would point to all the available 
implementations.  There are a plethora of "lightweight" IOC containers 
that can manage different components with varied configuration (i.e. 
instantiate a bean, provide different config to each instance), which 
Avalon can do as well.  But Avalon containers are among a much smaller 
set that allow looking up of multiple implementations of the same 
interface, as well as configuring them differently.  We should take more 
advantage of that, and avoid 1:1 relationships of 
interfaces/implementations.

Shash

Stephen McConnell wrote:

> 
> 
> David Worms wrote:
> 
>> I have an updated version of jelly working inside Merlin. I'll be 
>> happy to share it. From what I remember, I haven't changed the code, 
>> just added meta information, separated in to maven project (api/impl) 
>> and added a simple test to it. 
> 
> 
> 
> How about we put it in the sandbox?
> I'd like to take a loook at it.
> 
> Steve.
> 


Re: Merging plan (was Build process in maven?)

Posted by David Worms <da...@simpledesign.com>.
I just posted the service/implementation of Jelly:

http://www.abile.net/temp/jelly.zip

d.


On Wednesday, November 5, 2003, at 04:36  AM, Stephen McConnell wrote:

>
>
> David Worms wrote:
>
>> I have an updated version of jelly working inside Merlin. I'll be 
>> happy to share it. From what I remember, I haven't changed the code, 
>> just added meta information, separated in to maven project (api/impl) 
>> and added a simple test to it.
>
>
> How about we put it in the sandbox?
> I'd like to take a loook at it.
>
> Steve.
>
> -- 
>
> Stephen J. McConnell
> mailto:mcconnell@apache.org
>
>
>
>
> ---------------------------------------------------------------------
> 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: Merging plan (was Build process in maven?)

Posted by Stephen McConnell <mc...@apache.org>.

David Worms wrote:

> I have an updated version of jelly working inside Merlin. I'll be 
> happy to share it. From what I remember, I haven't changed the code, 
> just added meta information, separated in to maven project (api/impl) 
> and added a simple test to it. 


How about we put it in the sandbox?
I'd like to take a loook at it.

Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




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


Re: Merging plan (was Build process in maven?)

Posted by David Worms <da...@simpledesign.com>.
I have an updated version of jelly working inside Merlin. I'll be happy 
to share it. From what I remember, I haven't changed the code, just 
added meta information, separated in to maven project (api/impl) and 
added a simple test to it.

d.

On Tuesday, November 4, 2003, at 07:58  PM, J Aaron Farr wrote:

>
>
> On Tue, 2003-11-04 at 23:02, Stephen McConnell wrote:
>
>>>
>>>> Just the sort of thing I should be adding to the JIRA roadmap for 
>>>> Merlin!
>
> Agreed.  I can't wait for JIRA roadmaps for Avalon. :)
>
>>>
>>> NEWS FLASH From Colorado Software Summit!  It exists!  Dion Gillard's
>>> presentation on Jelly noted to major things:
>>>
>>>  1) There is an Avalon Service for integrating Jelly
>>>     into an Avalon container.
>>>
>>>  2) Jelly also has support for delegating to BSF.
>>>
>>> This means that you could pickup the Jelly service for Merlin, and 
>>> integrate
>>> it at a deep level so that we can use it for component testing, 
>>> using Jelly,
>>> BSF supported languages, etc.
>>>
>>> Right now the Avalon Jelly service is in Jelly's CVS module (Jakarta
>>> Commons).  Depending upon what you need to do it to (I haven't 
>>> looked),
>>> perhaps you might want to talk about adopting it officially into the 
>>> Avalon
>>> project.
>>>
>>> 	--- Noel
>
> I thought about doing a generic Jelly service, but it was such a back
> burner issue I never had time to do it.  This could be really cool!
>
> Couldn't this be used for some of the scriptable components Leo was
> interested in?
>
> -- 
>  jaaron  <http://jadetower.org>
>
>
> ---------------------------------------------------------------------
> 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