Hi Sahoo,
I've had the Class.forName issue in the back of my mind for a while
now. Web framework code does this a lot (JSF does, jsftemplating does,
woodstock does). Are the fixes Jerome provided
(Glassfish-require-services & HK2-Import-Bundles) enough to work around
all the problems? I haven't seen any issues come up, but I haven't been
deploying multiple applications which use these OSGi bundles concurrently.
I'll look for the ant bnd plugin, that's exactly what I need...
Ken
Sahoo wrote:
>
>>
>> Ken Paulsen wrote:
>>>
>>> Hi,
>>>
>>> In GF v3 just about everything is an OSGi bundle. This including
>>> all our plugins to our admin console as well any code those plugins
>>> rely on. This means, in order to use the Woodstock UIComponents (or
>>> any other woodstock code) from a plugin, then woodstock needs to be
>>> packaged as an OSGi bundle.
>>>
>>> We can either repackage the webui.jar (and potentially others -- I'm
>>> already doing dataprovider.jar) as an OSGi bundle during our build
>>> process. However, doing that does not help anyone else that wants
>>> Woodstock as an OSGi bundle. It would be very nice if you added the
>>> MANIFEST.MF entries necessary to use your jar files in an OSGi
>>> environment. Nothing else would need to change, just the
>>> MANIFEST.MF file.
> Without looking at the code, I can't say that. If it does
> Class.forName or META-INF/services lookup, then in order to be used in
> pure OSGi environment, those code have to be revisited.
>>>
>>> I'm not sure how to best automate this using ant (Sahoo, do you
>>> know?). Although I can show you how this can be done using the
>>> maven bnd plugin. Either way, this would be better than
>>> creating/maintaining the MANIFEST entries by hand.
> Yes, there is an Ant plugin to bnd as well. Just search for it; I
> don't have the link handy.
>
> Thanks,
> Sahoo
>>>
>>> If you want help doing this, I'm willing to do the work.
>>>
>>> Thanks!
>>>
>>> Ken