Thats an excellent idea. I think there are still parts of this that could be
made significantly easier by altering the SPI but I'll be happy to have them
in utility jar for now. I'll go do this.
...ant
On 11/9/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
How about adding a scripting utility
This hasn't entirely turned out as I was expecting. This container now looks
remarkably similar to the other existing ones, I thought we were trying to
refactor out the common parts to come up with an easier container SPI? Lets
take MissingSideFileException as an example, that could be reused by
On Nov 8, 2006, at 2:08 PM, ant elder wrote:
This hasn't entirely turned out as I was expecting. This container
now looks
remarkably similar to the other existing ones,
I see this as a good sign...to me it means we are arriving at an SPI
I thought we were trying to
refactor out the common
O.K., I committed the refactor to container.script with the follow
changes:
1. Fixed the project so it builds again :-) (it is not part of the
default build)
2. Removed the need for Async target invokers based on core changes
3. Remove ComponentType hack as that has been fixed in core
4.
Any luck in making these changes?
Jim
On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
As you don't like the easy SPI extension I've got rid of the easy
extension
dependency of the script container. I've moved the script
container into
trunk as it was going stale and i want to start using
No, tied up on M2 things, i doubt I'll have time for this till M2 is done.
...ant
On 10/31/06, Jim Marino [EMAIL PROTECTED] wrote:
Any luck in making these changes?
Jim
On Oct 26, 2006, at 8:30 AM, Jim Marino wrote:
As you don't like the easy SPI extension I've got rid of the easy
So do you mind if I make the changes?
Jim
On Oct 31, 2006, at 1:02 AM, ant elder wrote:
No, tied up on M2 things, i doubt I'll have time for this till M2
is done.
...ant
On 10/31/06, Jim Marino [EMAIL PROTECTED] wrote:
Any luck in making these changes?
Jim
On Oct 26, 2006, at 8:30
As you don't like the easy SPI extension I've got rid of the easy
extension
dependency of the script container. I've moved the script container
into
trunk as it was going stale and i want to start using and improving
it. It
still uses some of the easy classes which are in a helper package
On Oct 25, 2006, at 8:02 AM, ant elder wrote:
Comments in line...
...ant
On 10/11/06, Jim Marino [EMAIL PROTECTED] wrote:
snip
- How are script scopes handled? I'm assuming we want to have the
runtime manage statefull scripts, as we get that for free.
agree
- I also noticed the scope
On 10/10/06, Jim Marino [EMAIL PROTECTED] wrote:
On Oct 10, 2006, at 7:53 AM, ant elder wrote:
I'd be really happy for all those to become part of the core, but
I'm not
sure I see how all that remains will be a few three-line
statements. How
about I move this to a container-helper as I
Comments in line...
...ant
On 10/11/06, Jim Marino [EMAIL PROTECTED] wrote:
snip
- How are script scopes handled? I'm assuming we want to have the
runtime manage statefull scripts, as we get that for free.
agree
- I also noticed the scope is set by default to Module. The default
SCA
Hi,
A few comments inline
Thanks
- Venkat
On 10/11/06, Jim Marino [EMAIL PROTECTED] wrote:
On Oct 10, 2006, at 7:53 AM, ant elder wrote:
I'd be really happy for all those to become part of the core, but
I'm not
sure I see how all that remains will be a few three-line
statements. How
This is ending up all talk and no action so I'm going to again suggest just
moving it now, pulling the bits into core as discussed and you've said
you'll help with, and then seeing whats left and decide what to do with that
then.
...ant
On 10/11/06, Jim Marino [EMAIL PROTECTED] wrote:
I
On Oct 11, 2006, at 6:00 AM, ant elder wrote:
This is ending up all talk and no action
I don't see it that way. I think we are trying to arrive at the right
thing to do...I've asked specific questions that I'd like to get
answers to before I feel comfortable moving this out of the sandbox.
I looked at this some more and I think we can make a change in core
to support loading of custom component types. This will allow us to
get rid of having to use encapsulation for component types. Also, the
async invoker should move into an extension class in core. Finally, I
think
I'd be really happy for all those to become part of the core, but I'm not
sure I see how all that remains will be a few three-line statements. How
about I move this to a container-helper as I suggested before, we pull all
the bits out and do the refactoring and before we cut M2 see whats left and
On Oct 10, 2006, at 7:53 AM, ant elder wrote:
I'd be really happy for all those to become part of the core, but
I'm not
sure I see how all that remains will be a few three-line
statements. How
about I move this to a container-helper as I suggested before, we
pull all
the bits out and do
On 10/7/06, Jim Marino [EMAIL PROTECTED] wrote:
On Oct 7, 2006, at 10:42 AM, Jim Marino wrote:
On Oct 7, 2006, at 7:22 AM, ant elder wrote:
This is all working quite well now so i'd like to move it from my
sandbox to
be with the other containers. BSF 2.4 has just come out and the
jar
On Oct 9, 2006, at 3:42 AM, ant elder wrote:
On 10/7/06, Jim Marino [EMAIL PROTECTED] wrote:
On Oct 7, 2006, at 10:42 AM, Jim Marino wrote:
On Oct 7, 2006, at 7:22 AM, ant elder wrote:
This is all working quite well now so i'd like to move it from my
sandbox to
be with the other
Hi Jim...
Here is whatever I know of this...
To start with, yes this is just for the script containers
When we were doing the containers for scripting, we found that we were just
copying a basic framework of common code across containers and then
specializing parts that were very specific to
This is all working quite well now so i'd like to move it from my sandbox to
be with the other containers. BSF 2.4 has just come out and the jar is
available from a proper maven repo and the script container supports all the
SCA things like references, properties and async, also the start of a
On Oct 7, 2006, at 7:22 AM, ant elder wrote:
This is all working quite well now so i'd like to move it from my
sandbox to
be with the other containers. BSF 2.4 has just come out and the jar is
available from a proper maven repo and the script container
supports all the
SCA things like
On Oct 7, 2006, at 10:42 AM, Jim Marino wrote:
On Oct 7, 2006, at 7:22 AM, ant elder wrote:
This is all working quite well now so i'd like to move it from my
sandbox to
be with the other containers. BSF 2.4 has just come out and the
jar is
available from a proper maven repo and the
Thanks Ant. No problems about the change.. I will lookup sometime to get to
the same page.
- Venkat
On 9/14/06, ant elder [EMAIL PROTECTED] wrote:
I've added this ruby container to the sandbox now Venkat. I changed it to
handle the response types the way i'd already done for the rhino
I've the same problem getting this to work with rhino which also needs the
response class and i made a similar simple change to get it to work. The
proper change you describe at the end sounds ok, one thing to consider is
the new databinding framework and the IDL-independent
I've added this ruby container to the sandbox now Venkat. I changed it to
handle the response types the way i'd already done for the rhino container,
not because that way is better just as i'd already done that for the other
containers so it was easier than changing everything to the ruby way and
Hi Ant,
Sequel to our last chat over IRC I took a look at your Sandbox. I am able
to understand all of what you have done there. A couple of thoughts /
questions ...
- So would it be that we just have this one 'ScriptContainer' that will take
care of javascript, ruby, groovy.
- Would it be
27 matches
Mail list logo
