« Return to Thread: More flexibility in the OSGi manifest headers
Re: More flexibility in the OSGi manifest headers
by James Lemieux
::
Rate this Message:
Barend,
I've done the initial work in this area this weekend, but I'm going to pass the torch to you to do the detail work. Specifically, here is how it works as of now:
The GL build system is able to download jars it needs on-the-fly from a jar repository we keep at http://glazedlists.dev.java.net
I have added bnd.jar to that repository and updated our build.xml file to use the "bndwrap" ANT task to make an OSGi bundle our of our vanilla GL jars.
You can see this happen in the "jar" task of the GL build.xml file.
This is as far as I've gotten. If you execute "ant jar" it *does* generate an OSGi bundle without errors. What I'd hope you can help with is refining the output to be more precise. Specifically:
1) All Import-Packages appear like this:
Import-Package: ca.odell.glazedlists;resolution:=optional,
ca.odell.glazedlists.calculation;resolution:=optional,
ca.odell.glazedlists.event;resolution:=optional,
ca.odell.glazedlists.gui;resolution:=optional,
ca.odell.glazedlists.hibernate;resolution:=optional,
...
but I doubt it's correct to have all packages marked "resolution:=optional".... even though I'm not terribly sure what that even means.
2) All packages are exported at the moment, including ".impl" packages. Since this is one of the areas that the OSGi spec precisely exists to service (making public classes in private packages inaccessible) it would be nice to be able to remove these impl packages from that section, or mark them private.
3) I don't have an OSGi container installed anywhere so I'm not testing any of this at the moment.
The changes to build.xml are checked into HEAD but I did not rebuild the GL jars. Barend, are you able to pull the latest changes from CVS and try to refine the "jar" target to produce better manifest.mf entries? If so, that would help a lot.
Thanks,
James
I've done the initial work in this area this weekend, but I'm going to pass the torch to you to do the detail work. Specifically, here is how it works as of now:
The GL build system is able to download jars it needs on-the-fly from a jar repository we keep at http://glazedlists.dev.java.net
I have added bnd.jar to that repository and updated our build.xml file to use the "bndwrap" ANT task to make an OSGi bundle our of our vanilla GL jars.
You can see this happen in the "jar" task of the GL build.xml file.
This is as far as I've gotten. If you execute "ant jar" it *does* generate an OSGi bundle without errors. What I'd hope you can help with is refining the output to be more precise. Specifically:
1) All Import-Packages appear like this:
Import-Package: ca.odell.glazedlists;resolution:=optional,
ca.odell.glazedlists.calculation;resolution:=optional,
ca.odell.glazedlists.event;resolution:=optional,
ca.odell.glazedlists.gui;resolution:=optional,
ca.odell.glazedlists.hibernate;resolution:=optional,
...
but I doubt it's correct to have all packages marked "resolution:=optional".... even though I'm not terribly sure what that even means.
2) All packages are exported at the moment, including ".impl" packages. Since this is one of the areas that the OSGi spec precisely exists to service (making public classes in private packages inaccessible) it would be nice to be able to remove these impl packages from that section, or mark them private.
3) I don't have an OSGi container installed anywhere so I'm not testing any of this at the moment.
The changes to build.xml are checked into HEAD but I did not rebuild the GL jars. Barend, are you able to pull the latest changes from CVS and try to refine the "jar" target to produce better manifest.mf entries? If so, that would help a lot.
Thanks,
James
On Wed, Sep 10, 2008 at 1:23 PM, W.B. Garvelink <barend.garvelink@...> wrote:
James,
Thanks so far. I have created the issue (#454) and I'll happily work
with you and Bruce to tackle any issues that may come up.
Barend
On Wed, Sep 10, 2008 at 10:09 PM, James Lemieux <jplemieux@...> wrote:
> Hey Barend,
>
> OSGi support was done by me working in conjunction with Bruce Alspaugh I
> believe. I believe he was using it in an Eclipse RCP app, and so the way we
> worked was:
>
> 1) I modified our build system
> 2) Bruce tested it in his environment
> 3) repeat 1) and 2) until it seemed to do everything we needed
>
> I'm not even close to an OSGi expert. And I've never used Eclipse (always
> IDEA).
>
> I have no problems making the changes you require as long as they are
> compatible for use in the Eclipse RCP environment. (Since OSGi is actually a
> standalone spec, I'll assume that this is an easy assumption).
>
> Bruce, if you're still lurking out there, would you be willing to retest the
> GL jar within an Eclipse RCP once again after we've made these changes?
>
> Barend, please file a bug in the GL issue tracker so this work isn't lost
> for any reason.
>
> James
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...
« Return to Thread: More flexibility in the OSGi manifest headers
| Free embeddable forum powered by Nabble | Forum Help |
