Packaging GlazedLists as a Bundle

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

Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
Would it be possible to package the GlazedLists .jar distribution as an
Eclipse bundle? It would make it a bit easier for Eclipse plug-in
developers to integrate the code library with their other plug-ins.  It
would also simplify loading sort images directly from the .jar
distribution.  I could assign a plug-in id to GlazedLists, and load the
images relative to it.

Basically, I need some additional entries in the MANIFEST.MF file in the
distribution .jar.  The entries specify things like the plug-in id
(called the "Bundle-SymbolicName" in the file), required dependencies
(org.eclipse.swt and org.eclipse.jface), the list of packages exported
by Glazed Lists, and version information.  I have attached a MANIFEST.MF
file that shows the entries I need.

I see that you are in the process of making a new .jar for 1.7.1. Could
you include these entries?

Bruce

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Glazedlists Plug-in
Bundle-SymbolicName: ca.odell.glazedlists
Bundle-Version: 1.7.0
Bundle-ClassPath: .
Bundle-Localization: plugin
Export-Package: ca.odell.glazedlists,
 ca.odell.glazedlists.event,
 ca.odell.glazedlists.gui,
 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.filter,
 ca.odell.glazedlists.impl.gui,
 ca.odell.glazedlists.impl.io,
 ca.odell.glazedlists.impl.java15,
 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.io,
 ca.odell.glazedlists.jfreechart,
 ca.odell.glazedlists.matchers,
 ca.odell.glazedlists.migrationkit,
 ca.odell.glazedlists.migrationkit.swing,
 ca.odell.glazedlists.migrationkit.swt,
 ca.odell.glazedlists.nachocalendar,
 ca.odell.glazedlists.swing,
 ca.odell.glazedlists.swt,
 ca.odell.glazedlists.util.concurrent,
 resources.aqua,
 resources.metal,
 resources.ocean,
 resources.windows,
 resources.windowsxp
Require-Bundle: org.eclipse.swt,
 org.eclipse.jface


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

James Lemieux
Bruce,

   If there is nothing else about glazedlists.jar that needs to change, and only the manifest file needs extra entries, then I'm completely on board with adding them in and making it easier for use as an Eclipse plug-in. If the contents of the jar would need shuffling, it could be a harder sell, but that doesn't appear to be the case.

   Since the format of the manifest entries is well-known for eclipse plugins, I'd hope that there is an optional ANT task that could generate them. Any idea if that exists and could ease the implementation burdens? Ideally, it would do things like automatically create the Export-Package entry given a patternset.

   Failing the above, we can add more lines to the "jar" task of our build.xml file and try to manhandle the data in, but I'd really like it if the Export-Package entry was generated and not hard-coded (and thus maintained).

   So in short, sounds good dude!

James

On 8/25/06, Bruce Alspaugh <[hidden email] > wrote:
Would it be possible to package the GlazedLists .jar distribution as an
Eclipse bundle? It would make it a bit easier for Eclipse plug-in
developers to integrate the code library with their other plug-ins.  It
would also simplify loading sort images directly from the .jar
distribution.  I could assign a plug-in id to GlazedLists, and load the
images relative to it.

Basically, I need some additional entries in the MANIFEST.MF file in the
distribution .jar.  The entries specify things like the plug-in id
(called the "Bundle-SymbolicName" in the file), required dependencies
(org.eclipse.swt and org.eclipse.jface), the list of packages exported
by Glazed Lists, and version information.  I have attached a MANIFEST.MF
file that shows the entries I need.

I see that you are in the process of making a new .jar for 1.7.1. Could
you include these entries?

Bruce


Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Glazedlists Plug-in
Bundle-SymbolicName: ca.odell.glazedlists
Bundle-Version: 1.7.0
Bundle-ClassPath: .
Bundle-Localization: plugin
Export-Package: ca.odell.glazedlists,
ca.odell.glazedlists.event,
ca.odell.glazedlists.gui,
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.filter,
ca.odell.glazedlists.impl.gui ,
ca.odell.glazedlists.impl.io,
ca.odell.glazedlists.impl.java15,
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.io,
ca.odell.glazedlists.jfreechart,
ca.odell.glazedlists.matchers,
ca.odell.glazedlists.migrationkit,
ca.odell.glazedlists.migrationkit.swing,
ca.odell.glazedlists.migrationkit.swt,
ca.odell.glazedlists.nachocalendar ,
ca.odell.glazedlists.swing,
ca.odell.glazedlists.swt,
ca.odell.glazedlists.util.concurrent,
resources.aqua,
resources.metal,
resources.ocean,
resources.windows,
resources.windowsxp
Require-Bundle: org.eclipse.swt,
org.eclipse.jface



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


Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

James Lemieux
Oh, one other tiny thing. I'd make it:

Bundle-Name: Glazed Lists Plug-in

instead of

Bundle-Name: Glazedlists Plug-in


to be more consistent with the Implementation-Title entry, and the true name of the project.

James

On 8/25/06, James Lemieux <[hidden email]> wrote:
Bruce,

   If there is nothing else about glazedlists.jar that needs to change, and only the manifest file needs extra entries, then I'm completely on board with adding them in and making it easier for use as an Eclipse plug-in. If the contents of the jar would need shuffling, it could be a harder sell, but that doesn't appear to be the case.

   Since the format of the manifest entries is well-known for eclipse plugins, I'd hope that there is an optional ANT task that could generate them. Any idea if that exists and could ease the implementation burdens? Ideally, it would do things like automatically create the Export-Package entry given a patternset.

   Failing the above, we can add more lines to the "jar" task of our build.xml file and try to manhandle the data in, but I'd really like it if the Export-Package entry was generated and not hard-coded (and thus maintained).

   So in short, sounds good dude!

James

On 8/25/06, Bruce Alspaugh <[hidden email] > wrote:
Would it be possible to package the GlazedLists .jar distribution as an
Eclipse bundle? It would make it a bit easier for Eclipse plug-in
developers to integrate the code library with their other plug-ins.  It
would also simplify loading sort images directly from the .jar
distribution.  I could assign a plug-in id to GlazedLists, and load the
images relative to it.

Basically, I need some additional entries in the MANIFEST.MF file in the
distribution .jar.  The entries specify things like the plug-in id
(called the "Bundle-SymbolicName" in the file), required dependencies
(org.eclipse.swt and org.eclipse.jface), the list of packages exported
by Glazed Lists, and version information.  I have attached a MANIFEST.MF
file that shows the entries I need.

I see that you are in the process of making a new .jar for 1.7.1. Could
you include these entries?

Bruce


Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Glazedlists Plug-in
Bundle-SymbolicName: ca.odell.glazedlists
Bundle-Version: 1.7.0
Bundle-ClassPath: .
Bundle-Localization: plugin
Export-Package: ca.odell.glazedlists,
ca.odell.glazedlists.event,
ca.odell.glazedlists.gui,
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.filter,
ca.odell.glazedlists.impl.gui ,
<a href="http://ca.odell.glazedlists.impl.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ca.odell.glazedlists.impl.io,
ca.odell.glazedlists.impl.java15,
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,
<a href="http://ca.odell.glazedlists.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> ca.odell.glazedlists.io,
ca.odell.glazedlists.jfreechart,
ca.odell.glazedlists.matchers,
ca.odell.glazedlists.migrationkit,
ca.odell.glazedlists.migrationkit.swing,
ca.odell.glazedlists.migrationkit.swt,
ca.odell.glazedlists.nachocalendar ,
ca.odell.glazedlists.swing,
ca.odell.glazedlists.swt,
ca.odell.glazedlists.util.concurrent,
resources.aqua,
resources.metal,
resources.ocean,
resources.windows,
resources.windowsxp
Require-Bundle: org.eclipse.swt,
org.eclipse.jface



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



Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
I don't think we need to reshuffle the .jar beyond adding additional
entries to the manifest.mf file.  I'm fine with your suggested
Bundle-Name change.

Eclipse may have an ANT task to do it, but I used an easier way.  The
Eclipse import wizard allows you to import any .jar file into your
workspace as an Eclipse plug-in.  It automatically generates a
manifest.mf file that includes the Export-Package entry to get you
started.  In order to use the .jar as a plug-in, I had to manually
specify some additional information.  When you open the manifest.mf file
in an editor, it gives you multiple tabs.  The last tab lets you edit
the file manually, but I didn't need to.  The Overview tab lets you type
in the plug-in ID, version and plug-in name which is what I used.  The
Dependencies tab let me specify the bundles that the library depends
on:  org.eclipse.swt and org.eclipse.jface.

Bruce

James Lemieux wrote:

> Oh, one other tiny thing. I'd make it:
>
> Bundle-Name: Glazed Lists Plug-in
>
> instead of
>
> Bundle-Name: Glazedlists Plug-in
>
>
> to be more consistent with the Implementation-Title entry, and the
> true name of the project.
>
> James
>
> On 8/25/06, *James Lemieux* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Bruce,
>
>        If there is nothing else about glazedlists.jar that needs to
>     change, and only the manifest file needs extra entries, then I'm
>     completely on board with adding them in and making it easier for
>     use as an Eclipse plug-in. If the contents of the jar would need
>     shuffling, it could be a harder sell, but that doesn't appear to
>     be the case.
>
>        Since the format of the manifest entries is well-known for
>     eclipse plugins, I'd hope that there is an optional ANT task that
>     could generate them. Any idea if that exists and could ease the
>     implementation burdens? Ideally, it would do things like
>     automatically create the Export-Package entry given a patternset.
>
>        Failing the above, we can add more lines to the "jar" task of
>     our build.xml file and try to manhandle the data in, but I'd
>     really like it if the Export-Package entry was generated and not
>     hard-coded (and thus maintained).
>
>        So in short, sounds good dude!
>
>     James
>
>     On 8/25/06, *Bruce Alspaugh* < [hidden email]
>     <mailto:[hidden email]> > wrote:
>     Would it be possible to package the GlazedLists .jar distribution
>     as an
>     Eclipse bundle? It would make it a bit easier for Eclipse plug-in
>     developers to integrate the code library with their other
>     plug-ins.  It
>     would also simplify loading sort images directly from the .jar
>     distribution.  I could assign a plug-in id to GlazedLists, and
>     load the
>     images relative to it.
>
>     Basically, I need some additional entries in the MANIFEST.MF file
>     in the
>     distribution .jar.  The entries specify things like the plug-in id
>     (called the "Bundle-SymbolicName" in the file), required dependencies
>     (org.eclipse.swt and org.eclipse.jface), the list of packages exported
>     by Glazed Lists, and version information.  I have attached a
>     MANIFEST.MF
>     file that shows the entries I need.
>
>     I see that you are in the process of making a new .jar for 1.7.1.
>     Could
>     you include these entries?
>
>     Bruce
>
>
>     Manifest-Version: 1.0
>     Bundle-ManifestVersion: 2
>     Bundle-Name: Glazedlists Plug-in
>     Bundle-SymbolicName: ca.odell.glazedlists
>     Bundle-Version: 1.7.0
>     Bundle-ClassPath: .
>     Bundle-Localization: plugin
>     Export-Package: ca.odell.glazedlists,
>     ca.odell.glazedlists.event,
>     ca.odell.glazedlists.gui,
>     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.filter,
>     ca.odell.glazedlists.impl.gui ,
>     ca.odell.glazedlists.impl.io <http://ca.odell.glazedlists.impl.io>,
>     ca.odell.glazedlists.impl.java15,
>     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.io <http://ca.odell.glazedlists.io>,
>     ca.odell.glazedlists.jfreechart,
>     ca.odell.glazedlists.matchers,
>     ca.odell.glazedlists.migrationkit,
>     ca.odell.glazedlists.migrationkit.swing,
>     ca.odell.glazedlists.migrationkit.swt,
>     ca.odell.glazedlists.nachocalendar ,
>     ca.odell.glazedlists.swing,
>     ca.odell.glazedlists.swt,
>     ca.odell.glazedlists.util.concurrent,
>     resources.aqua,
>     resources.metal,
>     resources.ocean,
>     resources.windows,
>     resources.windowsxp
>     Require-Bundle: org.eclipse.swt,
>     org.eclipse.jface
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
In reply to this post by James Lemieux
I forgot to mention another manifest entry that might prove useful is
the plug-in provider:

Bundle-Vendor: www.publicobject.com/glazedlists

Bruce

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

Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

James Lemieux
In reply to this post by Bruce Alspaugh-2
Bruce,

   Using the wizard in Eclipse isn't a robust solution because:

a) Glazed Lists already generates a manifest.mf of its own with our own special entries. So we're looking to add the eclipse plugin manifest entries to what we already define (see the jar target in Glazed List's build.xml for the manifest we're building today) We actually use those values in a Main class that we ship so that double clicking the glazedlists.jar (on most platforms) displays version information, as a convenience.

b) More importantly, some of us (Jesse and myself) don't run Eclipse, and thus have no way to execute the wizard whenever we generate new Glazed Lists builds. Reusing old manifests is error-prone since we may have changed our package structure arbitrarily since the previous build.

Ultimately, it is our ANT and Maven build processes that need to produce our entire set of deliverables. If those deliverables include glazedlists.jar files that contain eclipse-plugin metadata, that's fine, but that data needs to be assembled by our ANT and Maven build processes each and every time any of us creates jars.

James

On 8/25/06, Bruce Alspaugh <[hidden email]> wrote:
I don't think we need to reshuffle the .jar beyond adding additional
entries to the manifest.mf file.  I'm fine with your suggested
Bundle-Name change.

Eclipse may have an ANT task to do it, but I used an easier way.  The
Eclipse import wizard allows you to import any .jar file into your
workspace as an Eclipse plug-in.  It automatically generates a
manifest.mf file that includes the Export-Package entry to get you
started.  In order to use the .jar as a plug-in, I had to manually
specify some additional information.  When you open the manifest.mf file
in an editor, it gives you multiple tabs.  The last tab lets you edit
the file manually, but I didn't need to.  The Overview tab lets you type
in the plug-in ID, version and plug-in name which is what I used.  The
Dependencies tab let me specify the bundles that the library depends
on:  org.eclipse.swt and org.eclipse.jface.

Bruce

James Lemieux wrote:

> Oh, one other tiny thing. I'd make it:
>
> Bundle-Name: Glazed Lists Plug-in
>
> instead of
>
> Bundle-Name: Glazedlists Plug-in
>
>
> to be more consistent with the Implementation-Title entry, and the
> true name of the project.
>
> James
>
> On 8/25/06, *James Lemieux* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Bruce,
>
>        If there is nothing else about glazedlists.jar that needs to
>     change, and only the manifest file needs extra entries, then I'm
>     completely on board with adding them in and making it easier for
>     use as an Eclipse plug-in. If the contents of the jar would need
>     shuffling, it could be a harder sell, but that doesn't appear to
>     be the case.
>
>        Since the format of the manifest entries is well-known for
>     eclipse plugins, I'd hope that there is an optional ANT task that
>     could generate them. Any idea if that exists and could ease the
>     implementation burdens? Ideally, it would do things like
>     automatically create the Export-Package entry given a patternset.
>
>        Failing the above, we can add more lines to the "jar" task of
>     our build.xml file and try to manhandle the data in, but I'd
>     really like it if the Export-Package entry was generated and not
>     hard-coded (and thus maintained).
>
>        So in short, sounds good dude!
>
>     James
>
>     On 8/25/06, *Bruce Alspaugh* < [hidden email]
>     <mailto:[hidden email]> > wrote:
>     Would it be possible to package the GlazedLists .jar distribution
>     as an
>     Eclipse bundle? It would make it a bit easier for Eclipse plug-in
>     developers to integrate the code library with their other
>     plug-ins.  It
>     would also simplify loading sort images directly from the .jar
>     distribution.  I could assign a plug-in id to GlazedLists, and
>     load the
>     images relative to it.
>
>     Basically, I need some additional entries in the MANIFEST.MF file
>     in the
>     distribution .jar.  The entries specify things like the plug-in id
>     (called the "Bundle-SymbolicName" in the file), required dependencies
>     (org.eclipse.swt and org.eclipse.jface), the list of packages exported
>     by Glazed Lists, and version information.  I have attached a
>     MANIFEST.MF
>     file that shows the entries I need.
>
>     I see that you are in the process of making a new .jar for 1.7.1.
>     Could
>     you include these entries?
>
>     Bruce
>
>
>     Manifest-Version: 1.0
>     Bundle-ManifestVersion: 2

>     Bundle-Name: Glazedlists Plug-in
>     Bundle-SymbolicName: ca.odell.glazedlists
>     Bundle-Version: 1.7.0
>     Bundle-ClassPath: .
>     Bundle-Localization: plugin
>     Export-Package: ca.odell.glazedlists,
>     ca.odell.glazedlists.event,
>     ca.odell.glazedlists.gui,
>     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.filter ,
>     ca.odell.glazedlists.impl.gui ,
>     ca.odell.glazedlists.impl.io <http://ca.odell.glazedlists.impl.io >,
>     ca.odell.glazedlists.impl.java15,
>     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.io < http://ca.odell.glazedlists.io>,
>     ca.odell.glazedlists.jfreechart,
>     ca.odell.glazedlists.matchers,
>     ca.odell.glazedlists.migrationkit,
>     ca.odell.glazedlists.migrationkit.swing ,
>     ca.odell.glazedlists.migrationkit.swt,
>     ca.odell.glazedlists.nachocalendar ,
>     ca.odell.glazedlists.swing,
>     ca.odell.glazedlists.swt,
>     ca.odell.glazedlists.util.concurrent ,
>     resources.aqua,
>     resources.metal,
>     resources.ocean,
>     resources.windows,
>     resources.windowsxp
>     Require-Bundle: org.eclipse.swt,
>     org.eclipse.jface
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
I'm not an ANT expert, but it's possible the wizard I mentioned is built
on an ANT script.  If I can locate it, can you merge that script into
the one you use?

Bruce

James Lemieux wrote:

> Bruce,
>
>    Using the wizard in Eclipse isn't a robust solution because:
>
> a) Glazed Lists already generates a manifest.mf of its own with our
> own special entries. So we're looking to add the eclipse plugin
> manifest entries to what we already define (see the jar target in
> Glazed List's build.xml for the manifest we're building today) We
> actually use those values in a Main class that we ship so that double
> clicking the glazedlists.jar (on most platforms) displays version
> information, as a convenience.
>
> b) More importantly, some of us (Jesse and myself) don't run Eclipse,
> and thus have no way to execute the wizard whenever we generate new
> Glazed Lists builds. Reusing old manifests is error-prone since we may
> have changed our package structure arbitrarily since the previous build.
>
> Ultimately, it is our ANT and Maven build processes that need to
> produce our entire set of deliverables. If those deliverables include
> glazedlists.jar files that contain eclipse-plugin metadata, that's
> fine, but that data needs to be assembled by our ANT and Maven build
> processes each and every time any of us creates jars.
>
> James
>
> On 8/25/06, *Bruce Alspaugh* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I don't think we need to reshuffle the .jar beyond adding additional
>     entries to the manifest.mf file.  I'm fine with your suggested
>     Bundle-Name change.
>
>     Eclipse may have an ANT task to do it, but I used an easier way.  The
>     Eclipse import wizard allows you to import any .jar file into your
>     workspace as an Eclipse plug-in.  It automatically generates a
>     manifest.mf file that includes the Export-Package entry to get you
>     started.  In order to use the .jar as a plug-in, I had to manually
>     specify some additional information.  When you open the
>     manifest.mf file
>     in an editor, it gives you multiple tabs.  The last tab lets you edit
>     the file manually, but I didn't need to.  The Overview tab lets
>     you type
>     in the plug-in ID, version and plug-in name which is what I used.  The
>     Dependencies tab let me specify the bundles that the library depends
>     on:  org.eclipse.swt and org.eclipse.jface.
>
>     Bruce
>
>     James Lemieux wrote:
>     > Oh, one other tiny thing. I'd make it:
>     >
>     > Bundle-Name: Glazed Lists Plug-in
>     >
>     > instead of
>     >
>     > Bundle-Name: Glazedlists Plug-in
>     >
>     >
>     > to be more consistent with the Implementation-Title entry, and the
>     > true name of the project.
>     >
>     > James
>     >
>     > On 8/25/06, *James Lemieux* <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto: [hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     Bruce,
>     >
>     >        If there is nothing else about glazedlists.jar that needs to
>     >     change, and only the manifest file needs extra entries, then
>     I'm
>     >     completely on board with adding them in and making it easier for
>     >     use as an Eclipse plug-in. If the contents of the jar would need
>     >     shuffling, it could be a harder sell, but that doesn't
>     appear to
>     >     be the case.
>     >
>     >        Since the format of the manifest entries is well-known for
>     >     eclipse plugins, I'd hope that there is an optional ANT task
>     that
>     >     could generate them. Any idea if that exists and could ease the
>     >     implementation burdens? Ideally, it would do things like
>     >     automatically create the Export-Package entry given a
>     patternset.
>     >
>     >        Failing the above, we can add more lines to the "jar"
>     task of
>     >     our build.xml file and try to manhandle the data in, but I'd
>     >     really like it if the Export-Package entry was generated and not
>     >     hard-coded (and thus maintained).
>     >
>     >        So in short, sounds good dude!
>     >
>     >     James
>     >
>     >     On 8/25/06, *Bruce Alspaugh* < [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>> > wrote:
>     >     Would it be possible to package the GlazedLists .jar
>     distribution
>     >     as an
>     >     Eclipse bundle? It would make it a bit easier for Eclipse
>     plug-in
>     >     developers to integrate the code library with their other
>     >     plug-ins.  It
>     >     would also simplify loading sort images directly from the .jar
>     >     distribution.  I could assign a plug-in id to GlazedLists, and
>     >     load the
>     >     images relative to it.
>     >
>     >     Basically, I need some additional entries in the MANIFEST.MF
>     file
>     >     in the
>     >     distribution .jar.  The entries specify things like the
>     plug-in id
>     >     (called the "Bundle-SymbolicName" in the file), required
>     dependencies
>     >     (org.eclipse.swt and org.eclipse.jface), the list of
>     packages exported
>     >     by Glazed Lists, and version information.  I have attached a
>     >     MANIFEST.MF
>     >     file that shows the entries I need.
>     >
>     >     I see that you are in the process of making a new .jar for
>     1.7.1.
>     >     Could
>     >     you include these entries?
>     >
>     >     Bruce
>     >
>     >
>     >     Manifest-Version: 1.0
>     >     Bundle-ManifestVersion: 2
>     >     Bundle-Name: Glazedlists Plug-in
>     >     Bundle-SymbolicName: ca.odell.glazedlists
>     >     Bundle-Version: 1.7.0
>     >     Bundle-ClassPath: .
>     >     Bundle-Localization: plugin
>     >     Export-Package: ca.odell.glazedlists,
>     >     ca.odell.glazedlists.event,
>     >     ca.odell.glazedlists.gui,
>     >     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.filter ,
>     >     ca.odell.glazedlists.impl.gui ,
>     >     ca.odell.glazedlists.impl.io
>     <http://ca.odell.glazedlists.impl.io>
>     <http://ca.odell.glazedlists.impl.io
>     <http://ca.odell.glazedlists.impl.io>>,
>     >     ca.odell.glazedlists.impl.java15,
>     >     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.io <http://ca.odell.glazedlists.io> <
>     http://ca.odell.glazedlists.io>,
>     >     ca.odell.glazedlists.jfreechart,
>     >     ca.odell.glazedlists.matchers,
>     >     ca.odell.glazedlists.migrationkit,
>     >     ca.odell.glazedlists.migrationkit.swing ,
>     >     ca.odell.glazedlists.migrationkit.swt,
>     >     ca.odell.glazedlists.nachocalendar ,
>     >     ca.odell.glazedlists.swing,
>     >     ca.odell.glazedlists.swt,
>     >     ca.odell.glazedlists.util.concurrent ,
>     >     resources.aqua,
>     >     resources.metal,
>     >     resources.ocean,
>     >     resources.windows,
>     >     resources.windowsxp
>     >     Require-Bundle: org.eclipse.swt,
>     >     org.eclipse.jface
>     >
>     >
>     >
>     >    
>     ---------------------------------------------------------------------
>     >     To unsubscribe, e-mail:
>     [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     For additional commands, e-mail:
>     [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

James Lemieux
Bruce,

   I found this from a powerpoint presentation on IBM's developerworks site:

- Manual publishing makes use of Ant scripts

followed closely by:

- Automatic publishing is available by using Eclipse wizards  


So it does look like using ANT is possible...

What is the relationship between the manifest.mf file and plugin.xml? Is the XML file just a newer way to indicate the metadata about your plugin? Maybe it would be easier to use that...?

James

On 8/25/06, Bruce Alspaugh <[hidden email]> wrote:
I'm not an ANT expert, but it's possible the wizard I mentioned is built
on an ANT script.  If I can locate it, can you merge that script into
the one you use?

Bruce

James Lemieux wrote:
> Bruce,
>
>    Using the wizard in Eclipse isn't a robust solution because:
>
> a) Glazed Lists already generates a manifest.mf of its own with our
> own special entries. So we're looking to add the eclipse plugin
> manifest entries to what we already define (see the jar target in
> Glazed List's build.xml for the manifest we're building today) We
> actually use those values in a Main class that we ship so that double

> clicking the glazedlists.jar (on most platforms) displays version
> information, as a convenience.
>
> b) More importantly, some of us (Jesse and myself) don't run Eclipse,
> and thus have no way to execute the wizard whenever we generate new
> Glazed Lists builds. Reusing old manifests is error-prone since we may
> have changed our package structure arbitrarily since the previous build.
>
> Ultimately, it is our ANT and Maven build processes that need to
> produce our entire set of deliverables. If those deliverables include
> glazedlists.jar files that contain eclipse-plugin metadata, that's
> fine, but that data needs to be assembled by our ANT and Maven build
> processes each and every time any of us creates jars.
>
> James
>
> On 8/25/06, *Bruce Alspaugh* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I don't think we need to reshuffle the .jar beyond adding additional
>     entries to the manifest.mf file.  I'm fine with your suggested
>     Bundle-Name change.
>
>     Eclipse may have an ANT task to do it, but I used an easier way.  The
>     Eclipse import wizard allows you to import any .jar file into your
>     workspace as an Eclipse plug-in.  It automatically generates a
>     manifest.mf file that includes the Export-Package entry to get you
>     started.  In order to use the .jar as a plug-in, I had to manually
>     specify some additional information.  When you open the
>     manifest.mf file
>     in an editor, it gives you multiple tabs.  The last tab lets you edit
>     the file manually, but I didn't need to.  The Overview tab lets
>     you type
>     in the plug-in ID, version and plug-in name which is what I used.  The
>     Dependencies tab let me specify the bundles that the library depends
>     on:  org.eclipse.swt and org.eclipse.jface.
>
>     Bruce
>
>     James Lemieux wrote:
>     > Oh, one other tiny thing. I'd make it:
>     >
>     > Bundle-Name: Glazed Lists Plug-in
>     >
>     > instead of
>     >
>     > Bundle-Name: Glazedlists Plug-in
>     >
>     >
>     > to be more consistent with the Implementation-Title entry, and the
>     > true name of the project.
>     >
>     > James
>     >
>     > On 8/25/06, *James Lemieux* <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto: [hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     Bruce,
>     >
>     >        If there is nothing else about glazedlists.jar that needs to
>     >     change, and only the manifest file needs extra entries, then
>     I'm
>     >     completely on board with adding them in and making it easier for
>     >     use as an Eclipse plug-in. If the contents of the jar would need
>     >     shuffling, it could be a harder sell, but that doesn't
>     appear to
>     >     be the case.
>     >
>     >        Since the format of the manifest entries is well-known for
>     >     eclipse plugins, I'd hope that there is an optional ANT task
>     that
>     >     could generate them. Any idea if that exists and could ease the
>     >     implementation burdens? Ideally, it would do things like
>     >     automatically create the Export-Package entry given a
>     patternset.
>     >
>     >        Failing the above, we can add more lines to the "jar"
>     task of
>     >     our build.xml file and try to manhandle the data in, but I'd
>     >     really like it if the Export-Package entry was generated and not
>     >     hard-coded (and thus maintained).
>     >
>     >        So in short, sounds good dude!
>     >
>     >     James
>     >
>     >     On 8/25/06, *Bruce Alspaugh* < [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto: [hidden email]>> > wrote:
>     >     Would it be possible to package the GlazedLists .jar
>     distribution
>     >     as an
>     >     Eclipse bundle? It would make it a bit easier for Eclipse
>     plug-in
>     >     developers to integrate the code library with their other
>     >     plug-ins.  It
>     >     would also simplify loading sort images directly from the .jar
>     >     distribution.  I could assign a plug-in id to GlazedLists, and
>     >     load the
>     >     images relative to it.
>     >
>     >     Basically, I need some additional entries in the MANIFEST.MF
>     file
>     >     in the
>     >     distribution .jar.  The entries specify things like the

>     plug-in id
>     >     (called the "Bundle-SymbolicName" in the file), required
>     dependencies
>     >     ( org.eclipse.swt and org.eclipse.jface), the list of
>     packages exported
>     >     by Glazed Lists, and version information.  I have attached a
>     >     MANIFEST.MF
>     >     file that shows the entries I need.
>     >
>     >     I see that you are in the process of making a new .jar for
>     1.7.1.
>     >     Could
>     >     you include these entries?
>     >
>     >     Bruce
>     >
>     >
>     >     Manifest-Version: 1.0
>     >     Bundle-ManifestVersion: 2
>     >     Bundle-Name: Glazedlists Plug-in
>     >     Bundle-SymbolicName: ca.odell.glazedlists
>     >     Bundle-Version: 1.7.0
>     >     Bundle-ClassPath: .
>     >     Bundle-Localization: plugin
>     >     Export-Package: ca.odell.glazedlists,
>     >     ca.odell.glazedlists.event,
>     >     ca.odell.glazedlists.gui,
>     >     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.filter ,
>     >     ca.odell.glazedlists.impl.gui ,
>     >     <a href="http://ca.odell.glazedlists.impl.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ca.odell.glazedlists.impl.io
>     <<a href="http://ca.odell.glazedlists.impl.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ca.odell.glazedlists.impl.io >
>     <<a href="http://ca.odell.glazedlists.impl.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ca.odell.glazedlists.impl.io
>     <<a href="http://ca.odell.glazedlists.impl.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://ca.odell.glazedlists.impl.io>>,
>     >     ca.odell.glazedlists.impl.java15,
>     >     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,
>     >     <a href="http://ca.odell.glazedlists.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">ca.odell.glazedlists.io <<a href="http://ca.odell.glazedlists.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> http://ca.odell.glazedlists.io> <
>     <a href="http://ca.odell.glazedlists.io" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://ca.odell.glazedlists.io >,
>     >     ca.odell.glazedlists.jfreechart,
>     >     ca.odell.glazedlists.matchers,
>     >     ca.odell.glazedlists.migrationkit,
>     >     ca.odell.glazedlists.migrationkit.swing ,
>     >     ca.odell.glazedlists.migrationkit.swt,
>     >     ca.odell.glazedlists.nachocalendar ,
>     >     ca.odell.glazedlists.swing,
>     >     ca.odell.glazedlists.swt,
>     >     ca.odell.glazedlists.util.concurrent ,

>     >     resources.aqua,
>     >     resources.metal,
>     >     resources.ocean,
>     >     resources.windows,
>     >     resources.windowsxp
>     >     Require-Bundle: org.eclipse.swt,
>     >     org.eclipse.jface
>     >
>     >
>     >
>     >
>     ---------------------------------------------------------------------
>     >     To unsubscribe, e-mail:
>     [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     For additional commands, e-mail:
>     [hidden email]
>     <mailto: [hidden email]>
>     >     <mailto:[hidden email]
>     <mailto: [hidden email]>>
>     >
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto: [hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
At some point we might need a plugin.xml file, but the metadata it
contains is very different from what is in the manifest file.  The
plugin.xml file defines the extensions and extension point contributions
for your plug-in.  At this stage, I don't think we need to contribute
any extension points.  My manual suggests that most bundled code
libraries don't.  My main plugin that uses Glazes Lists does have a
plugin.xml file, but that is so it can contribute views, editors,
perspectives, etc. to the RCP shell.  So for now, I don't think we need
a plugin.xml file.

On the other hand, the Eclipse guys strongly insist that you export
every package in your manifest.  See:
http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg07550.html

I gather the tough scripting part is to automatically identify all the
packages in Glazed Lists so we don't accidentally miss any in the build
process.  I have a question out on the Eclipse forums asking if anyone
has an ANT script to generate the Export-Package entries in the
manifest.mf file.  The other entries look to be simple name-value
pairs.  Would it be possible to have a post-build script that takes the
normal .jar file as input and updates the manifest.mf file with one that
has all the packages listed?

http://mail-archives.apache.org/mod_mbox/maven-users/200306.mbox/%3C3EE4AE01.4070408@...%3E

Bruce

The plugin.xml file hWould it be possible to create a post-build ANT
script that takes your normal .jar as input and replaces the manifest.mf
file with one that has all the packages listed?

I noticed the Eclipse guys


James Lemieux wrote:

> Bruce,
>
>    I found this from a powerpoint presentation on IBM's developerworks
> site:
>
> - Manual publishing makes use of Ant scripts
>
> followed closely by:
>
> - Automatic publishing is available by using Eclipse wizards  
>
>
> So it does look like using ANT is possible...
>
> What is the relationship between the manifest.mf file and plugin.xml?
> Is the XML file just a newer way to indicate the metadata about your
> plugin? Maybe it would be easier to use that...?
>
> James
>
> On 8/25/06, *Bruce Alspaugh* < [hidden email]
> <mailto:[hidden email]>> wrote:
>
>     I'm not an ANT expert, but it's possible the wizard I mentioned is
>     built
>     on an ANT script.  If I can locate it, can you merge that script into
>     the one you use?
>
>     Bruce
>
>     James Lemieux wrote:
>     > Bruce,
>     >
>     >    Using the wizard in Eclipse isn't a robust solution because:
>     >
>     > a) Glazed Lists already generates a manifest.mf of its own with our
>     > own special entries. So we're looking to add the eclipse plugin
>     > manifest entries to what we already define (see the jar target in
>     > Glazed List's build.xml for the manifest we're building today) We
>     > actually use those values in a Main class that we ship so that
>     double
>     > clicking the glazedlists.jar (on most platforms) displays version
>     > information, as a convenience.
>     >
>     > b) More importantly, some of us (Jesse and myself) don't run
>     Eclipse,
>     > and thus have no way to execute the wizard whenever we generate new
>     > Glazed Lists builds. Reusing old manifests is error-prone since
>     we may
>     > have changed our package structure arbitrarily since the
>     previous build.
>     >
>     > Ultimately, it is our ANT and Maven build processes that need to
>     > produce our entire set of deliverables. If those deliverables
>     include
>     > glazedlists.jar files that contain eclipse-plugin metadata, that's
>     > fine, but that data needs to be assembled by our ANT and Maven build
>     > processes each and every time any of us creates jars.
>     >
>     > James
>     >
>     > On 8/25/06, *Bruce Alspaugh* < [hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>>
>     wrote:
>     >
>     >     I don't think we need to reshuffle the .jar beyond adding
>     additional
>     >     entries to the manifest.mf file.  I'm fine with your suggested
>     >     Bundle-Name change.
>     >
>     >     Eclipse may have an ANT task to do it, but I used an easier
>     way.  The
>     >     Eclipse import wizard allows you to import any .jar file
>     into your
>     >     workspace as an Eclipse plug-in.  It automatically generates a
>     >     manifest.mf file that includes the Export-Package entry to
>     get you
>     >     started.  In order to use the .jar as a plug-in, I had to
>     manually
>     >     specify some additional information.  When you open the
>     >     manifest.mf file
>     >     in an editor, it gives you multiple tabs.  The last tab lets
>     you edit
>     >     the file manually, but I didn't need to.  The Overview tab lets
>     >     you type
>     >     in the plug-in ID, version and plug-in name which is what I
>     used.  The
>     >     Dependencies tab let me specify the bundles that the library
>     depends
>     >     on:  org.eclipse.swt and org.eclipse.jface.
>     >
>     >     Bruce
>     >
>     >     James Lemieux wrote:
>     >     > Oh, one other tiny thing. I'd make it:
>     >     >
>     >     > Bundle-Name: Glazed Lists Plug-in
>     >     >
>     >     > instead of
>     >     >
>     >     > Bundle-Name: Glazedlists Plug-in
>     >     >
>     >     >
>     >     > to be more consistent with the Implementation-Title entry,
>     and the
>     >     > true name of the project.
>     >     >
>     >     > James
>     >     >
>     >     > On 8/25/06, *James Lemieux* <[hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email] <mailto:[hidden email]>>
>     >     > <mailto: [hidden email] <mailto:[hidden email]>
>     <mailto: [hidden email] <mailto:[hidden email]>>>> wrote:
>     >     >
>     >     >     Bruce,
>     >     >
>     >     >        If there is nothing else about glazedlists.jar that
>     needs to
>     >     >     change, and only the manifest file needs extra
>     entries, then
>     >     I'm
>     >     >     completely on board with adding them in and making it
>     easier for
>     >     >     use as an Eclipse plug-in. If the contents of the jar
>     would need
>     >     >     shuffling, it could be a harder sell, but that doesn't
>     >     appear to
>     >     >     be the case.
>     >     >
>     >     >        Since the format of the manifest entries is
>     well-known for
>     >     >     eclipse plugins, I'd hope that there is an optional
>     ANT task
>     >     that
>     >     >     could generate them. Any idea if that exists and could
>     ease the
>     >     >     implementation burdens? Ideally, it would do things like
>     >     >     automatically create the Export-Package entry given a
>     >     patternset.
>     >     >
>     >     >        Failing the above, we can add more lines to the "jar"
>     >     task of
>     >     >     our build.xml file and try to manhandle the data in,
>     but I'd
>     >     >     really like it if the Export-Package entry was
>     generated and not
>     >     >     hard-coded (and thus maintained).
>     >     >
>     >     >        So in short, sounds good dude!
>     >     >
>     >     >     James
>     >     >
>     >     >     On 8/25/06, *Bruce Alspaugh* < [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email] <mailto:[hidden email]>>
>     >     >     <mailto:[hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email]
>     <mailto:[hidden email]>>> > wrote:
>     >     >     Would it be possible to package the GlazedLists .jar
>     >     distribution
>     >     >     as an
>     >     >     Eclipse bundle? It would make it a bit easier for Eclipse
>     >     plug-in
>     >     >     developers to integrate the code library with their other
>     >     >     plug-ins.  It
>     >     >     would also simplify loading sort images directly from
>     the .jar
>     >     >     distribution.  I could assign a plug-in id to
>     GlazedLists, and
>     >     >     load the
>     >     >     images relative to it.
>     >     >
>     >     >     Basically, I need some additional entries in the
>     MANIFEST.MF
>     >     file
>     >     >     in the
>     >     >     distribution .jar.  The entries specify things like the
>     >     plug-in id
>     >     >     (called the "Bundle-SymbolicName" in the file), required
>     >     dependencies
>     >     >     ( org.eclipse.swt and org.eclipse.jface), the list of
>     >     packages exported
>     >     >     by Glazed Lists, and version information.  I have
>     attached a
>     >     >     MANIFEST.MF
>     >     >     file that shows the entries I need.
>     >     >
>     >     >     I see that you are in the process of making a new .jar for
>     >     1.7.1.
>     >     >     Could
>     >     >     you include these entries?
>     >     >
>     >     >     Bruce
>     >     >
>     >     >
>     >     >     Manifest-Version: 1.0
>     >     >     Bundle-ManifestVersion: 2
>     >     >     Bundle-Name: Glazedlists Plug-in
>     >     >     Bundle-SymbolicName: ca.odell.glazedlists
>     >     >     Bundle-Version: 1.7.0
>     >     >     Bundle-ClassPath: .
>     >     >     Bundle-Localization: plugin
>     >     >     Export-Package: ca.odell.glazedlists,
>     >     >     ca.odell.glazedlists.event,
>     >     >     ca.odell.glazedlists.gui,
>     >     >     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.filter ,
>     >     >     ca.odell.glazedlists.impl.gui ,
>     >     >     ca.odell.glazedlists.impl.io
>     <http://ca.odell.glazedlists.impl.io>
>     >     <http://ca.odell.glazedlists.impl.io
>     <http://ca.odell.glazedlists.impl.io>>
>     >     <http://ca.odell.glazedlists.impl.io
>     >     < http://ca.odell.glazedlists.impl.io>>,
>     >     >     ca.odell.glazedlists.impl.java15,
>     >     >     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.io
>     <http://ca.odell.glazedlists.io> < http://ca.odell.glazedlists.io> <
>     >     http://ca.odell.glazedlists.io
>     <http://ca.odell.glazedlists.io>>,
>     >     >     ca.odell.glazedlists.jfreechart,
>     >     >     ca.odell.glazedlists.matchers,
>     >     >     ca.odell.glazedlists.migrationkit,
>     >     >     ca.odell.glazedlists.migrationkit.swing ,
>     >     >     ca.odell.glazedlists.migrationkit.swt,
>     >     >     ca.odell.glazedlists.nachocalendar ,
>     >     >     ca.odell.glazedlists.swing,
>     >     >     ca.odell.glazedlists.swt,
>     >     >     ca.odell.glazedlists.util.concurrent ,
>     >     >     resources.aqua,
>     >     >     resources.metal,
>     >     >     resources.ocean,
>     >     >     resources.windows,
>     >     >     resources.windowsxp
>     >     >     Require-Bundle: org.eclipse.swt,
>     >     >     org.eclipse.jface
>     >     >
>     >     >
>     >     >
>     >     >
>     >    
>     ---------------------------------------------------------------------
>     >     >     To unsubscribe, e-mail:
>     >     [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email]
>     <mailto:[hidden email]>>
>     >     >     <mailto:[hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email]
>     <mailto:[hidden email]>>>
>     >     >     For additional commands, e-mail:
>     >     [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email]
>     <mailto:[hidden email]>>
>     >     >     <mailto: [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email]
>     <mailto:[hidden email]>>>
>     >     >
>     >     >
>     >     >
>     >
>     >    
>     ---------------------------------------------------------------------
>     >     To unsubscribe, e-mail:
>     [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email]
>     <mailto:[hidden email]>>
>     >     For additional commands, e-mail:
>     [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto: [hidden email]
>     <mailto:[hidden email]>>
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Holger
In reply to this post by Bruce Alspaugh-2
Hey guys,

interesting discussion going on here...
 
> On the other hand, the Eclipse guys strongly insist that you export
> every package in your manifest.  See:
> http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg07550.html

My understanding is that this convention for the Export-Package option
is for the Eclipse SDK plugins only.
I think other plugins are free to only export 'public' packages that should be
available to other plugins.
So, our impl-packages should probably be excluded from the Export-Package
entry in my opinion, but I could be wrong...

>
> I gather the tough scripting part is to automatically identify all the
> packages in Glazed Lists so we don't accidentally miss any in the build
> process.  I have a question out on the Eclipse forums asking if anyone
> has an ANT script to generate the Export-Package entries in the
> manifest.mf file.  The other entries look to be simple name-value
> pairs.  Would it be possible to have a post-build script that takes the
> normal .jar file as input and updates the manifest.mf file with one that
> has all the packages listed?
>
> http://mail-archives.apache.org/mod_mbox/maven-users/200306.mbox/%3C3EE4AE01.4070408@...%3E

Actually we don't use Maven. We use Ant for our build process and produce
Maven upload bundles for deployment.
So, the static manifest entries would be easy to add to our Ant target.

So it comes down to the question how to produce the Export-Package value.

Holger

______________________________________________________________________
XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Packaging GlazedLists as a Bundle

Jesse Wilson
Hey guys ----

A few quick thoughts on this discussion...
 - I agree that we don't want to export the .impl package if
   we can get away with it.
 - Generating the package list within Ant is pretty straightforward.
   We don't need a tool, I can probably write some ant code to do it.

...and one question:
 - Could adding this extra metadata be annoying for people using
   Eclipse RCP with Glazed Lists imported in a different way?
   For example, if they're using it as a dependency for another
   plugin?

I've never used Eclipse RCP so I'm not very familiar with how that
stuff all works!

Cheers,
Jesse


On 8/26/06, Holger Brands <[hidden email]> wrote:

> Hey guys,
>
> interesting discussion going on here...
>
> > On the other hand, the Eclipse guys strongly insist that you export
> > every package in your manifest.  See:
> > http://dev.eclipse.org/mhonarc/lists/eclipse-dev/msg07550.html
>
> My understanding is that this convention for the Export-Package option
> is for the Eclipse SDK plugins only.
> I think other plugins are free to only export 'public' packages that should be
> available to other plugins.
> So, our impl-packages should probably be excluded from the Export-Package
> entry in my opinion, but I could be wrong...
>
> >
> > I gather the tough scripting part is to automatically identify all the
> > packages in Glazed Lists so we don't accidentally miss any in the build
> > process.  I have a question out on the Eclipse forums asking if anyone
> > has an ANT script to generate the Export-Package entries in the
> > manifest.mf file.  The other entries look to be simple name-value
> > pairs.  Would it be possible to have a post-build script that takes the
> > normal .jar file as input and updates the manifest.mf file with one that
> > has all the packages listed?
> >
> > http://mail-archives.apache.org/mod_mbox/maven-users/200306.mbox/%3C3EE4AE01.4070408@...%3E
>
> Actually we don't use Maven. We use Ant for our build process and produce
> Maven upload bundles for deployment.
> So, the static manifest entries would be easy to add to our Ant target.
>
> So it comes down to the question how to produce the Export-Package value.
>
> Holger
>
> ______________________________________________________________________
> XXL-Speicher, PC-Virenschutz, Spartarife & mehr: Nur im WEB.DE Club!
> Jetzt gratis testen! http://freemail.web.de/home/landingpad/?mc=021130
>
> ---------------------------------------------------------------------
> 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: Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
Hi Guys,

If you want a good intro to how Eclipse RCP applications fit together and how this whole plugin architecture works, I would highly recommend, "Eclipse Rich Client Platform:  Designing, Coding and Packaging Java Applications" by Jeff McAffer and Jean-Michel Lemieux.  It is a well writtten tutorial that walks you through the Eclipse IDE step-by-step to build a chat client application.  It is a quick read that should answer most of your questions.

On 8/26/06, Jesse Wilson <[hidden email]> wrote:
Hey guys ----

A few quick thoughts on this discussion...
- I agree that we don't want to export the .impl package if
   we can get away with it.

From experimenting with the Eclipse IDE, if plugin A does not export a package, plugin B that depends on A cannot import it.  In other words when I write an import statement in my java code for plugin B that tries to reference the non-exported package in A, Eclipse will not be able to resolve it.  I get a compile time error.  This might be why some plug-in authors don't want to export their non-api packages.  I think what Jeff McAffer was wanting people to do is to go ahead and export the package, but then use additional directives in the manifest to control access to it. 


- Generating the package list within Ant is pretty straightforward.
   We don't need a tool, I can probably write some ant code to do it.

Hey, that's great!  It's nice to have an Ant scripting expert here who can do it.

...and one question:
- Could adding this extra metadata be annoying for people using
   Eclipse RCP with Glazed Lists imported in a different way?
   For example, if they're using it as a dependency for another
   plugin?

I don't think so.  If you don't need the extra metadata, it should be ignored.  What the additional metadata allows you to do is to treat the distribution .jar file as an Eclipse plug-in without having to turn it into a plug-in by injecting the necessary metadata yourself using the wizard or by some other means.  Having the extra metadata is what allows you to use the .jar as a dependency of another plugin.  The export/dependency system is part of the mechanism that allows you to share resources across plugin boundaries.

If you don't want to cross a plug-in boundary, a plug-in author could just incorporate the .jar into the plug-in they are developing.  In that case the metadata would be unnecessary, but that defeats modularity.  Better to make Glazed Lists a plugin, and then multiple plug-ins that want to utilize Glazed Lists would simply depend on the Glazed List plug-in.  It would also make updating to a new version of Glazed Lists simpler, because there would only be one plug-in to update.  The update process can even be done after your application is deployed.  Eclipse has a sophisticated Update feature that RCP applications can leverage to allow the end-user to walk through a wizard to selectively download, update, and add additional plug-ins.  The plug-in binding process happens dynamically at runtime, so when they restart their application the new functionality will magically appear.

Bruce


Reply | Threaded
Open this post in threaded view
|

Re: Re: Packaging GlazedLists as a Bundle

James Lemieux
Bruce, et al,

   So, I spent today playing around with an ANT task from http://www.knopflerfish.org/ which helps projects create OSGi compliant "bundles"... otherwise known as "jar files with some meta information in the manifest file that Eclipse can work with". This is the task that Holger pointed us toward.

   I extracted the ANT task code from the larger jar it lives in and customized the code slightly for our case. Specifically, the assumption in the existing task is that you only want to expose packages that contain class files. In our case, we have resource directories that contain only image files (PNG files), so the modification I made knows how to include relative paths to PNG files FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an absolute file name to a PNG, it's impossible to tell what directory you want reported. Our implementation cuts off everything before the "resources" folder name.

   So, I've created a new entry in the Glazed Lists \tools directory called OSGi_bundleinfo here:

https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0


and when you run the ant task: "ant jar" for Glazed Lists, it downloads <a href="https://glazedlists.dev.java.net/files/documents/1073/39631/OSGiBundleInfo.jar" onclick="return launch(this.href, 1)"> OSGiBundleInfo.jar from that directory, creates an ANT task from it, and then executes that ANT task in order to get the value that should be used for the export-packages manifest entry. I made a half-hearted attempt to assemble the export-packages value using standard ant tasks, but it's an exercise in madness.

   So, Bruce, can I get you to test out the latest jars from CVS to see if they comply with Eclipse's expectation. At the moment, the generated manifest looks like this (i.e. no newline chars anywhere within manifest entries... only between them):

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
Main-Class: ca.odell.glazedlists.impl.Main
Sealed: true
Built-By: James Lemieux
Built-At: 2006-08-27 21:52
Implementation-Version: 2006-08-27 21:52
Implementation-Title: Glazed Lists
Implementation-URL: http://publicobject.com/glazedlists/
Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob Eden, Hol
 ger Brands
Source-Version: JDK 1.5
Bundle-ManifestVersion: 2
Bundle-Name: Glazed Lists Plug-in
Bundle-SymbolicName: ca.odell.glazedlists
Bundle-Version: ${version}
Bundle-ClassPath: .
Bundle-Localization: plugin
Export-Package: ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
 ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
 s.io,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers ,ca
 .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
 ng,ca.odell.glazedlists.migrationkit.swt,ca.odell.glazedlists.nachoca
 lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
 lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
 cean,resources.windows,resources.windowsxp
Require-Bundle: org.eclipse.swt,org.eclipse.jface



In other news, I stumbled into making my "ant upload" target work tonight! It began earlier in the day when Holger mentioned that his ANT installation did not have bcel.jar in its lib directory, while mine did. I saw that I had copied it there when playing around with Java Net Tasks. So, I deleted all jars from my ANT installation's \lib directory and copied the default jars in there once more, and voila. the next time I ran "ant upload" it actually uploaded the jars. So, Jesse, if that task is broken for you as well, check your \lib directory for stray jars.

James




On 8/26/06, Bruce Alspaugh <[hidden email]> wrote:
Hi Guys,

If you want a good intro to how Eclipse RCP applications fit together and how this whole plugin architecture works, I would highly recommend, "Eclipse Rich Client Platform:  Designing, Coding and Packaging Java Applications" by Jeff McAffer and Jean-Michel Lemieux.  It is a well writtten tutorial that walks you through the Eclipse IDE step-by-step to build a chat client application.  It is a quick read that should answer most of your questions.

On 8/26/06, Jesse Wilson <[hidden email]> wrote:
Hey guys ----

A few quick thoughts on this discussion...
- I agree that we don't want to export the .impl package if
   we can get away with it.

From experimenting with the Eclipse IDE, if plugin A does not export a package, plugin B that depends on A cannot import it.  In other words when I write an import statement in my java code for plugin B that tries to reference the non-exported package in A, Eclipse will not be able to resolve it.  I get a compile time error.  This might be why some plug-in authors don't want to export their non-api packages.  I think what Jeff McAffer was wanting people to do is to go ahead and export the package, but then use additional directives in the manifest to control access to it. 


- Generating the package list within Ant is pretty straightforward.
   We don't need a tool, I can probably write some ant code to do it.

Hey, that's great!  It's nice to have an Ant scripting expert here who can do it.

...and one question:
- Could adding this extra metadata be annoying for people using
   Eclipse RCP with Glazed Lists imported in a different way?
   For example, if they're using it as a dependency for another
   plugin?

I don't think so.  If you don't need the extra metadata, it should be ignored.  What the additional metadata allows you to do is to treat the distribution .jar file as an Eclipse plug-in without having to turn it into a plug-in by injecting the necessary metadata yourself using the wizard or by some other means.  Having the extra metadata is what allows you to use the .jar as a dependency of another plugin.  The export/dependency system is part of the mechanism that allows you to share resources across plugin boundaries.

If you don't want to cross a plug-in boundary, a plug-in author could just incorporate the .jar into the plug-in they are developing.  In that case the metadata would be unnecessary, but that defeats modularity.  Better to make Glazed Lists a plugin, and then multiple plug-ins that want to utilize Glazed Lists would simply depend on the Glazed List plug-in.  It would also make updating to a new version of Glazed Lists simpler, because there would only be one plug-in to update.  The update process can even be done after your application is deployed.  Eclipse has a sophisticated Update feature that RCP applications can leverage to allow the end-user to walk through a wizard to selectively download, update, and add additional plug-ins.  The plug-in binding process happens dynamically at runtime, so when they restart their application the new functionality will magically appear.

Bruce



Reply | Threaded
Open this post in threaded view
|

Re: Re: Packaging GlazedLists as a Bundle

Holger
In reply to this post by Bruce Alspaugh-2
Nice work, James.

Is there some useful value for the
'Bundle-Version' property when we do a
latest build or does this only make sense for
'official' releases?

Regarding the BCEL library:

We should keep in mind that our demojar target also depends
on BCEL, because it uses the <classfileset> optional type.

Actually, I have the BCEL library in my Ant lib directory
because of the demojar and the 'upload' target works even so.
So probably there were some other jars in your lib directory
confusing the javanettasks?!
So, to run the demojar target you still need BCEL in the Ant lib dir.

Holger

>Bruce, et al,
>
>    So, I spent today playing around with an ANT task from http://www.knopflerfish.org/ which helps projects create OSGi compliant "bundles"... otherwise known as "jar files with some meta information in the manifest file that Eclipse can work with". This is the task that Holger pointed us toward.
>
>
>    I extracted the ANT task code from the larger jar it lives in and customized the code slightly for our case. Specifically, the assumption in the existing task is that you only want to expose packages that contain class files. In our case, we have resource directories that contain only image files (PNG files), so the modification I made knows how to include relative paths to PNG files FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an absolute file name to a PNG, it's impossible to tell what directory you want reported. Our implementation cuts off everything before the "resources" folder name.
>
>
>    So, I've created a new entry in the Glazed Lists \tools directory called OSGi_bundleinfo here:
>
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
>
> and when you run the ant task: "ant jar" for Glazed Lists, it downloads
>  OSGiBundleInfo.jar from that directory, creates an ANT task from it, and then executes that ANT task in order to get the value that should be used for the export-packages manifest entry. I made a half-hearted attempt to assemble the export-packages value using standard ant tasks, but it's an exercise in madness.
>
>
>    So, Bruce, can I get you to test out the latest jars from CVS to see if they comply with Eclipse's expectation. At the moment, the generated manifest looks like this (i.e. no newline chars anywhere within manifest entries... only between them):
>
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
> Main-Class: ca.odell.glazedlists.impl.Main
> Sealed: true
> Built-By: James Lemieux
> Built-At: 2006-08-27 21:52
>
> Implementation-Version: 2006-08-27 21:52
> Implementation-Title: Glazed Lists
> Implementation-URL: http://publicobject.com/glazedlists/
> Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob Eden, Hol
>
>  ger Brands
> Source-Version: JDK 1.5
> Bundle-ManifestVersion: 2
> Bundle-Name: Glazed Lists Plug-in
> Bundle-SymbolicName: ca.odell.glazedlists
> Bundle-Version: ${version}
> Bundle-ClassPath: .
> Bundle-Localization: plugin
>
> Export-Package: ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
>  ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
>  s.io,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers
> ,ca
>  .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
>  ng,ca.odell.glazedlists.migrationkit.swt,ca.odell.glazedlists.nachoca
>  lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
>
>  lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
>  cean,resources.windows,resources.windowsxp
> Require-Bundle: org.eclipse.swt,org.eclipse.jface
>
>
>
> In other news, I stumbled into making my "ant upload" target work tonight! It began earlier in the day when Holger mentioned that his ANT installation did not have bcel.jar in its lib directory, while mine did. I saw that I had copied it there when playing around with Java Net Tasks. So, I deleted all jars from my ANT installation's \lib directory and copied the default jars in there once more, and voila. the next time I ran "ant upload" it actually uploaded the jars. So, Jesse, if that task is broken for you as well, check your \lib directory for stray jars.
>
>
> James
>
>
>
>
>
> On 8/26/06, Bruce Alspaugh <[hidden email]> wrote:
>
> Hi Guys,
>
> If you want a good intro to how Eclipse RCP applications fit together and how this whole plugin architecture works, I would highly recommend, "Eclipse Rich Client Platform:  Designing, Coding and Packaging Java Applications" by Jeff McAffer and Jean-Michel Lemieux.  It is a well writtten tutorial that walks you through the Eclipse IDE step-by-step to build a chat client application.  It is a quick read that should answer most of your questions.
>
>
>
>
> On 8/26/06, Jesse Wilson <
> [hidden email]> wrote:
> Hey guys ----
>
> A few quick thoughts on this discussion...
>  - I agree that we don't want to export the .impl package if
>    we can get away with it.
>
>
> From experimenting with the Eclipse IDE, if plugin A does not export a package, plugin B that depends on A cannot import it.  In other words when I write an import statement in my java code for plugin B that tries to reference the non-exported package in A, Eclipse will not be able to resolve it.  I get a compile time error.  This might be why some plug-in authors don't want to export their non-api packages.  I think what Jeff McAffer was wanting people to do is to go ahead and export the package, but then use additional directives in the manifest to control access to it.  
>
>
>
>  - Generating the package list within Ant is pretty straightforward.
>
>    We don't need a tool, I can probably write some ant code to do it.
>
>
>
> Hey, that's great!  It's nice to have an Ant scripting expert here who can do it.
>
>
> ...and one question:
>  - Could adding this extra metadata be annoying for people using
>    Eclipse RCP with Glazed Lists imported in a different way?
>    For example, if they're using it as a dependency for another
>
>    plugin?
>
>
> I don't think so.  If you don't need the extra metadata, it should be ignored.  What the additional metadata allows you to do is to treat the distribution .jar file as an Eclipse plug-in without having to turn it into a plug-in by injecting the necessary metadata yourself using the wizard or by some other means.  Having the extra metadata is what allows you to use the .jar as a dependency of another plugin.  The export/dependency system is part of the mechanism that allows you to share resources across plugin boundaries.
>
>
> If you don't want to cross a plug-in boundary, a plug-in author could just incorporate the .jar into the plug-in they are developing.  In that case the metadata would be unnecessary, but that defeats modularity.  Better to make Glazed Lists a plugin, and then multiple plug-ins that want to utilize Glazed Lists would simply depend on the Glazed List plug-in.  It would also make updating to a new version of Glazed Lists simpler, because there would only be one plug-in to update.  The update process can even be done after your application is deployed.  Eclipse has a sophisticated Update feature that RCP applications can leverage to allow the end-user to walk through a wizard to selectively download, update, and add additional plug-ins.  The plug-in binding process happens dynamically at runtime, so when they restart their application the new functionality will magically appear.
>
>
> Bruce
>
>
>
>


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

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

Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
In reply to this post by James Lemieux
Hi James,

Thanks for working on this.

I downloaded glazedlists_java15.jar from the latest_build directory and
renamed it ca.odell.glazedlists_1.7.1.v20060827.jar to follow the file
naming convention for plugins.  Then I dropped it into the plugin
directory, and launched Eclipse.  When Eclipse started up, I got an
error, "Could not install bundle
plugins/ca.odell.glazedlists_1.7.1.v20060827.jar   For input string:
"${version}".

Can you take a look at the Bundle-Version tag in the manifest file?  It
needs an actual number like 1.7.1.

Bruce

James Lemieux wrote:

> Bruce, et al,
>
>    So, I spent today playing around with an ANT task from
> http://www.knopflerfish.org/ which helps projects create OSGi
> compliant "bundles"... otherwise known as "jar files with some meta
> information in the manifest file that Eclipse can work with". This is
> the task that Holger pointed us toward.
>
>    I extracted the ANT task code from the larger jar it lives in and
> customized the code slightly for our case. Specifically, the
> assumption in the existing task is that you only want to expose
> packages that contain class files. In our case, we have resource
> directories that contain only image files (PNG files), so the
> modification I made knows how to include relative paths to PNG files
> FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an
> absolute file name to a PNG, it's impossible to tell what directory
> you want reported. Our implementation cuts off everything before the
> "resources" folder name.
>
>    So, I've created a new entry in the Glazed Lists \tools directory
> called OSGi_bundleinfo here:
>
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0 
> <https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>
>
> and when you run the ant task: "ant jar" for Glazed Lists, it
> downloads OSGiBundleInfo.jar
> <https://glazedlists.dev.java.net/files/documents/1073/39631/OSGiBundleInfo.jar>
> from that directory, creates an ANT task from it, and then executes
> that ANT task in order to get the value that should be used for the
> export-packages manifest entry. I made a half-hearted attempt to
> assemble the export-packages value using standard ant tasks, but it's
> an exercise in madness.
>
>    So, Bruce, can I get you to test out the latest jars from CVS to
> see if they comply with Eclipse's expectation. At the moment, the
> generated manifest looks like this (i.e. no newline chars anywhere
> within manifest entries... only between them):
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
> Main-Class: ca.odell.glazedlists.impl.Main
> Sealed: true
> Built-By: James Lemieux
> Built-At: 2006-08-27 21:52
> Implementation-Version: 2006-08-27 21:52
> Implementation-Title: Glazed Lists
> Implementation-URL: http://publicobject.com/glazedlists/
> Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob Eden, Hol
>  ger Brands
> Source-Version: JDK 1.5
> Bundle-ManifestVersion: 2
> Bundle-Name: Glazed Lists Plug-in
> Bundle-SymbolicName: ca.odell.glazedlists
> Bundle-Version: ${version}
> Bundle-ClassPath: .
> Bundle-Localization: plugin
> Export-Package: ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
>  ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
>  s.io
> <http://s.io>,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers
> ,ca
>  .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
>  ng,ca.odell.glazedlists.migrationkit.swt,ca.odell.glazedlists.nachoca
>  lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
>  lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
>  cean,resources.windows,resources.windowsxp
> Require-Bundle: org.eclipse.swt,org.eclipse.jface
>
>
>
> In other news, I stumbled into making my "ant upload" target work
> tonight! It began earlier in the day when Holger mentioned that his
> ANT installation did not have bcel.jar in its lib directory, while
> mine did. I saw that I had copied it there when playing around with
> Java Net Tasks. So, I deleted all jars from my ANT installation's \lib
> directory and copied the default jars in there once more, and voila.
> the next time I ran "ant upload" it actually uploaded the jars. So,
> Jesse, if that task is broken for you as well, check your \lib
> directory for stray jars.
>
> James
>
>
>
>
> On 8/26/06, *Bruce Alspaugh* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Guys,
>
>     If you want a good intro to how Eclipse RCP applications fit
>     together and how this whole plugin architecture works, I would
>     highly recommend, "Eclipse Rich Client Platform:  Designing,
>     Coding and Packaging Java Applications" by Jeff McAffer and
>     Jean-Michel Lemieux.  It is a well writtten tutorial that walks
>     you through the Eclipse IDE step-by-step to build a chat client
>     application.  It is a quick read that should answer most of your
>     questions.
>
>     On 8/26/06, *Jesse Wilson* < [hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hey guys ----
>
>         A few quick thoughts on this discussion...
>         - I agree that we don't want to export the .impl package if
>            we can get away with it.
>
>
>     From experimenting with the Eclipse IDE, if plugin A does not
>     export a package, plugin B that depends on A cannot import it.  In
>     other words when I write an import statement in my java code for
>     plugin B that tries to reference the non-exported package in A,
>     Eclipse will not be able to resolve it.  I get a compile time
>     error.  This might be why some plug-in authors don't want to
>     export their non-api packages.  I think what Jeff McAffer was
>     wanting people to do is to go ahead and export the package, but
>     then use additional directives in the manifest to control access
>     to it.
>
>
>         - Generating the package list within Ant is pretty
>         straightforward.
>            We don't need a tool, I can probably write some ant code to
>         do it.
>
>
>     Hey, that's great!  It's nice to have an Ant scripting expert here
>     who can do it.
>
>         ...and one question:
>         - Could adding this extra metadata be annoying for people using
>            Eclipse RCP with Glazed Lists imported in a different way?
>            For example, if they're using it as a dependency for another
>            plugin?
>
>
>     I don't think so.  If you don't need the extra metadata, it should
>     be ignored.  What the additional metadata allows you to do is to
>     treat the distribution .jar file as an Eclipse plug-in without
>     having to turn it into a plug-in by injecting the necessary
>     metadata yourself using the wizard or by some other means.  Having
>     the extra metadata is what allows you to use the .jar as a
>     dependency of another plugin.  The export/dependency system is
>     part of the mechanism that allows you to share resources across
>     plugin boundaries.
>
>     If you don't want to cross a plug-in boundary, a plug-in author
>     could just incorporate the .jar into the plug-in they are
>     developing.  In that case the metadata would be unnecessary, but
>     that defeats modularity.  Better to make Glazed Lists a plugin,
>     and then multiple plug-ins that want to utilize Glazed Lists would
>     simply depend on the Glazed List plug-in.  It would also make
>     updating to a new version of Glazed Lists simpler, because there
>     would only be one plug-in to update.  The update process can even
>     be done after your application is deployed.  Eclipse has a
>     sophisticated Update feature that RCP applications can leverage to
>     allow the end-user to walk through a wizard to selectively
>     download, update, and add additional plug-ins.  The plug-in
>     binding process happens dynamically at runtime, so when they
>     restart their application the new functionality will magically
>     appear.
>
>     Bruce
>
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

James Lemieux
Bruce,

   Other than the ${version} discrepancy, I was attempting to recreate the manifest you pasted into your original post. I didn't read anything further regarding the OSGi bundle spec.

   If it's not too much trouble, could I get you to manually change the manifest.mf file to correct the ${version} problem (set it to 1.7.1, or whatever you like) and then see if eclipse still complains? If you could iterate like that a few times until it works and then give me a list of all problems with the manifest, then I can probably mow them all down tonight and get you working by tomorrow.

James.

On 8/28/06, Bruce Alspaugh <[hidden email]> wrote:
Hi James,

Thanks for working on this.

I downloaded glazedlists_java15.jar from the latest_build directory and
renamed it ca.odell.glazedlists_1.7.1.v20060827.jar to follow the file
naming convention for plugins.  Then I dropped it into the plugin
directory, and launched Eclipse.  When Eclipse started up, I got an
error, "Could not install bundle
plugins/ca.odell.glazedlists_1.7.1.v20060827.jar   For input string:
"${version}".

Can you take a look at the Bundle-Version tag in the manifest file?  It
needs an actual number like 1.7.1.

Bruce

James Lemieux wrote:

> Bruce, et al,
>
>    So, I spent today playing around with an ANT task from
> http://www.knopflerfish.org/ which helps projects create OSGi
> compliant "bundles"... otherwise known as "jar files with some meta
> information in the manifest file that Eclipse can work with". This is
> the task that Holger pointed us toward.
>
>    I extracted the ANT task code from the larger jar it lives in and
> customized the code slightly for our case. Specifically, the
> assumption in the existing task is that you only want to expose
> packages that contain class files. In our case, we have resource
> directories that contain only image files (PNG files), so the
> modification I made knows how to include relative paths to PNG files
> FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an

> absolute file name to a PNG, it's impossible to tell what directory
> you want reported. Our implementation cuts off everything before the
> "resources" folder name.
>
>    So, I've created a new entry in the Glazed Lists \tools directory
> called OSGi_bundleinfo here:
>
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
> < https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>
>
> and when you run the ant task: "ant jar" for Glazed Lists, it
> downloads OSGiBundleInfo.jar
> <https://glazedlists.dev.java.net/files/documents/1073/39631/OSGiBundleInfo.jar>
> from that directory, creates an ANT task from it, and then executes
> that ANT task in order to get the value that should be used for the
> export-packages manifest entry. I made a half-hearted attempt to
> assemble the export-packages value using standard ant tasks, but it's
> an exercise in madness.
>
>    So, Bruce, can I get you to test out the latest jars from CVS to
> see if they comply with Eclipse's expectation. At the moment, the
> generated manifest looks like this ( i.e. no newline chars anywhere
> within manifest entries... only between them):
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
> Main-Class: ca.odell.glazedlists.impl.Main

> Sealed: true
> Built-By: James Lemieux
> Built-At: 2006-08-27 21:52
> Implementation-Version: 2006-08-27 21:52
> Implementation-Title: Glazed Lists
> Implementation-URL: http://publicobject.com/glazedlists/
> Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob Eden, Hol
>  ger Brands
> Source-Version: JDK 1.5
> Bundle-ManifestVersion: 2
> Bundle-Name: Glazed Lists Plug-in
> Bundle-SymbolicName: ca.odell.glazedlists
> Bundle-Version: ${version}
> Bundle-ClassPath: .
> Bundle-Localization: plugin
> Export-Package: ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
>  ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
>  s.io
> < http://s.io>,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers
> ,ca
>  .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
>  ng,ca.odell.glazedlists.migrationkit.swt ,ca.odell.glazedlists.nachoca
>  lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
>  lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
>  cean,resources.windows,resources.windowsxp
> Require-Bundle: org.eclipse.swt,org.eclipse.jface
>
>
>
> In other news, I stumbled into making my "ant upload" target work
> tonight! It began earlier in the day when Holger mentioned that his
> ANT installation did not have bcel.jar in its lib directory, while
> mine did. I saw that I had copied it there when playing around with
> Java Net Tasks. So, I deleted all jars from my ANT installation's \lib
> directory and copied the default jars in there once more, and voila.
> the next time I ran "ant upload" it actually uploaded the jars. So,
> Jesse, if that task is broken for you as well, check your \lib
> directory for stray jars.
>
> James
>
>
>
>
> On 8/26/06, *Bruce Alspaugh* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi Guys,
>
>     If you want a good intro to how Eclipse RCP applications fit
>     together and how this whole plugin architecture works, I would
>     highly recommend, "Eclipse Rich Client Platform:  Designing,
>     Coding and Packaging Java Applications" by Jeff McAffer and
>     Jean-Michel Lemieux.  It is a well writtten tutorial that walks
>     you through the Eclipse IDE step-by-step to build a chat client
>     application.  It is a quick read that should answer most of your
>     questions.
>
>     On 8/26/06, *Jesse Wilson* < [hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hey guys ----
>
>         A few quick thoughts on this discussion...
>         - I agree that we don't want to export the .impl package if
>            we can get away with it.
>
>
>     From experimenting with the Eclipse IDE, if plugin A does not
>     export a package, plugin B that depends on A cannot import it.  In
>     other words when I write an import statement in my java code for
>     plugin B that tries to reference the non-exported package in A,
>     Eclipse will not be able to resolve it.  I get a compile time
>     error.  This might be why some plug-in authors don't want to
>     export their non-api packages.  I think what Jeff McAffer was
>     wanting people to do is to go ahead and export the package, but
>     then use additional directives in the manifest to control access
>     to it.
>
>
>         - Generating the package list within Ant is pretty
>         straightforward.
>            We don't need a tool, I can probably write some ant code to
>         do it.
>
>
>     Hey, that's great!  It's nice to have an Ant scripting expert here
>     who can do it.
>
>         ...and one question:
>         - Could adding this extra metadata be annoying for people using
>            Eclipse RCP with Glazed Lists imported in a different way?
>            For example, if they're using it as a dependency for another
>            plugin?
>
>
>     I don't think so.  If you don't need the extra metadata, it should
>     be ignored.  What the additional metadata allows you to do is to
>     treat the distribution .jar file as an Eclipse plug-in without
>     having to turn it into a plug-in by injecting the necessary
>     metadata yourself using the wizard or by some other means.  Having
>     the extra metadata is what allows you to use the .jar as a
>     dependency of another plugin.  The export/dependency system is
>     part of the mechanism that allows you to share resources across
>     plugin boundaries.
>
>     If you don't want to cross a plug-in boundary, a plug-in author
>     could just incorporate the .jar into the plug-in they are
>     developing.  In that case the metadata would be unnecessary, but
>     that defeats modularity.  Better to make Glazed Lists a plugin,
>     and then multiple plug-ins that want to utilize Glazed Lists would
>     simply depend on the Glazed List plug-in.  It would also make
>     updating to a new version of Glazed Lists simpler, because there
>     would only be one plug-in to update.  The update process can even
>     be done after your application is deployed.  Eclipse has a
>     sophisticated Update feature that RCP applications can leverage to
>     allow the end-user to walk through a wizard to selectively
>     download, update, and add additional plug-ins.  The plug-in
>     binding process happens dynamically at runtime, so when they
>     restart their application the new functionality will magically
>     appear.
>
>     Bruce
>
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
I'll give it a try.

Bruce

James Lemieux wrote:

> Bruce,
>
>    Other than the ${version} discrepancy, I was attempting to recreate
> the manifest you pasted into your original post. I didn't read
> anything further regarding the OSGi bundle spec.
>
>    If it's not too much trouble, could I get you to manually change
> the manifest.mf file to correct the ${version} problem (set it to
> 1.7.1, or whatever you like) and then see if eclipse still complains?
> If you could iterate like that a few times until it works and then
> give me a list of all problems with the manifest, then I can probably
> mow them all down tonight and get you working by tomorrow.
>
> James.
>
> On 8/28/06, *Bruce Alspaugh* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi James,
>
>     Thanks for working on this.
>
>     I downloaded glazedlists_java15.jar from the latest_build
>     directory and
>     renamed it ca.odell.glazedlists_1.7.1.v20060827.jar to follow the file
>     naming convention for plugins.  Then I dropped it into the plugin
>     directory, and launched Eclipse.  When Eclipse started up, I got an
>     error, "Could not install bundle
>     plugins/ca.odell.glazedlists_1.7.1.v20060827.jar   For input string:
>     "${version}".
>
>     Can you take a look at the Bundle-Version tag in the manifest
>     file?  It
>     needs an actual number like 1.7.1.
>
>     Bruce
>
>     James Lemieux wrote:
>     > Bruce, et al,
>     >
>     >    So, I spent today playing around with an ANT task from
>     > http://www.knopflerfish.org/ which helps projects create OSGi
>     > compliant "bundles"... otherwise known as "jar files with some meta
>     > information in the manifest file that Eclipse can work with".
>     This is
>     > the task that Holger pointed us toward.
>     >
>     >    I extracted the ANT task code from the larger jar it lives in and
>     > customized the code slightly for our case. Specifically, the
>     > assumption in the existing task is that you only want to expose
>     > packages that contain class files. In our case, we have resource
>     > directories that contain only image files (PNG files), so the
>     > modification I made knows how to include relative paths to PNG files
>     > FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an
>     > absolute file name to a PNG, it's impossible to tell what directory
>     > you want reported. Our implementation cuts off everything before
>     the
>     > "resources" folder name.
>     >
>     >    So, I've created a new entry in the Glazed Lists \tools directory
>     > called OSGi_bundleinfo here:
>     >
>     >
>     https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
>     <https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>
>     > <
>     https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
>     <https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>>
>     >
>     > and when you run the ant task: "ant jar" for Glazed Lists, it
>     > downloads OSGiBundleInfo.jar
>     >
>     <https://glazedlists.dev.java.net/files/documents/1073/39631/OSGiBundleInfo.jar>
>     > from that directory, creates an ANT task from it, and then executes
>     > that ANT task in order to get the value that should be used for the
>     > export-packages manifest entry. I made a half-hearted attempt to
>     > assemble the export-packages value using standard ant tasks, but
>     it's
>     > an exercise in madness.
>     >
>     >    So, Bruce, can I get you to test out the latest jars from CVS to
>     > see if they comply with Eclipse's expectation. At the moment, the
>     > generated manifest looks like this ( i.e. no newline chars anywhere
>     > within manifest entries... only between them):
>     >
>     > Manifest-Version: 1.0
>     > Ant-Version: Apache Ant 1.6.5
>     > Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>     > Main-Class: ca.odell.glazedlists.impl.Main
>     > Sealed: true
>     > Built-By: James Lemieux
>     > Built-At: 2006-08-27 21:52
>     > Implementation-Version: 2006-08-27 21:52
>     > Implementation-Title: Glazed Lists
>     > Implementation-URL: http://publicobject.com/glazedlists/
>     > Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob
>     Eden, Hol
>     >  ger Brands
>     > Source-Version: JDK 1.5
>     > Bundle-ManifestVersion: 2
>     > Bundle-Name: Glazed Lists Plug-in
>     > Bundle-SymbolicName: ca.odell.glazedlists
>     > Bundle-Version: ${version}
>     > Bundle-ClassPath: .
>     > Bundle-Localization: plugin
>     > Export-Package:
>     ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
>     >  ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
>     >  s.io <http://s.io>
>     > <
>     http://s.io>,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers
>     > ,ca
>     >  .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
>     >  ng,ca.odell.glazedlists.migrationkit.swt
>     ,ca.odell.glazedlists.nachoca
>     >  lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
>     >  lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
>     >  cean,resources.windows,resources.windowsxp
>     > Require-Bundle: org.eclipse.swt,org.eclipse.jface
>     >
>     >
>     >
>     > In other news, I stumbled into making my "ant upload" target work
>     > tonight! It began earlier in the day when Holger mentioned that his
>     > ANT installation did not have bcel.jar in its lib directory, while
>     > mine did. I saw that I had copied it there when playing around with
>     > Java Net Tasks. So, I deleted all jars from my ANT
>     installation's \lib
>     > directory and copied the default jars in there once more, and voila.
>     > the next time I ran "ant upload" it actually uploaded the jars. So,
>     > Jesse, if that task is broken for you as well, check your \lib
>     > directory for stray jars.
>     >
>     > James
>     >
>     >
>     >
>     >
>     > On 8/26/06, *Bruce Alspaugh* <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto: [hidden email]
>     <mailto:[hidden email]>>> wrote:
>     >
>     >     Hi Guys,
>     >
>     >     If you want a good intro to how Eclipse RCP applications fit
>     >     together and how this whole plugin architecture works, I would
>     >     highly recommend, "Eclipse Rich Client Platform:  Designing,
>     >     Coding and Packaging Java Applications" by Jeff McAffer and
>     >     Jean-Michel Lemieux.  It is a well writtten tutorial that walks
>     >     you through the Eclipse IDE step-by-step to build a chat client
>     >     application.  It is a quick read that should answer most of your
>     >     questions.
>     >
>     >     On 8/26/06, *Jesse Wilson* < [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >         Hey guys ----
>     >
>     >         A few quick thoughts on this discussion...
>     >         - I agree that we don't want to export the .impl package if
>     >            we can get away with it.
>     >
>     >
>     >     From experimenting with the Eclipse IDE, if plugin A does not
>     >     export a package, plugin B that depends on A cannot import
>     it.  In
>     >     other words when I write an import statement in my java code for
>     >     plugin B that tries to reference the non-exported package in A,
>     >     Eclipse will not be able to resolve it.  I get a compile time
>     >     error.  This might be why some plug-in authors don't want to
>     >     export their non-api packages.  I think what Jeff McAffer was
>     >     wanting people to do is to go ahead and export the package, but
>     >     then use additional directives in the manifest to control access
>     >     to it.
>     >
>     >
>     >         - Generating the package list within Ant is pretty
>     >         straightforward.
>     >            We don't need a tool, I can probably write some ant
>     code to
>     >         do it.
>     >
>     >
>     >     Hey, that's great!  It's nice to have an Ant scripting
>     expert here
>     >     who can do it.
>     >
>     >         ...and one question:
>     >         - Could adding this extra metadata be annoying for
>     people using
>     >            Eclipse RCP with Glazed Lists imported in a different
>     way?
>     >            For example, if they're using it as a dependency for
>     another
>     >            plugin?
>     >
>     >
>     >     I don't think so.  If you don't need the extra metadata, it
>     should
>     >     be ignored.  What the additional metadata allows you to do is to
>     >     treat the distribution .jar file as an Eclipse plug-in without
>     >     having to turn it into a plug-in by injecting the necessary
>     >     metadata yourself using the wizard or by some other
>     means.  Having
>     >     the extra metadata is what allows you to use the .jar as a
>     >     dependency of another plugin.  The export/dependency system is
>     >     part of the mechanism that allows you to share resources across
>     >     plugin boundaries.
>     >
>     >     If you don't want to cross a plug-in boundary, a plug-in author
>     >     could just incorporate the .jar into the plug-in they are
>     >     developing.  In that case the metadata would be unnecessary, but
>     >     that defeats modularity.  Better to make Glazed Lists a plugin,
>     >     and then multiple plug-ins that want to utilize Glazed Lists
>     would
>     >     simply depend on the Glazed List plug-in.  It would also make
>     >     updating to a new version of Glazed Lists simpler, because there
>     >     would only be one plug-in to update.  The update process can
>     even
>     >     be done after your application is deployed.  Eclipse has a
>     >     sophisticated Update feature that RCP applications can
>     leverage to
>     >     allow the end-user to walk through a wizard to selectively
>     >     download, update, and add additional plug-ins.  The plug-in
>     >     binding process happens dynamically at runtime, so when they
>     >     restart their application the new functionality will magically
>     >     appear.
>     >
>     >     Bruce
>     >
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

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

Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

Bruce Alspaugh-2
In reply to this post by James Lemieux
Hi James,

Attached is a manifest.mf file that Eclipse seems to be happy with.  I
took a standard Glazed List distribution, replaced the manifest file
with this one, renamed the .jar file to
"ca.odell.glazedlists_1.7.1.v20060827.jar" to conform to the plug-in
naming convention, copied it into the plugins directory, started up
Eclipse, and tried it out.

Eclipse detected the plug-in without any warnings or errors.  It shows
up as "ca.odell.glazedlists (1.7.1)" right along with the other built-in
plug-ins. I left the tags that you were already using alone, and they
didn't seem to interfere with Eclipse.  I created a "Hello, World"
plug-in, added a dependency on the Glazed Lists plug-in, instantiated a
BasicEventList, and everything compiled and ran without a hitch.  I
didn't try displaying an EventList, but I think we are OK from previous
tests.

I tagged the "impl" packages as "x-internal := true" so that when I try
to write an import statement for one of those packages, Eclipse gives me
a "discouraged access" warning.  By changing a preference I can make
Eclipse ignore it, give a warning, or give an error.  If it doesn't make
building the Export-Package list too horribly complicated, I think this
is the behavior we want.  The people who answered me in the newsgroups
basically confirmed things for me.

I think if we can duplicate this manifest we should be good to go.  Be
careful about line wrapping or blank lines in the middle.  If we get a
bad line break, especially in the middle of a package name or other
identifier, it could confuse Eclipse.

Too bad Hibernate doesn't make it this easy for the developer.  :)

Bruce

James Lemieux wrote:

> Bruce,
>
>    Other than the ${version} discrepancy, I was attempting to recreate
> the manifest you pasted into your original post. I didn't read
> anything further regarding the OSGi bundle spec.
>
>    If it's not too much trouble, could I get you to manually change
> the manifest.mf file to correct the ${version} problem (set it to
> 1.7.1, or whatever you like) and then see if eclipse still complains?
> If you could iterate like that a few times until it works and then
> give me a list of all problems with the manifest, then I can probably
> mow them all down tonight and get you working by tomorrow.
>
> James.
>
> On 8/28/06, *Bruce Alspaugh* <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hi James,
>
>     Thanks for working on this.
>
>     I downloaded glazedlists_java15.jar from the latest_build
>     directory and
>     renamed it ca.odell.glazedlists_1.7.1.v20060827.jar to follow the file
>     naming convention for plugins.  Then I dropped it into the plugin
>     directory, and launched Eclipse.  When Eclipse started up, I got an
>     error, "Could not install bundle
>     plugins/ca.odell.glazedlists_1.7.1.v20060827.jar   For input string:
>     "${version}".
>
>     Can you take a look at the Bundle-Version tag in the manifest
>     file?  It
>     needs an actual number like 1.7.1.
>
>     Bruce
>
>     James Lemieux wrote:
>     > Bruce, et al,
>     >
>     >    So, I spent today playing around with an ANT task from
>     > http://www.knopflerfish.org/ which helps projects create OSGi
>     > compliant "bundles"... otherwise known as "jar files with some meta
>     > information in the manifest file that Eclipse can work with".
>     This is
>     > the task that Holger pointed us toward.
>     >
>     >    I extracted the ANT task code from the larger jar it lives in and
>     > customized the code slightly for our case. Specifically, the
>     > assumption in the existing task is that you only want to expose
>     > packages that contain class files. In our case, we have resource
>     > directories that contain only image files (PNG files), so the
>     > modification I made knows how to include relative paths to PNG files
>     > FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an
>     > absolute file name to a PNG, it's impossible to tell what directory
>     > you want reported. Our implementation cuts off everything before
>     the
>     > "resources" folder name.
>     >
>     >    So, I've created a new entry in the Glazed Lists \tools directory
>     > called OSGi_bundleinfo here:
>     >
>     >
>     https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
>     <https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>
>     > <
>     https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
>     <https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>>
>     >
>     > and when you run the ant task: "ant jar" for Glazed Lists, it
>     > downloads OSGiBundleInfo.jar
>     >
>     <https://glazedlists.dev.java.net/files/documents/1073/39631/OSGiBundleInfo.jar>
>     > from that directory, creates an ANT task from it, and then executes
>     > that ANT task in order to get the value that should be used for the
>     > export-packages manifest entry. I made a half-hearted attempt to
>     > assemble the export-packages value using standard ant tasks, but
>     it's
>     > an exercise in madness.
>     >
>     >    So, Bruce, can I get you to test out the latest jars from CVS to
>     > see if they comply with Eclipse's expectation. At the moment, the
>     > generated manifest looks like this ( i.e. no newline chars anywhere
>     > within manifest entries... only between them):
>     >
>     > Manifest-Version: 1.0
>     > Ant-Version: Apache Ant 1.6.5
>     > Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>     > Main-Class: ca.odell.glazedlists.impl.Main
>     > Sealed: true
>     > Built-By: James Lemieux
>     > Built-At: 2006-08-27 21:52
>     > Implementation-Version: 2006-08-27 21:52
>     > Implementation-Title: Glazed Lists
>     > Implementation-URL: http://publicobject.com/glazedlists/
>     > Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob
>     Eden, Hol
>     >  ger Brands
>     > Source-Version: JDK 1.5
>     > Bundle-ManifestVersion: 2
>     > Bundle-Name: Glazed Lists Plug-in
>     > Bundle-SymbolicName: ca.odell.glazedlists
>     > Bundle-Version: ${version}
>     > Bundle-ClassPath: .
>     > Bundle-Localization: plugin
>     > Export-Package:
>     ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
>     >  ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
>     >  s.io <http://s.io>
>     > <
>     http://s.io>,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers
>     > ,ca
>     >  .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
>     >  ng,ca.odell.glazedlists.migrationkit.swt
>     ,ca.odell.glazedlists.nachoca
>     >  lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
>     >  lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
>     >  cean,resources.windows,resources.windowsxp
>     > Require-Bundle: org.eclipse.swt,org.eclipse.jface
>     >
>     >
>     >
>     > In other news, I stumbled into making my "ant upload" target work
>     > tonight! It began earlier in the day when Holger mentioned that his
>     > ANT installation did not have bcel.jar in its lib directory, while
>     > mine did. I saw that I had copied it there when playing around with
>     > Java Net Tasks. So, I deleted all jars from my ANT
>     installation's \lib
>     > directory and copied the default jars in there once more, and voila.
>     > the next time I ran "ant upload" it actually uploaded the jars. So,
>     > Jesse, if that task is broken for you as well, check your \lib
>     > directory for stray jars.
>     >
>     > James
>     >
>     >
>     >
>     >
>     > On 8/26/06, *Bruce Alspaugh* <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto: [hidden email]
>     <mailto:[hidden email]>>> wrote:
>     >
>     >     Hi Guys,
>     >
>     >     If you want a good intro to how Eclipse RCP applications fit
>     >     together and how this whole plugin architecture works, I would
>     >     highly recommend, "Eclipse Rich Client Platform:  Designing,
>     >     Coding and Packaging Java Applications" by Jeff McAffer and
>     >     Jean-Michel Lemieux.  It is a well writtten tutorial that walks
>     >     you through the Eclipse IDE step-by-step to build a chat client
>     >     application.  It is a quick read that should answer most of your
>     >     questions.
>     >
>     >     On 8/26/06, *Jesse Wilson* < [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >         Hey guys ----
>     >
>     >         A few quick thoughts on this discussion...
>     >         - I agree that we don't want to export the .impl package if
>     >            we can get away with it.
>     >
>     >
>     >     From experimenting with the Eclipse IDE, if plugin A does not
>     >     export a package, plugin B that depends on A cannot import
>     it.  In
>     >     other words when I write an import statement in my java code for
>     >     plugin B that tries to reference the non-exported package in A,
>     >     Eclipse will not be able to resolve it.  I get a compile time
>     >     error.  This might be why some plug-in authors don't want to
>     >     export their non-api packages.  I think what Jeff McAffer was
>     >     wanting people to do is to go ahead and export the package, but
>     >     then use additional directives in the manifest to control access
>     >     to it.
>     >
>     >
>     >         - Generating the package list within Ant is pretty
>     >         straightforward.
>     >            We don't need a tool, I can probably write some ant
>     code to
>     >         do it.
>     >
>     >
>     >     Hey, that's great!  It's nice to have an Ant scripting
>     expert here
>     >     who can do it.
>     >
>     >         ...and one question:
>     >         - Could adding this extra metadata be annoying for
>     people using
>     >            Eclipse RCP with Glazed Lists imported in a different
>     way?
>     >            For example, if they're using it as a dependency for
>     another
>     >            plugin?
>     >
>     >
>     >     I don't think so.  If you don't need the extra metadata, it
>     should
>     >     be ignored.  What the additional metadata allows you to do is to
>     >     treat the distribution .jar file as an Eclipse plug-in without
>     >     having to turn it into a plug-in by injecting the necessary
>     >     metadata yourself using the wizard or by some other
>     means.  Having
>     >     the extra metadata is what allows you to use the .jar as a
>     >     dependency of another plugin.  The export/dependency system is
>     >     part of the mechanism that allows you to share resources across
>     >     plugin boundaries.
>     >
>     >     If you don't want to cross a plug-in boundary, a plug-in author
>     >     could just incorporate the .jar into the plug-in they are
>     >     developing.  In that case the metadata would be unnecessary, but
>     >     that defeats modularity.  Better to make Glazed Lists a plugin,
>     >     and then multiple plug-ins that want to utilize Glazed Lists
>     would
>     >     simply depend on the Glazed List plug-in.  It would also make
>     >     updating to a new version of Glazed Lists simpler, because there
>     >     would only be one plug-in to update.  The update process can
>     even
>     >     be done after your application is deployed.  Eclipse has a
>     >     sophisticated Update feature that RCP applications can
>     leverage to
>     >     allow the end-user to walk through a wizard to selectively
>     >     download, update, and add additional plug-ins.  The plug-in
>     >     binding process happens dynamically at runtime, so when they
>     >     restart their application the new functionality will magically
>     >     appear.
>     >
>     >     Bruce
>     >
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_06-64 ("Apple Computer, Inc.")
Main-Class: ca.odell.glazedlists.impl.Main
Sealed: true
Built-By: jessewilson
Built-At: 2006-08-10 0:27
Implementation-Version: 1.7.0
Implementation-Title: Glazed Lists
Implementation-URL: http://publicobject.com/glazedlists/
Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob Eden, Holger Brands
Source-Version: JDK 1.5
Bundle-ManifestVersion: 2
Bundle-Name: Glazed Lists Plugin
Bundle-SymbolicName: ca.odell.glazedlists
Bundle-Version: 1.7.1
Bundle-ClassPath: .
Bundle-Vendor: http://www.publicobject.com/glazedlists/
Bundle-Localization: plugin
Export-Package: ca.odell.glazedlists,
 ca.odell.glazedlists.event,
 ca.odell.glazedlists.gui,
 ca.odell.glazedlists.impl; x-internal := true,
 ca.odell.glazedlists.impl.adt; x-internal := true,
 ca.odell.glazedlists.impl.adt.barcode2; x-internal := true,
 ca.odell.glazedlists.impl.adt.gnutrove; x-internal := true,
 ca.odell.glazedlists.impl.beans; x-internal := true,
 ca.odell.glazedlists.impl.ctp; x-internal := true,
 ca.odell.glazedlists.impl.filter; x-internal := true,
 ca.odell.glazedlists.impl.gui; x-internal := true,
 ca.odell.glazedlists.impl.io; x-internal := true,
 ca.odell.glazedlists.impl.java15; x-internal := true,
 ca.odell.glazedlists.impl.matchers; x-internal := true,
 ca.odell.glazedlists.impl.nio; x-internal := true,
 ca.odell.glazedlists.impl.pmap; x-internal := true,
 ca.odell.glazedlists.impl.rbp; x-internal := true,
 ca.odell.glazedlists.impl.sort; x-internal := true,
 ca.odell.glazedlists.impl.swing; x-internal := true,
 ca.odell.glazedlists.impl.swt; x-internal := true,
 ca.odell.glazedlists.io,
 ca.odell.glazedlists.jfreechart,
 ca.odell.glazedlists.matchers,
 ca.odell.glazedlists.migrationkit,
 ca.odell.glazedlists.migrationkit.swing,
 ca.odell.glazedlists.migrationkit.swt,
 ca.odell.glazedlists.nachocalendar,
 ca.odell.glazedlists.swing,
 ca.odell.glazedlists.swt,
 ca.odell.glazedlists.util.concurrent,
 resources.aqua,
 resources.metal,
 resources.ocean,
 resources.windows,
 resources.windowsxp
Require-Bundle: org.eclipse.swt,
 org.eclipse.jface


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Packaging GlazedLists as a Bundle

James Lemieux
Hey Bruce,

Thanks for getting me a stable target to aim at. It shouldn't be too difficult to add the "x-internal := true" mumbo jumbo at the correct location. We've already customized the knopfler ANT target to some degree to include our \resources folders... so doing a bit more customization doesn't worry me.

I'll also see how easy it is to add \n's between the Export-Package elements.

Look for a new jar in CVS tomorrow morning...

James

On 8/28/06, Bruce Alspaugh <[hidden email]> wrote:
Hi James,

Attached is a manifest.mf file that Eclipse seems to be happy with.  I
took a standard Glazed List distribution, replaced the manifest file
with this one, renamed the .jar file to
"ca.odell.glazedlists_1.7.1.v20060827.jar " to conform to the plug-in
naming convention, copied it into the plugins directory, started up
Eclipse, and tried it out.

Eclipse detected the plug-in without any warnings or errors.  It shows
up as " ca.odell.glazedlists (1.7.1)" right along with the other built-in
plug-ins. I left the tags that you were already using alone, and they
didn't seem to interfere with Eclipse.  I created a "Hello, World"
plug-in, added a dependency on the Glazed Lists plug-in, instantiated a
BasicEventList, and everything compiled and ran without a hitch.  I
didn't try displaying an EventList, but I think we are OK from previous
tests.

I tagged the "impl" packages as "x-internal := true" so that when I try
to write an import statement for one of those packages, Eclipse gives me
a "discouraged access" warning.  By changing a preference I can make
Eclipse ignore it, give a warning, or give an error.  If it doesn't make
building the Export-Package list too horribly complicated, I think this
is the behavior we want.  The people who answered me in the newsgroups
basically confirmed things for me.

I think if we can duplicate this manifest we should be good to go.  Be
careful about line wrapping or blank lines in the middle.  If we get a
bad line break, especially in the middle of a package name or other
identifier, it could confuse Eclipse.

Too bad Hibernate doesn't make it this easy for the developer.  :)

Bruce

James Lemieux wrote:

> Bruce,
>
>    Other than the ${version} discrepancy, I was attempting to recreate
> the manifest you pasted into your original post. I didn't read
> anything further regarding the OSGi bundle spec.
>
>    If it's not too much trouble, could I get you to manually change
> the manifest.mf file to correct the ${version} problem (set it to
> 1.7.1, or whatever you like) and then see if eclipse still complains?
> If you could iterate like that a few times until it works and then
> give me a list of all problems with the manifest, then I can probably
> mow them all down tonight and get you working by tomorrow.
>
> James.
>
> On 8/28/06, *Bruce Alspaugh* <[hidden email]
> <mailto: [hidden email]>> wrote:
>
>     Hi James,
>
>     Thanks for working on this.
>
>     I downloaded glazedlists_java15.jar from the latest_build
>     directory and
>     renamed it ca.odell.glazedlists_1.7.1.v20060827.jar to follow the file
>     naming convention for plugins.  Then I dropped it into the plugin
>     directory, and launched Eclipse.  When Eclipse started up, I got an
>     error, "Could not install bundle
>     plugins/ca.odell.glazedlists_1.7.1.v20060827.jar   For input string:
>     "${version}".
>
>     Can you take a look at the Bundle-Version tag in the manifest
>     file?  It
>     needs an actual number like 1.7.1.
>
>     Bruce
>
>     James Lemieux wrote:
>     > Bruce, et al,
>     >
>     >    So, I spent today playing around with an ANT task from
>     > http://www.knopflerfish.org/ which helps projects create OSGi
>     > compliant "bundles"... otherwise known as "jar files with some meta
>     > information in the manifest file that Eclipse can work with".
>     This is
>     > the task that Holger pointed us toward.
>     >
>     >    I extracted the ANT task code from the larger jar it lives in and
>     > customized the code slightly for our case. Specifically, the
>     > assumption in the existing task is that you only want to expose
>     > packages that contain class files. In our case, we have resource
>     > directories that contain only image files (PNG files), so the
>     > modification I made knows how to include relative paths to PNG files
>     > FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an
>     > absolute file name to a PNG, it's impossible to tell what directory
>     > you want reported. Our implementation cuts off everything before
>     the
>     > "resources" folder name.
>     >
>     >    So, I've created a new entry in the Glazed Lists \tools directory
>     > called OSGi_bundleinfo here:
>     >
>     >
>     https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
>     < https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>
>     > <
>     https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
>     < https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>>
>     >
>     > and when you run the ant task: "ant jar" for Glazed Lists, it
>     > downloads OSGiBundleInfo.jar
>     >
>     <https://glazedlists.dev.java.net/files/documents/1073/39631/OSGiBundleInfo.jar >
>     > from that directory, creates an ANT task from it, and then executes
>     > that ANT task in order to get the value that should be used for the
>     > export-packages manifest entry. I made a half-hearted attempt to
>     > assemble the export-packages value using standard ant tasks, but
>     it's
>     > an exercise in madness.
>     >
>     >    So, Bruce, can I get you to test out the latest jars from CVS to
>     > see if they comply with Eclipse's expectation. At the moment, the
>     > generated manifest looks like this ( i.e. no newline chars anywhere
>     > within manifest entries... only between them):
>     >
>     > Manifest-Version: 1.0
>     > Ant-Version: Apache Ant 1.6.5
>     > Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>     > Main-Class: ca.odell.glazedlists.impl.Main
>     > Sealed: true
>     > Built-By: James Lemieux
>     > Built-At: 2006-08-27 21:52
>     > Implementation-Version: 2006-08-27 21:52
>     > Implementation-Title: Glazed Lists
>     > Implementation-URL: http://publicobject.com/glazedlists/
>     > Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob
>     Eden, Hol
>     >  ger Brands
>     > Source-Version: JDK 1.5
>     > Bundle-ManifestVersion: 2
>     > Bundle-Name: Glazed Lists Plug-in
>     > Bundle-SymbolicName: ca.odell.glazedlists
>     > Bundle-Version: ${version}
>     > Bundle-ClassPath: .
>     > Bundle-Localization: plugin
>     > Export-Package:
>     ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
>     >  ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
>     >  s.io <http://s.io>
>     > <
>     http://s.io>,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers
>     > ,ca
>     >  .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
>     >  ng,ca.odell.glazedlists.migrationkit.swt
>     ,ca.odell.glazedlists.nachoca
>     >  lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
>     >  lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
>     >  cean,resources.windows,resources.windowsxp

>     > Require-Bundle: org.eclipse.swt,org.eclipse.jface
>     >
>     >
>     >
>     > In other news, I stumbled into making my "ant upload" target work
>     > tonight! It began earlier in the day when Holger mentioned that his
>     > ANT installation did not have bcel.jar in its lib directory, while
>     > mine did. I saw that I had copied it there when playing around with
>     > Java Net Tasks. So, I deleted all jars from my ANT
>     installation's \lib
>     > directory and copied the default jars in there once more, and voila.
>     > the next time I ran "ant upload" it actually uploaded the jars. So,
>     > Jesse, if that task is broken for you as well, check your \lib
>     > directory for stray jars.
>     >
>     > James
>     >
>     >
>     >
>     >
>     > On 8/26/06, *Bruce Alspaugh* <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto: [hidden email]
>     <mailto:[hidden email]>>> wrote:
>     >
>     >     Hi Guys,
>     >
>     >     If you want a good intro to how Eclipse RCP applications fit
>     >     together and how this whole plugin architecture works, I would
>     >     highly recommend, "Eclipse Rich Client Platform:  Designing,
>     >     Coding and Packaging Java Applications" by Jeff McAffer and
>     >     Jean-Michel Lemieux.  It is a well writtten tutorial that walks
>     >     you through the Eclipse IDE step-by-step to build a chat client
>     >     application.  It is a quick read that should answer most of your
>     >     questions.
>     >
>     >     On 8/26/06, *Jesse Wilson* < [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >         Hey guys ----
>     >
>     >         A few quick thoughts on this discussion...
>     >         - I agree that we don't want to export the .impl package if
>     >            we can get away with it.
>     >
>     >
>     >     From experimenting with the Eclipse IDE, if plugin A does not
>     >     export a package, plugin B that depends on A cannot import
>     it.  In
>     >     other words when I write an import statement in my java code for
>     >     plugin B that tries to reference the non-exported package in A,
>     >     Eclipse will not be able to resolve it.  I get a compile time
>     >     error.  This might be why some plug-in authors don't want to
>     >     export their non-api packages.  I think what Jeff McAffer was
>     >     wanting people to do is to go ahead and export the package, but
>     >     then use additional directives in the manifest to control access
>     >     to it.
>     >
>     >
>     >         - Generating the package list within Ant is pretty
>     >         straightforward.
>     >            We don't need a tool, I can probably write some ant
>     code to
>     >         do it.
>     >
>     >
>     >     Hey, that's great!  It's nice to have an Ant scripting
>     expert here
>     >     who can do it.
>     >
>     >         ...and one question:
>     >         - Could adding this extra metadata be annoying for
>     people using
>     >            Eclipse RCP with Glazed Lists imported in a different
>     way?
>     >            For example, if they're using it as a dependency for
>     another
>     >            plugin?
>     >
>     >
>     >     I don't think so.  If you don't need the extra metadata, it
>     should
>     >     be ignored.  What the additional metadata allows you to do is to
>     >     treat the distribution .jar file as an Eclipse plug-in without

>     >     having to turn it into a plug-in by injecting the necessary
>     >     metadata yourself using the wizard or by some other
>     means.  Having
>     >     the extra metadata is what allows you to use the .jar as a
>     >     dependency of another plugin.  The export/dependency system is
>     >     part of the mechanism that allows you to share resources across
>     >     plugin boundaries.
>     >
>     >     If you don't want to cross a plug-in boundary, a plug-in author
>     >     could just incorporate the .jar into the plug-in they are
>     >     developing.  In that case the metadata would be unnecessary, but
>     >     that defeats modularity.  Better to make Glazed Lists a plugin,
>     >     and then multiple plug-ins that want to utilize Glazed Lists
>     would
>     >     simply depend on the Glazed List plug-in.  It would also make
>     >     updating to a new version of Glazed Lists simpler, because there
>     >     would only be one plug-in to update.  The update process can
>     even
>     >     be done after your application is deployed.  Eclipse has a
>     >     sophisticated Update feature that RCP applications can
>     leverage to
>     >     allow the end-user to walk through a wizard to selectively
>     >     download, update, and add additional plug-ins.  The plug-in
>     >     binding process happens dynamically at runtime, so when they
>     >     restart their application the new functionality will magically
>     >     appear.
>     >
>     >     Bruce
>     >
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>



Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_06-64 ("Apple Computer, Inc.")
Main-Class: ca.odell.glazedlists.impl.Main
Sealed: true
Built-By: jessewilson
Built-At: 2006-08-10 0:27
Implementation-Version: 1.7.0
Implementation-Title: Glazed Lists
Implementation-URL: http://publicobject.com/glazedlists/
Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob Eden, Holger Brands
Source-Version: JDK 1.5
Bundle-ManifestVersion: 2
Bundle-Name: Glazed Lists Plugin
Bundle-SymbolicName: ca.odell.glazedlists
Bundle-Version: 1.7.1
Bundle-ClassPath: .
Bundle-Vendor: http://www.publicobject.com/glazedlists/
Bundle-Localization: plugin
Export-Package: ca.odell.glazedlists ,
ca.odell.glazedlists.event,
ca.odell.glazedlists.gui,
ca.odell.glazedlists.impl; x-internal := true,
ca.odell.glazedlists.impl.adt; x-internal := true,
ca.odell.glazedlists.impl.adt.barcode2; x-internal := true,
ca.odell.glazedlists.impl.adt.gnutrove; x-internal := true,
ca.odell.glazedlists.impl.beans; x-internal := true,
ca.odell.glazedlists.impl.ctp; x-internal := true,
ca.odell.glazedlists.impl.filter; x-internal := true,
ca.odell.glazedlists.impl.gui; x-internal := true,
ca.odell.glazedlists.impl.io; x-internal := true,
ca.odell.glazedlists.impl.java15; x-internal := true,
ca.odell.glazedlists.impl.matchers; x-internal := true,
ca.odell.glazedlists.impl.nio; x-internal := true,
ca.odell.glazedlists.impl.pmap; x-internal := true,
ca.odell.glazedlists.impl.rbp; x-internal := true,
ca.odell.glazedlists.impl.sort; x-internal := true,
ca.odell.glazedlists.impl.swing; x-internal := true,
ca.odell.glazedlists.impl.swt; x-internal := true,
ca.odell.glazedlists.io ,
ca.odell.glazedlists.jfreechart,
ca.odell.glazedlists.matchers,
ca.odell.glazedlists.migrationkit,
ca.odell.glazedlists.migrationkit.swing,
ca.odell.glazedlists.migrationkit.swt,
ca.odell.glazedlists.nachocalendar ,
ca.odell.glazedlists.swing,
ca.odell.glazedlists.swt,
ca.odell.glazedlists.util.concurrent,
resources.aqua,
resources.metal,
resources.ocean,
resources.windows,
resources.windowsxp
Require-Bundle: org.eclipse.swt,
org.eclipse.jface



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


Reply | Threaded
Open this post in threaded view
|

Re: Re: Packaging GlazedLists as a Bundle

Jesse Wilson
Hey guys ----

I'm a little paranoid about version numbering here.

So far, our standard has been that the version number
is the date, unless it was a proper release in which
case it was three dotted numbers: 1.7.0. By making
exactly one release for a given number, we can easily
go back and validate whether a given problem occurred
for a given release.

When we do a snapshot build to fix or trial a feature between
releases, will this build work with the OSGi system if its only
version information is the date? Or do we need to select a
version number to tack on? I'd really prefer not to associate
version numbers with snapshot builds!

Other than that, the OSGi system looks pretty sweet. It's
unfortunate that it's not integrated with Maven, those two seem
to be attempting to accomplish overlapping goals!

Cheers,
Jesse

On 8/28/06, James Lemieux <[hidden email]> wrote:

> Hey Bruce,
>
> Thanks for getting me a stable target to aim at. It shouldn't be too
> difficult to add the "x-internal := true" mumbo jumbo at the correct
> location. We've already customized the knopfler ANT target to some degree to
> include our \resources folders... so doing a bit more customization doesn't
> worry me.
>
> I'll also see how easy it is to add \n's between the Export-Package
> elements.
>
> Look for a new jar in CVS tomorrow morning...
>
> James
>
>
> On 8/28/06, Bruce Alspaugh <[hidden email]> wrote:
> >
>  Hi James,
>
> Attached is a manifest.mf file that Eclipse seems to be happy with.  I
> took a standard Glazed List distribution, replaced the manifest file
> with this one, renamed the .jar file to
> "ca.odell.glazedlists_1.7.1.v20060827.jar " to conform to
> the plug-in
> naming convention, copied it into the plugins directory, started up
> Eclipse, and tried it out.
>
> Eclipse detected the plug-in without any warnings or errors.  It shows
> up as " ca.odell.glazedlists (1.7.1)" right along with the other built-in
> plug-ins. I left the tags that you were already using alone, and they
> didn't seem to interfere with Eclipse.  I created a "Hello, World"
> plug-in, added a dependency on the Glazed Lists plug-in, instantiated a
> BasicEventList, and everything compiled and ran without a hitch.  I
> didn't try displaying an EventList, but I think we are OK from previous
> tests.
>
> I tagged the "impl" packages as "x-internal := true" so that when I try
> to write an import statement for one of those packages, Eclipse gives me
> a "discouraged access" warning.  By changing a preference I can make
> Eclipse ignore it, give a warning, or give an error.  If it doesn't make
> building the Export-Package list too horribly complicated, I think this
> is the behavior we want.  The people who answered me in the newsgroups
> basically confirmed things for me.
>
> I think if we can duplicate this manifest we should be good to go.  Be
> careful about line wrapping or blank lines in the middle.  If we get a
> bad line break, especially in the middle of a package name or other
> identifier, it could confuse Eclipse.
>
> Too bad Hibernate doesn't make it this easy for the developer.  :)
>
> Bruce
>
> James Lemieux wrote:
> > Bruce,
> >
> >    Other than the ${version} discrepancy, I was attempting to recreate
> > the manifest you pasted into your original post. I didn't read
> > anything further regarding the OSGi bundle spec.
> >
> >    If it's not too much trouble, could I get you to manually change
> > the manifest.mf file to correct the ${version} problem (set it to
> > 1.7.1, or whatever you like) and then see if eclipse still complains?
> > If you could iterate like that a few times until it works and then
> > give me a list of all problems with the manifest, then I can probably
> > mow them all down tonight and get you working by tomorrow.
> >
> > James.
> >
> > On 8/28/06, *Bruce Alspaugh* <[hidden email]
> > <mailto: [hidden email]>> wrote:
> >
> >     Hi James,
> >
> >     Thanks for working on this.
> >
> >     I downloaded glazedlists_java15.jar from the latest_build
> >     directory and
> >     renamed it ca.odell.glazedlists_1.7.1.v20060827.jar
> to follow the file
> >     naming convention for plugins.  Then I dropped it into the plugin
> >     directory, and launched Eclipse.  When Eclipse started up, I got an
> >     error, "Could not install bundle
> >     plugins/ca.odell.glazedlists_1.7.1.v20060827.jar
> For input string:
> >     "${version}".
> >
> >     Can you take a look at the Bundle-Version tag in the manifest
> >     file?  It
> >     needs an actual number like 1.7.1.
> >
> >     Bruce
> >
> >     James Lemieux wrote:
> >     > Bruce, et al,
> >     >
> >     >    So, I spent today playing around with an ANT task from
> >     > http://www.knopflerfish.org/ which helps projects create OSGi
> >     > compliant "bundles"... otherwise known as "jar files with some meta
> >     > information in the manifest file that Eclipse can work with".
> >     This is
> >     > the task that Holger pointed us toward.
> >     >
> >     >    I extracted the ANT task code from the larger jar it lives in and
> >     > customized the code slightly for our case. Specifically, the
> >     > assumption in the existing task is that you only want to expose
> >     > packages that contain class files. In our case, we have resource
> >     > directories that contain only image files (PNG files), so the
> >     > modification I made knows how to include relative paths to PNG files
> >     > FOR GLAZED LISTS ONLY. It isn't a general fix, because, given an
> >     > absolute file name to a PNG, it's impossible to tell what directory
> >     > you want reported. Our implementation cuts off everything before
> >     the
> >     > "resources" folder name.
> >     >
> >     >    So, I've created a new entry in the Glazed Lists \tools directory
> >     > called OSGi_bundleinfo here:
> >     >
> >     >
> >
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
> >     <
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>
> >     > <
> >
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0
> >     <
> https://glazedlists.dev.java.net/servlets/ProjectDocumentList?folderID=5875&expandFolder=5875&folderID=0>>
> >     >
> >     > and when you run the ant task: "ant jar" for Glazed Lists, it
> >     > downloads OSGiBundleInfo.jar
> >     >
> >
> <https://glazedlists.dev.java.net/files/documents/1073/39631/OSGiBundleInfo.jar
> >
> >     > from that directory, creates an ANT task from it, and then executes
> >     > that ANT task in order to get the value that should be used for the
> >     > export-packages manifest entry. I made a half-hearted attempt to
> >     > assemble the export-packages value using standard ant tasks, but
> >     it's
> >     > an exercise in madness.
> >     >
> >     >    So, Bruce, can I get you to test out the latest jars from CVS to
> >     > see if they comply with Eclipse's expectation. At the moment, the
> >     > generated manifest looks like this ( i.e. no newline chars anywhere
> >     > within manifest entries... only between them):
> >     >
> >     > Manifest-Version: 1.0
> >     > Ant-Version: Apache Ant 1.6.5
> >     > Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
> >     > Main-Class: ca.odell.glazedlists.impl.Main
> >     > Sealed: true
> >     > Built-By: James Lemieux
> >     > Built-At: 2006-08-27 21:52
> >     > Implementation-Version: 2006-08-27 21:52
> >     > Implementation-Title: Glazed Lists
> >     > Implementation-URL:
> http://publicobject.com/glazedlists/
> >     > Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob
> >     Eden, Hol
> >     >  ger Brands
> >     > Source-Version: JDK 1.5
> >     > Bundle-ManifestVersion: 2
> >     > Bundle-Name: Glazed Lists Plug-in
> >     > Bundle-SymbolicName: ca.odell.glazedlists
> >     > Bundle-Version: ${version}
> >     > Bundle-ClassPath: .
> >     > Bundle-Localization: plugin
> >     > Export-Package:
> >     ca.odell.glazedlists,ca.odell.glazedlists.event,ca.ode
> >
> >  ll.glazedlists.gui,ca.odell.glazedlists.hibernate,ca.odell.glazedlist
> >     >  s.io <http://s.io>
> >     > <
> >
> http://s.io>,ca.odell.glazedlists.jfreechart,ca.odell.glazedlists.matchers
> >     > ,ca
> >
> >  .odell.glazedlists.migrationkit,ca.odell.glazedlists.migrationkit.swi
> >     >  ng,ca.odell.glazedlists.migrationkit.swt
> >     ,ca.odell.glazedlists.nachoca
> >
> >  lendar,ca.odell.glazedlists.swing,ca.odell.glazedlists.swt,ca.odell.g
> >
> >  lazedlists.util.concurrent,resources.aqua,resources.metal,resources.o
>  >     >  cean,resources.windows,resources.windowsxp
> >     > Require-Bundle: org.eclipse.swt,org.eclipse.jface
> >     >
> >     >
> >     >
> >     > In other news, I stumbled into making my "ant upload" target work
> >     > tonight! It began earlier in the day when Holger mentioned that his
> >     > ANT installation did not have bcel.jar in its lib directory, while
> >     > mine did. I saw that I had copied it there when playing around with
> >     > Java Net Tasks. So, I deleted all jars from my ANT
> >     installation's \lib
> >     > directory and copied the default jars in there once more, and voila.
> >     > the next time I ran "ant upload" it actually uploaded the jars. So,
> >     > Jesse, if that task is broken for you as well, check your \lib
> >     > directory for stray jars.
> >     >
> >     > James
> >     >
> >     >
> >     >
> >     >
> >     > On 8/26/06, *Bruce Alspaugh* <[hidden email]
> >     <mailto:[hidden email]>
> >     > <mailto: [hidden email]
> >     <mailto:[hidden email]>>> wrote:
> >     >
> >     >     Hi Guys,
> >     >
> >     >     If you want a good intro to how Eclipse RCP applications fit
> >     >     together and how this whole plugin architecture works, I would
> >     >     highly recommend, "Eclipse Rich Client Platform:  Designing,
> >     >     Coding and Packaging Java Applications" by Jeff McAffer and
> >     >     Jean-Michel Lemieux.  It is a well writtten tutorial that walks
> >     >     you through the Eclipse IDE step-by-step to build a chat client
> >     >     application.  It is a quick read that should answer most of your
> >     >     questions.
> >     >
> >     >     On 8/26/06, *Jesse Wilson* < [hidden email]
> >     <mailto:[hidden email]>
> >     >     <mailto:[hidden email] <mailto: [hidden email]>>> wrote:
> >     >
> >     >         Hey guys ----
> >     >
> >     >         A few quick thoughts on this discussion...
> >     >         - I agree that we don't want to export the .impl package if
> >     >            we can get away with it.
> >     >
> >     >
> >     >     From experimenting with the Eclipse IDE, if plugin A does not
> >     >     export a package, plugin B that depends on A cannot import
> >     it.  In
> >     >     other words when I write an import statement in my java code for
> >     >     plugin B that tries to reference the non-exported package in A,
> >     >     Eclipse will not be able to resolve it.  I get a compile time
> >     >     error.  This might be why some plug-in authors don't want to
> >     >     export their non-api packages.  I think what Jeff McAffer was
> >     >     wanting people to do is to go ahead and export the package, but
> >     >     then use additional directives in the manifest to control access
> >     >     to it.
> >     >
> >     >
> >     >         - Generating the package list within Ant is pretty
> >     >         straightforward.
> >     >            We don't need a tool, I can probably write some ant
> >     code to
> >     >         do it.
> >     >
> >     >
> >     >     Hey, that's great!  It's nice to have an Ant scripting
> >     expert here
> >     >     who can do it.
> >     >
> >     >         ...and one question:
> >     >         - Could adding this extra metadata be annoying for
> >     people using
> >     >            Eclipse RCP with Glazed Lists imported in a different
> >     way?
> >     >            For example, if they're using it as a dependency for
> >     another
> >     >            plugin?
> >     >
> >     >
> >     >     I don't think so.  If you don't need the extra metadata, it
> >     should
> >     >     be ignored.  What the additional metadata allows you to do is to
>  >     >     treat the distribution .jar file as an Eclipse plug-in without
> >     >     having to turn it into a plug-in by injecting the necessary
> >     >     metadata yourself using the wizard or by some other
> >     means.  Having
> >     >     the extra metadata is what allows you to use the .jar as a
> >     >     dependency of another plugin.  The export/dependency system is
> >     >     part of the mechanism that allows you to share resources across
> >     >     plugin boundaries.
> >     >
> >     >     If you don't want to cross a plug-in boundary, a plug-in author
> >     >     could just incorporate the .jar into the plug-in they are
> >     >     developing.  In that case the metadata would be unnecessary, but
> >     >     that defeats modularity.  Better to make Glazed Lists a plugin,
> >     >     and then multiple plug-ins that want to utilize Glazed Lists
> >     would
> >     >     simply depend on the Glazed List plug-in.  It would also make
> >     >     updating to a new version of Glazed Lists simpler, because there
> >     >     would only be one plug-in to update.  The update process can
> >     even
> >     >     be done after your application is deployed.  Eclipse has a
> >     >     sophisticated Update feature that RCP applications can
> >     leverage to
> >     >     allow the end-user to walk through a wizard to selectively
> >     >     download, update, and add additional plug-ins.  The plug-in
> >     >     binding process happens dynamically at runtime, so when they
> >     >     restart their application the new functionality will magically
> >     >     appear.
> >     >
> >     >     Bruce
> >     >
> >     >
> >     >
> >
> >
> ---------------------------------------------------------------------
> >     To unsubscribe, e-mail:
> [hidden email]
> >     <mailto:[hidden email] >
> >     For additional commands, e-mail:
> [hidden email]
> >     <mailto:[hidden email] >
> >
> >
>
>
>
> Manifest-Version: 1.0
> Ant-Version: Apache Ant 1.6.5
> Created-By: 1.5.0_06-64 ("Apple Computer, Inc.")
>
> Main-Class: ca.odell.glazedlists.impl.Main
> Sealed: true
>  Built-By: jessewilson
> Built-At: 2006-08-10 0:27
> Implementation-Version: 1.7.0
>
> Implementation-Title: Glazed Lists
> Implementation-URL: http://publicobject.com/glazedlists/
> Contributors: Jesse Wilson, Kevin Maltby, James Lemieux, Rob Eden, Holger
> Brands
>
> Source-Version: JDK 1.5
> Bundle-ManifestVersion: 2
> Bundle-Name: Glazed Lists Plugin
>
> Bundle-SymbolicName: ca.odell.glazedlists
> Bundle-Version: 1.7.1
> Bundle-ClassPath: .
> Bundle-Vendor: http://www.publicobject.com/glazedlists/
>
> Bundle-Localization: plugin
> Export-Package: ca.odell.glazedlists ,
>  ca.odell.glazedlists.event,
>  ca.odell.glazedlists.gui,
>  ca.odell.glazedlists.impl; x-internal := true,
>  ca.odell.glazedlists.impl.adt; x-internal := true,
>  ca.odell.glazedlists.impl.adt.barcode2; x-internal :=
> true,
>  ca.odell.glazedlists.impl.adt.gnutrove; x-internal :=
> true,
>  ca.odell.glazedlists.impl.beans; x-internal := true,
>  ca.odell.glazedlists.impl.ctp; x-internal := true,
>  ca.odell.glazedlists.impl.filter; x-internal := true,
>  ca.odell.glazedlists.impl.gui; x-internal := true,
>  ca.odell.glazedlists.impl.io; x-internal := true,
>  ca.odell.glazedlists.impl.java15; x-internal := true,
>  ca.odell.glazedlists.impl.matchers; x-internal := true,
>  ca.odell.glazedlists.impl.nio; x-internal := true,
>  ca.odell.glazedlists.impl.pmap; x-internal := true,
>  ca.odell.glazedlists.impl.rbp; x-internal := true,
>  ca.odell.glazedlists.impl.sort; x-internal := true,
>  ca.odell.glazedlists.impl.swing; x-internal := true,
>  ca.odell.glazedlists.impl.swt; x-internal := true,
>  ca.odell.glazedlists.io ,
>
>  ca.odell.glazedlists.jfreechart,
>  ca.odell.glazedlists.matchers,
>  ca.odell.glazedlists.migrationkit,
>  ca.odell.glazedlists.migrationkit.swing,
>  ca.odell.glazedlists.migrationkit.swt,
>  ca.odell.glazedlists.nachocalendar ,
>  ca.odell.glazedlists.swing,
>  ca.odell.glazedlists.swt,
>  ca.odell.glazedlists.util.concurrent,
>
>  resources.aqua,
>  resources.metal,
>  resources.ocean,
>  resources.windows,
>  resources.windowsxp
> Require-Bundle: org.eclipse.swt,
>  org.eclipse.jface
>
>
>
> ---------------------------------------------------------------------
> 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]

12