Опаковайте буркана на трета страна, който импортира от пакета по подразбиране с помощта на bndtools

Искам да опаковам буркан на трета страна. За съжаление доставчикът постави един единствен клас (a.class) с един единствен метод в пакета по подразбиране.

Когато се опитам да включа ресурса с помощта на Include-Resource: @lib/acme-8.0.jar, това води до следната грешка:

The default package '.' is not permitted by the Import-Package syntax.
This can be caused by compile errors in Eclipse because Eclipse creates valid class files regardless of compile errors.
The following package(s) import from the default package [com.acme.util]

bnd print -all acme-8.0.jar ми дава следния изход (съкратено, името на доставчика е заменено с acme)

[API USES]
.                                        []

com.acme.common                            []

com.acme.acmedrt                             [com.acme.acmedrt.types, com.acme.acmedrt.comm.jobtransport, com.acme.acmedrt.workflow.type
s]

com.acme.acmedrt.impl                        [com.acme.acmedrt, com.acme.acmedrt.types, org.apache.commons.logging, com.acme.acmedrt.imp
l.types, com.acme.acmedrt.comm.jobtransport, com.acme.acmedrt.pool, org.apache.commons.pool, com.acme.acmedrt.workflow.types]

com.acme.acmedrt.impl.types                  [com.acme.acmedrt.types, com.acme.acmedrt, com.acme.acmedrt.impl, org.xml.sax]

com.acme.acmedrt.notification                [com.acme.acmedrt]

com.acme.acmedrt.pool                        [com.acme.acmedrt, com.acme.acmedrt.impl.types, com.acme.acmedrt.impl, com.acme.acmedrt.types,
org.apache.commons.pool, com.acme.acmedrt.workflow.types]

com.acme.acmedrt.types                       [com.acme.acmedrt, com.acme.common]

com.acme.acmedrt.util                        []

com.acme.acmedrt.workflow.types              [com.acme.common]

com.acme.tools                             []

com.acme.util                              []

com.acme.util.xml                          []


[LIST]

  a.class
META-INF
  MANIFEST.MF
com
com <no contents>
com/acme
com/acme <no contents>
com/acme/common
  Enum.class
com/acme/acmedrt
[...]

Ако разбирам правилно този изход, няколко пакета използват пакета по подразбиране. Как изобщо е възможно това? Доколкото знам, не можете да импортирате класове от пакета по подразбиране.

Вече се свързах с доставчика с молба за преместване на класа в нарушение. Вероятно той няма да последва предложението ми.

Има ли заобиколно решение за обработка на класове в пакета по подразбиране?


java jar osgi bnd bndtools
person tobias_    schedule 11.01.2016    source източник
comment
Вярно е, че не можете да импортирате пакета по подразбиране в OSGi. Но трябва да е добре да имате класове от пакета по подразбиране във вашия пакет.   -  person Neil Bartlett    schedule 13.01.2016
comment
@NeilBartlett Може би, но bnd не успява да създаде пакет от дадения буркан, което води до съобщението за грешка по-горе.   -  person tobias_    schedule 13.01.2016
comment
Изглежда, че класът е пакетът по подразбиране, който се споменава в API на другите пакети. Оттук и съобщението за грешка.   -  person BJ Hargrave    schedule 13.01.2016
comment
@BJHargrave Съгласен съм. Но както казах, нямам никакъв контрол върху буркана на трета страна. Има ли начин да се погрижите за тази грешка и да създадете пакет, без да променяте дадения буркан?   -  person tobias_    schedule 13.01.2016
comment
Ако не можете да преместите класа в именуван пакет, тогава не можете да направите пакет от буркана. Пакетът без име (по подразбиране) не може да бъде експортиран или импортиран.   -  person BJ Hargrave    schedule 13.01.2016

Отговори (1)


arrow_upward
2
arrow_downward

Вероятно можете да се измъкнете със следната опция:

 -fixupmessages: "The default package "
person Peter Kriens    schedule 13.01.2016
comment
Тази опция потиска съобщението за грешка и ми позволява да създам пакет. Използването на библиотеката обаче води до изключение в някои случаи (com/acme/util/a.a(I)Ljava/lang/String; @44: if_icmpge .Очакван кадър на стекова карта на това място.). Не знам дали това е свързано с липсващия клас в пакета по подразбиране или е резултат от неудовлетворена зависимост. - person tobias_; 13.01.2016
comment
Гледайки съобщението, това е малко вероятно, но не и невъзможно ... Но ако имате скапана библиотека, имате скапани проблеми ... :-( - person Peter Kriens; 18.01.2016
comment
Доставчикът използва обфускация на код за части от тяхната библиотека. Споменатата грешка изглежда възниква, когато се извиква обфусциран код. Свързах се с продавача, за да прегледам техния продукт. - person tobias_; 11.02.2016