More flexibility in the OSGi manifest headers

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

More flexibility in the OSGi manifest headers

W.B. Garvelink
Hi,



The CVS HEAD version of GlazedLists_java15, when built, contains these OSGi
headers:

> Require-Bundle: org.eclipse.swt,org.eclipse.jface
> Export-Package: (all packages; "impl" packages with an "x-internal:=true"
> directive.)

While these headers are probably the quickest way to make Glazed Lists work in
an Eclipse environment, they actually prohibit its use in any other OSGi
environment. My requirements at work are to use GlazedLists/Swing inside the
Apache Felix container. I simply use a modified manifest file there, but I'd
like to suggest a more comprehensive OSGi manifest here, which should give the
necessary flexibility to run Glazed Lists in any OSGi environment with either
GUI toolkit.

There are three ingredients to making this work:

 1) Use of "Import-Package:" instead of "Require-Bundle", which wires against
    the Java packages instead of the Bundle-SymbolicName of their provider.
    (please see [1] for background info)
 2) Use of "Import-Package: <package>;resolution:=optional", for specifying
    dependencies that get resolved during bundle resolution ("deployment", to
        oversimplify), but which won't cause resolution to fail if they're absent.
 3) Use of "DynamicImport-Package", for specifying packages that aren't
    resolved until the first time any of its classes is loaded.

The tricky bit is that I'm fairly new to OSGi myself and I have no experience
developing for the Eclipse platform. I've tried out the manifest I'm proposing
in Apache Felix and Java Swing, but I'd appreciate it if someone could test it
in an Eclipse Equinox and SWT container.

I've used the bnd tool (see [2]) to get the dependencies, then manually added
"resolution:=optional" directives where appropriate. It's possible to include
bnd into the build script instead of using a hand-kept manifest, but I haven't
taken it that far. One of the things bnd can does that I haven't is to specify
transitive dependencies on the imports ("uses" directive).

I'd appreciate it if you would consider using this more comprehensive OSGi
manifest instead of the one you have now. I think it may be worthwhile to
split the distribution into glazedlists-swt and glazedlists-swing, both would
be simpler and the two GUI toolkits are unlikely to be used in conjunction.

My proposed manifest file (actually just the import and export statements) is
at the end of this email. If you want me to, I can create a ticket in the
issue tracker and attach it there.

Thanks,
Barend

[1] http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html
[2] http://www.aqute.biz/Code/Bnd


==============================================================================
Export-Package: ca.odell.glazedlists;version=1.7.0,
 ca.odell.glazedlists.calculation;version=1.7.0,
 ca.odell.glazedlists.event;version=1.7.0,
 ca.odell.glazedlists.gui;version=1.7.0,
 ca.odell.glazedlists.hibernate;version=1.7.0,
 ca.odell.glazedlists.io;version=1.7.0,
 ca.odell.glazedlists.jfreechart;version=1.7.0,
 ca.odell.glazedlists.matchers;version=1.7.0,
 ca.odell.glazedlists.nachocalendar;version=1.7.0,
 ca.odell.glazedlists.swing;version=1.7.0,
 ca.odell.glazedlists.swt;version=1.7.0,
 ca.odell.glazedlists.util.concurrent;version=1.7.0,
 ca.odell.glazedlists.util.reflect;version=1.7.0,
 resources.aqua;version=1.7.0,
 resources.metal;version=1.7.0,
 resources.ocean;version=1.7.0,
 resources.windows;version=1.7.0,
 resources.windowsxp;version=1.7.0
Private-Package: ca.odell.glazedlists.impl,
 ca.odell.glazedlists.impl.adt,
 ca.odell.glazedlists.impl.adt.barcode2,
 ca.odell.glazedlists.impl.adt.gnutrove,
 ca.odell.glazedlists.impl.beans,
 ca.odell.glazedlists.impl.ctp,
 ca.odell.glazedlists.impl.event,
 ca.odell.glazedlists.impl.filter,
 ca.odell.glazedlists.impl.functions,
 ca.odell.glazedlists.impl.gui,
 ca.odell.glazedlists.impl.io,
 ca.odell.glazedlists.impl.matchers,
 ca.odell.glazedlists.impl.nio,
 ca.odell.glazedlists.impl.pmap,
 ca.odell.glazedlists.impl.rbp,
 ca.odell.glazedlists.impl.sort,
 ca.odell.glazedlists.impl.swing,
 ca.odell.glazedlists.impl.swt,
 ca.odell.glazedlists.impl.text
Import-Package: ca.odell.glazedlists,
 ca.odell.glazedlists.calculation,
 ca.odell.glazedlists.event,
 ca.odell.glazedlists.gui,
 ca.odell.glazedlists.io,
 ca.odell.glazedlists.jfreechart,
 ca.odell.glazedlists.matchers,
 ca.odell.glazedlists.swing,
 ca.odell.glazedlists.swt,
 ca.odell.glazedlists.util.concurrent,
 ca.odell.glazedlists.util.reflect,
 javax.accessibility;resolution:=optional,
 javax.swing;resolution:=optional,
 javax.swing.border;resolution:=optional,
 javax.swing.event;resolution:=optional,
 javax.swing.plaf;resolution:=optional,
 javax.swing.plaf.basic;resolution:=optional,
 javax.swing.plaf.metal;resolution:=optional,
 javax.swing.table;resolution:=optional,
 javax.swing.text;resolution:=optional,
 javax.swing.tree;resolution:=optional,
 javax.swing.undo;resolution:=optional,
 org.eclipse.jface.viewers;resolution:=optional,
 org.eclipse.swt.events;resolution:=optional,
 org.eclipse.swt.graphics;resolution:=optional,
 org.eclipse.swt.layout;resolution:=optional,
 org.eclipse.swt.widgets;resolution:=optional,
 com.ibm.icu.text;resolution:=optional,
 com.jgoodies.forms.layout;resolution:=optional,
 com.publicobject.issuesbrowser;resolution:=optional,
 com.publicobject.misc;resolution:=optional,
 de.kupzog.ktable;resolution:=optional,
 net.sf.nachocalendar;resolution:=optional,
 net.sf.nachocalendar.components;resolution:=optional,
 org.hibernate;resolution:=optional,
 org.hibernate.collection;resolution:=optional,
 org.hibernate.engine;resolution:=optional,
 org.hibernate.persister.collection;resolution:=optional,
 org.hibernate.usertype;resolution:=optional,
 org.jdesktop.swingx;resolution:=optional,
 org.jdesktop.swingx.decorator;resolution:=optional,
 org.jdesktop.swingx.table;resolution:=optional,
 org.jfree.data;resolution:=optional,
 org.jfree.data.category;resolution:=optional,
 org.jfree.data.general;resolution:=optional

==============================================================================
(Don't forget that blank line at the end of manifest.mf)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

James Lemieux
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

On Wed, Sep 10, 2008 at 12:48 PM, W.B. Garvelink <[hidden email]> wrote:
Hi,



The CVS HEAD version of GlazedLists_java15, when built, contains these OSGi
headers:

> Require-Bundle: org.eclipse.swt,org.eclipse.jface
> Export-Package: (all packages; "impl" packages with an "x-internal:=true"
> directive.)

While these headers are probably the quickest way to make Glazed Lists work in
an Eclipse environment, they actually prohibit its use in any other OSGi
environment. My requirements at work are to use GlazedLists/Swing inside the
Apache Felix container. I simply use a modified manifest file there, but I'd
like to suggest a more comprehensive OSGi manifest here, which should give the
necessary flexibility to run Glazed Lists in any OSGi environment with either
GUI toolkit.

There are three ingredients to making this work:

 1) Use of "Import-Package:" instead of "Require-Bundle", which wires against
   the Java packages instead of the Bundle-SymbolicName of their provider.
   (please see [1] for background info)
 2) Use of "Import-Package: <package>;resolution:=optional", for specifying
   dependencies that get resolved during bundle resolution ("deployment", to
       oversimplify), but which won't cause resolution to fail if they're absent.
 3) Use of "DynamicImport-Package", for specifying packages that aren't
   resolved until the first time any of its classes is loaded.

The tricky bit is that I'm fairly new to OSGi myself and I have no experience
developing for the Eclipse platform. I've tried out the manifest I'm proposing
in Apache Felix and Java Swing, but I'd appreciate it if someone could test it
in an Eclipse Equinox and SWT container.

I've used the bnd tool (see [2]) to get the dependencies, then manually added
"resolution:=optional" directives where appropriate. It's possible to include
bnd into the build script instead of using a hand-kept manifest, but I haven't
taken it that far. One of the things bnd can does that I haven't is to specify
transitive dependencies on the imports ("uses" directive).

I'd appreciate it if you would consider using this more comprehensive OSGi
manifest instead of the one you have now. I think it may be worthwhile to
split the distribution into glazedlists-swt and glazedlists-swing, both would
be simpler and the two GUI toolkits are unlikely to be used in conjunction.

My proposed manifest file (actually just the import and export statements) is
at the end of this email. If you want me to, I can create a ticket in the
issue tracker and attach it there.

Thanks,
Barend

[1] http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html
[2] http://www.aqute.biz/Code/Bnd


==============================================================================
Export-Package: ca.odell.glazedlists;version=1.7.0,
 ca.odell.glazedlists.calculation;version=1.7.0,
 ca.odell.glazedlists.event;version=1.7.0,
 ca.odell.glazedlists.gui;version=1.7.0,
 ca.odell.glazedlists.hibernate;version=1.7.0,
 ca.odell.glazedlists.io;version=1.7.0,
 ca.odell.glazedlists.jfreechart;version=1.7.0,
 ca.odell.glazedlists.matchers;version=1.7.0,
 ca.odell.glazedlists.nachocalendar;version=1.7.0,
 ca.odell.glazedlists.swing;version=1.7.0,
 ca.odell.glazedlists.swt;version=1.7.0,
 ca.odell.glazedlists.util.concurrent;version=1.7.0,
 ca.odell.glazedlists.util.reflect;version=1.7.0,
 resources.aqua;version=1.7.0,
 resources.metal;version=1.7.0,
 resources.ocean;version=1.7.0,
 resources.windows;version=1.7.0,
 resources.windowsxp;version=1.7.0
Private-Package: ca.odell.glazedlists.impl,
 ca.odell.glazedlists.impl.adt,
 ca.odell.glazedlists.impl.adt.barcode2,
 ca.odell.glazedlists.impl.adt.gnutrove,
 ca.odell.glazedlists.impl.beans,
 ca.odell.glazedlists.impl.ctp,
 ca.odell.glazedlists.impl.event,
 ca.odell.glazedlists.impl.filter,
 ca.odell.glazedlists.impl.functions,
 ca.odell.glazedlists.impl.gui,
 ca.odell.glazedlists.impl.io,
 ca.odell.glazedlists.impl.matchers,
 ca.odell.glazedlists.impl.nio,
 ca.odell.glazedlists.impl.pmap,
 ca.odell.glazedlists.impl.rbp,
 ca.odell.glazedlists.impl.sort,
 ca.odell.glazedlists.impl.swing,
 ca.odell.glazedlists.impl.swt,
 ca.odell.glazedlists.impl.text
Import-Package: ca.odell.glazedlists,
 ca.odell.glazedlists.calculation,
 ca.odell.glazedlists.event,
 ca.odell.glazedlists.gui,
 ca.odell.glazedlists.io,
 ca.odell.glazedlists.jfreechart,
 ca.odell.glazedlists.matchers,
 ca.odell.glazedlists.swing,
 ca.odell.glazedlists.swt,
 ca.odell.glazedlists.util.concurrent,
 ca.odell.glazedlists.util.reflect,
 javax.accessibility;resolution:=optional,
 javax.swing;resolution:=optional,
 javax.swing.border;resolution:=optional,
 javax.swing.event;resolution:=optional,
 javax.swing.plaf;resolution:=optional,
 javax.swing.plaf.basic;resolution:=optional,
 javax.swing.plaf.metal;resolution:=optional,
 javax.swing.table;resolution:=optional,
 javax.swing.text;resolution:=optional,
 javax.swing.tree;resolution:=optional,
 javax.swing.undo;resolution:=optional,
 org.eclipse.jface.viewers;resolution:=optional,
 org.eclipse.swt.events;resolution:=optional,
 org.eclipse.swt.graphics;resolution:=optional,
 org.eclipse.swt.layout;resolution:=optional,
 org.eclipse.swt.widgets;resolution:=optional,
 com.ibm.icu.text;resolution:=optional,
 com.jgoodies.forms.layout;resolution:=optional,
 com.publicobject.issuesbrowser;resolution:=optional,
 com.publicobject.misc;resolution:=optional,
 de.kupzog.ktable;resolution:=optional,
 net.sf.nachocalendar;resolution:=optional,
 net.sf.nachocalendar.components;resolution:=optional,
 org.hibernate;resolution:=optional,
 org.hibernate.collection;resolution:=optional,
 org.hibernate.engine;resolution:=optional,
 org.hibernate.persister.collection;resolution:=optional,
 org.hibernate.usertype;resolution:=optional,
 org.jdesktop.swingx;resolution:=optional,
 org.jdesktop.swingx.decorator;resolution:=optional,
 org.jdesktop.swingx.table;resolution:=optional,
 org.jfree.data;resolution:=optional,
 org.jfree.data.category;resolution:=optional,
 org.jfree.data.general;resolution:=optional

==============================================================================
(Don't forget that blank line at the end of manifest.mf)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

W.B. Garvelink
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

James Lemieux
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

On Wed, Sep 10, 2008 at 1:23 PM, W.B. Garvelink <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

W.B. Garvelink
James,


Thanks, I will start on this. Should have some results by next weekend.

Regards,
Barend


On 9/15/08, James Lemieux <[hidden email]> wrote:

> 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
>
> On Wed, Sep 10, 2008 at 1:23 PM, W.B. Garvelink
> <[hidden email]>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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

W.B. Garvelink
I mentioned last week that I should have an updated bnd definition by
about now. Altough I have made some progress, I'm not yet satisfied
with the results and I'm going to take some more time. I'll check back
in next weekend.


Barend



On Mon, Sep 15, 2008 at 9:30 AM, W.B. Garvelink
<[hidden email]> wrote:
> James,
>
>
> Thanks, I will start on this. Should have some results by next weekend.
>
> Regards,
> Barend
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

W.B. Garvelink
Hi Jesse,


I have attached a bnd definitions file and an modified ant task to
issue #454 in the tracker. The version I uploaded doesn't delete the
original JAR file but puts the OSGi file alongside it for easy
comparison. After checking the two, you may want to introduce a delete
and rename like there were there before.

I had to duplicate the JAR metadata in the .bnd file. You may want to
remove it from the ant build, but I'll leave that up to you.


Regards,
Barend



On Sun, Sep 21, 2008 at 4:52 PM, W.B. Garvelink
<[hidden email]> wrote:
> I mentioned last week that I should have an updated bnd definition by
> about now. Altough I have made some progress, I'm not yet satisfied
> with the results and I'm going to take some more time. I'll check back
> in next weekend.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

James Lemieux
Barend,

   I have added your changes to source control and updated the latest jars here.

Please try it out and let me know if you experience any troubles.

James

On Sun, Sep 28, 2008 at 1:15 PM, W.B. Garvelink <[hidden email]> wrote:
Hi Jesse,


I have attached a bnd definitions file and an modified ant task to
issue #454 in the tracker. The version I uploaded doesn't delete the
original JAR file but puts the OSGi file alongside it for easy
comparison. After checking the two, you may want to introduce a delete
and rename like there were there before.

I had to duplicate the JAR metadata in the .bnd file. You may want to
remove it from the ant build, but I'll leave that up to you.


Regards,
Barend



On Sun, Sep 21, 2008 at 4:52 PM, W.B. Garvelink
<[hidden email]> wrote:
> I mentioned last week that I should have an updated bnd definition by
> about now. Altough I have made some progress, I'm not yet satisfied
> with the results and I'm going to take some more time. I'll check back
> in next weekend.
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

W.B. Garvelink
Hi James,



Thank you. I built a new jar file and did in fact run into trouble.
There was a line missing from the bnd file. I checked, and it's also
missing from the file I uploaded into the issue tracker, making it my
fault. I don't know what happened there, sorry. Here's the missing
line:

Import-Package: *;resolution:=optional

This is the line that enables Glazed Lists to be deployed into an OSGi
container with some or all of its dependencies missing. It is to be
added to the bottom section of the glazedlists.bnd file.

Thanks and regards,

Barend




On Mon, Oct 6, 2008 at 10:15 AM, James Lemieux <[hidden email]> wrote:

> Barend,
>
>    I have added your changes to source control and updated the latest jars
> here.
>
> Please try it out and let me know if you experience any troubles.
>
> James
>
> On Sun, Sep 28, 2008 at 1:15 PM, W.B. Garvelink <[hidden email]>
> wrote:
>>
>> Hi Jesse,
>>
>>
>> I have attached a bnd definitions file and an modified ant task to
>> issue #454 in the tracker. The version I uploaded doesn't delete the
>> original JAR file but puts the OSGi file alongside it for easy
>> comparison. After checking the two, you may want to introduce a delete
>> and rename like there were there before.
>>
>> I had to duplicate the JAR metadata in the .bnd file. You may want to
>> remove it from the ant build, but I'll leave that up to you.
>>
>>
>> Regards,
>> Barend
>>
>>
>>
>> On Sun, Sep 21, 2008 at 4:52 PM, W.B. Garvelink
>> <[hidden email]> wrote:
>> > I mentioned last week that I should have an updated bnd definition by
>> > about now. Altough I have made some progress, I'm not yet satisfied
>> > with the results and I'm going to take some more time. I'll check back
>> > in next weekend.
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

James Lemieux
Barend,

   The latest jars have been updated to include this change.

James

On Fri, Oct 10, 2008 at 5:09 AM, W.B. Garvelink <[hidden email]> wrote:
Hi James,



Thank you. I built a new jar file and did in fact run into trouble.
There was a line missing from the bnd file. I checked, and it's also
missing from the file I uploaded into the issue tracker, making it my
fault. I don't know what happened there, sorry. Here's the missing
line:

Import-Package: *;resolution:=optional

This is the line that enables Glazed Lists to be deployed into an OSGi
container with some or all of its dependencies missing. It is to be
added to the bottom section of the glazedlists.bnd file.

Thanks and regards,

Barend




On Mon, Oct 6, 2008 at 10:15 AM, James Lemieux <[hidden email]> wrote:
> Barend,
>
>    I have added your changes to source control and updated the latest jars
> here.
>
> Please try it out and let me know if you experience any troubles.
>
> James
>
> On Sun, Sep 28, 2008 at 1:15 PM, W.B. Garvelink <[hidden email]>
> wrote:
>>
>> Hi Jesse,
>>
>>
>> I have attached a bnd definitions file and an modified ant task to
>> issue #454 in the tracker. The version I uploaded doesn't delete the
>> original JAR file but puts the OSGi file alongside it for easy
>> comparison. After checking the two, you may want to introduce a delete
>> and rename like there were there before.
>>
>> I had to duplicate the JAR metadata in the .bnd file. You may want to
>> remove it from the ant build, but I'll leave that up to you.
>>
>>
>> Regards,
>> Barend
>>
>>
>>
>> On Sun, Sep 21, 2008 at 4:52 PM, W.B. Garvelink
>> <[hidden email]> wrote:
>> > I mentioned last week that I should have an updated bnd definition by
>> > about now. Altough I have made some progress, I'm not yet satisfied
>> > with the results and I'm going to take some more time. I'll check back
>> > in next weekend.
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in the OSGi manifest headers

W.B. Garvelink
Thank you.


Barend



On Mon, Oct 13, 2008 at 11:05 AM, James Lemieux <[hidden email]> wrote:

> Barend,
>
>    The latest jars have been updated to include this change.
>
> James
>
> On Fri, Oct 10, 2008 at 5:09 AM, W.B. Garvelink <[hidden email]>
> wrote:
>>
>> Hi James,
>>
>>
>>
>> Thank you. I built a new jar file and did in fact run into trouble.
>> There was a line missing from the bnd file. I checked, and it's also
>> missing from the file I uploaded into the issue tracker, making it my
>> fault. I don't know what happened there, sorry. Here's the missing
>> line:
>>
>> Import-Package: *;resolution:=optional
>>
>> This is the line that enables Glazed Lists to be deployed into an OSGi
>> container with some or all of its dependencies missing. It is to be
>> added to the bottom section of the glazedlists.bnd file.
>>
>> Thanks and regards,
>>
>> Barend
>>
>>
>>
>>
>> On Mon, Oct 6, 2008 at 10:15 AM, James Lemieux <[hidden email]>
>> wrote:
>> > Barend,
>> >
>> >    I have added your changes to source control and updated the latest
>> > jars
>> > here.
>> >
>> > Please try it out and let me know if you experience any troubles.
>> >
>> > James
>> >
>> > On Sun, Sep 28, 2008 at 1:15 PM, W.B. Garvelink
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Hi Jesse,
>> >>
>> >>
>> >> I have attached a bnd definitions file and an modified ant task to
>> >> issue #454 in the tracker. The version I uploaded doesn't delete the
>> >> original JAR file but puts the OSGi file alongside it for easy
>> >> comparison. After checking the two, you may want to introduce a delete
>> >> and rename like there were there before.
>> >>
>> >> I had to duplicate the JAR metadata in the .bnd file. You may want to
>> >> remove it from the ant build, but I'll leave that up to you.
>> >>
>> >>
>> >> Regards,
>> >> Barend
>> >>
>> >>
>> >>
>> >> On Sun, Sep 21, 2008 at 4:52 PM, W.B. Garvelink
>> >> <[hidden email]> wrote:
>> >> > I mentioned last week that I should have an updated bnd definition by
>> >> > about now. Altough I have made some progress, I'm not yet satisfied
>> >> > with the results and I'm going to take some more time. I'll check
>> >> > back
>> >> > in next weekend.
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]