Replace "DynamicImport-Package: *" to exact package names in MANIFEST.MF

[GoogleCodeExporter]

Using asterisk with DynamicImport-Package is not really a good idea in any OSGi 
bundle. I generated simply a MANIFEST header with bnd tools that looks like the 
following:

Import-Package: javax.management;resolution:=optional,javax.naming;resol
 ution:=optional,javax.naming.spi;resolution:=optional,javax.net;resolut
 ion:=optional,javax.net.ssl;resolution:=optional,javax.servlet;resoluti
 on:=optional,javax.servlet.http;resolution:=optional,javax.sql;resoluti
 on:=optional,javax.transaction.xa;resolution:=optional,org.apache.lucen
 e.analysis;resolution:=optional,org.apache.lucene.analysis.standard;res
 olution:=optional,org.apache.lucene.document;resolution:=optional,org.a
 pache.lucene.index;resolution:=optional,org.apache.lucene.queryParser;r
 esolution:=optional,org.apache.lucene.search;resolution:=optional,org.a
 pache.lucene.store;resolution:=optional,org.apache.lucene.util;resoluti
 on:=optional,org.osgi.framework;resolution:=optional,org.slf4j;resoluti
 on:=optional

I think the maintainer of the project may know better which package is optional 
and which not and also at least the minimum versions for each package would be 
nice (like which version range of lucene is accepted).

In our case we even define a version for javax.transaction and javax.sql as we 
do not want to use the packages coming with the JDK.

Original issue reported on code.google.com by balazs.z...@everit.biz on 25 Jun 2012 at 8:59

[GoogleCodeExporter]

> Using asterisk with DynamicImport-Package is not really a good idea

It is used to support user defined functions.

Is it a problem for you?

I suggest before filing a bug to discuss it on the Google Group.

Original comment by thomas.t...@gmail.com on 26 Jun 2012 at 7:05

• Changed state: WorksForMe
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

First of all, I am sorry for not discussing it on the forum before. In my 
company we use our bug tracker as a communication platform as well.

My problem was that based on the header I did not see which requirement is 
optional and which is not. Also I did not see what version range is accepted. I 
had to go into documentations and try finding it out.

Also imagine if someone has two applications in the OSGi container. One of them 
uses Lucene 2.x, one of the Lucene 3.x. In this case it will not be controlled 
in h2 which Lucene it wires to.

Well, I created an Import-Package section for myself as the following:

Import-Package: javax.management,javax.naming,javax.naming.spi,javax.net
 ,javax.net.ssl,javax.servlet;version="[2.6,4)";resolution:=optional,jav
 ax.servlet.http;version="[2.6,4)";resolution:=optional,javax.sql;versio
 n="[4.0,5)",javax.transaction.xa;version="[1.1,2)",org.apache.lucene.an
 alysis;version="[3,4)";resolution:=optional,org.apache.lucene.analysis.
 standard;version="[3,4)";resolution:=optional,org.apache.lucene.documen
 t;version="[3,4)";resolution:=optional,org.apache.lucene.index;version=
 "[3,4)";resolution:=optional,org.apache.lucene.queryParser;version="[3,
 4)";resolution:=optional,org.apache.lucene.search;version="[3,4)";resol
 ution:=optional,org.apache.lucene.store;version="[3,4)";resolution:=opt
 ional,org.apache.lucene.util;version="[3,4)";resolution:=optional,org.o
 sgi.framework;version="[1.5,2)",org.slf4j;version="[1.6,2)"

In our case it is pretty sick as we do not want to use anything from the JDK 
(not even javax.sql package) as we had problems with the wiring before.

DynamicImport may have a meaning sometimes but it should not replace the 
necessary configuration. It would be something like if you wrote on top of each 
of your class "import *;"

Original comment by balazs.z...@everit.biz on 26 Jun 2012 at 7:57

• Added labels: ****
• Removed labels: ****