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