On 04/19/2010 05:07 PM, Woonsan Ko wrote:
----- Original Message ----
From: Ate Douma<[email protected]>
To: Jetspeed Developers List<[email protected]>
Sent: Mon, April 19, 2010 4:46:00 PM
Subject: Re: edit_defaults
On 04/19/2010 04:38 PM, Woonsan Ko wrote:
Hi
Ate/All,
----- Original Message ----
From:
Ate Douma<
href="mailto:[email protected]";>[email protected]>
To: Jetspeed
Developers List<
href="mailto:[email protected]";>[email protected]>
Cc: Bridges Developers List<
ymailto="mailto:[email protected]";
href="mailto:[email protected]";>[email protected]>
Sent: Fri, April 9, 2010 1:18:02 PM
Subject: Re:
edit_defaults
I also committed an initial fix for
the
GenericVelocityPortlet almost like what you proposed earlier on
this email (and
which was the
trigger for all this),
see:
http://issues.apache.org/jira/browse/PB-103
I'm
leaving the root JIRA
issue for this,
http://issues.apache.org/jira/browse/PB-98, open for now as
there
still remains work to be done on
especially the bridges-site (only
the
groundwork has been done so far) and pending possible migration
of other bridges
like maybe the groovy
and
struts
bridge.
I think it would be better to move
out the groovy bridge to /portals/bridges/trunk/bridges-scripts; We can simply
add jruby or jython supports there as well as groovy in the similar way.
I
think that could make sense from a *bridge* development/maintenance
POV.
One thing to consider though is if the end-user of such a bridge
would want/need to use like all three scripting engines (groovy, jruby,
jython) at the same time?
If not, bundling them all together might not be
optimal because of all the (runtime) dependencies being pulled in to support all
of them.
In that case providing dedicated "engine" specific bridges only
needed that engine specific dependencies might be preferred.
Maybe a more
abstract main "scripting-bridge" with specific implementation sub bridges (e.g.
groovy, jruby, etc.) could be done instead.
Maybe something like how slf4j
works with separated back-end logging engine specific
implementations.
Thanks for the response.
I thought we could have *provided* dependencies for the physical scripting
engine libraries.
For example, if a user wants to use bridges-scripts with jruby, then the user
should provide jruby runtime libraries.
I thought this would make it simpler than having multiple projects for each
scripting engine. This approach is the same way as springframework does for
script beans support.
Yes, that would be a good solution too, I didn't think of that!
Great, I'm +1 on using that solution.
Ate
I'm not sure what others feel like though.
Regards,
Woonsan
Regards,
Ate
Kind
regards,
Woonsan
---------------------------------------------------------------------
To
unsubscribe, e-mail:
ymailto="mailto:[email protected]";
href="mailto:[email protected]";>[email protected]
For additional commands, e-mail:
ymailto="mailto:[email protected]";
href="mailto:[email protected]";>[email protected]
---------------------------------------------------------------------
To
unsubscribe, e-mail:
ymailto="mailto:[email protected]";
href="mailto:[email protected]";>[email protected]
For
additional commands, e-mail:
ymailto="mailto:[email protected]";
href="mailto:[email protected]";>[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
