RfC: put jruby-complete jar into server/default/lib ?
Joseph Marques
jmarques at redhat.com
Mon Jan 25 09:35:55 UTC 2010
On 01/25/2010 03:59 AM, Heiko W.Rupp wrote:
> Am 25.01.2010 um 01:54 schrieb Joseph Marques:
>
>> If we want to promote the community writing their own plugins for
>> things, then we need to make sure the process "just works" for them.
>>
> I completely agree with you.
>
>
>> Packaging libraries in plugins seems like a very common task, so if we
>> (the platform developers) can't do it, do we reasonably expect them
>> (plugin writers in the community) to do it? We need to figure out why
>> packaging the library in your plugin is not working.
>>
> This here seems to be a more special case as the registration of
> JSR-223 script languages is done through some classloader magic:
> when loading the jar it looks for META-INF/servcies/javax.script.ScriptEngineFactory
> and tries to instantiate the class, that is found inside.
>
>
> Anyway: my question here was a little bit about wanting to be lazy :-)
> But also about "do we want to enable another language on the server, that
> people can use in server side plugins like the alert ones or in perspectives?"
>
I'm on the fence about this. On the one hand, it would be nice to
support several different languages because that makes the platform more
attractive to a wider audience. On the other hand, I wonder whether
there will be any interop concerns in the future.
Agent-side plugins today have a rich concept of inheritance - both
extension and injected is supported. If we ever think that the
community will require server-side plugins with the same functionality,
then allowing multiple languages will introduce a style that makes them
naturally more difficult (or impossible) to reuse in the way agent-side
plugins have been reused.
More information about the rhq-devel
mailing list