Fórum

External Jar for Liferay DXP

thumbnail
Manish Jha, modificado 6 Anos atrás.

External Jar for Liferay DXP

Junior Member Postagens: 50 Data de Entrada: 07/02/13 Postagens Recentes
I am creating Liferay DXP service and it has dependency on external jar. These jar have dependency on other jar as transitive dependency. This includes dependency on spring jars.

I followed option 4 on the following link to include dependent jar in the module.
https://web.liferay.com/web/user.26526/blog/-/blogs/osgi-module-dependencies

However, i do not want to include jar already provided by liferay OSGI container. I do not have idea how to get list of jars provided by OSGI container.

I would like to know is there any way to know jars provided by liferay OSGI container ?
thumbnail
Christoph Rabel, modificado 6 Anos atrás.

RE: External Jar for Liferay DXP

Liferay Legend Postagens: 1554 Data de Entrada: 24/09/09 Postagens Recentes
You can list all services through the gogo shell with the lb command
https://dev.liferay.com/develop/reference/-/knowledge_base/7-0/using-the-felix-gogo-shell

telnet localhost 11311
lb

On windows telnet is usually not installed, it can somehow be added, but it's probably easier to download putty.
thumbnail
Manish Jha, modificado 6 Anos atrás.

RE: External Jar for Liferay DXP

Junior Member Postagens: 50 Data de Entrada: 07/02/13 Postagens Recentes
OSGI service list does not list available jars for OSGI modules.
For example , I searched for Spring jar in the gogo shell, i could not jars listed. We know that spring jars are provided by Liferay OSGI container and we do not need to include the jar in the module's class path.
thumbnail
David H Nebinger, modificado 6 Anos atrás.

RE: External Jar for Liferay DXP (Resposta)

Liferay Legend Postagens: 14916 Data de Entrada: 02/09/06 Postagens Recentes
Manish Jha:
I would like to know is there any way to know jars provided by liferay OSGI container ?


No.

Normally you find out what is missing and fill in the holes until you get no more undefined references. Any transitive dependencies that do not get flagged as undefined refs will represent packages that are available.

That's also a key to understanding, though, there's no concept of "available jars" or "provided jars" in OSGi, there's just "exposed packages". Any packages not exposed are going to represent dependencies that you have to satisfy.

Looking for jars can mess you up because I could add commons-codec into my bundle, but I could also export the packages thus exposing commons-codec without you finding a jar anywhere.









Come meet me at the 2017 LSNA!