掲示板

Some doubts about Bnd.Bnd and Build.gradle

thumbnail
6年前 に Jon Ander Gonzalez によって更新されました。

Some doubts about Bnd.Bnd and Build.gradle

Junior Member 投稿: 28 参加年月日: 17/05/30 最新の投稿
Hi friends:

i have problems to know the version that i have to write in the dependencies in the build.gradle.

for example Liferay Journal API in the Liferay DXP src Sp.3 yo can find this bnd.bnd. with version 2.1.2
Bundle-Name: Liferay Journal API
Bundle-SymbolicName: com.liferay.journal.api
Bundle-Version: [b]2.1.2[/b]


but for example when Journal-Content-web wants to use this library, add this:

	provided group: "com.liferay", name: "com.liferay.journal.api", version: [b]"2.0.0"[/b]


Why are the versions different?
The version of the jar is the same of the osgi module?


Thanks in advanced.
thumbnail
6年前 に David H Nebinger によって更新されました。

RE: Some doubts about Bnd.Bnd and Build.gradle

Liferay Legend 投稿: 14916 参加年月日: 06/09/02 最新の投稿
Jon Ander Gonzalez:
Why are the versions different?


So normally as developers when we use libraries we always try to start with the latest and greatest as that means we get (hopefully) bug-free code.

When it comes to OSGi API jars, we do things differently. We want to pick the oldest possible version that has the API definition we need, but not a newer one.

So journal-content-web, for example, uses version 2.0.0 of the API jar because it is perfectly happy with the 2.0.0 interface definitions. Note that the API version has no real association with the service implementation jar (in your case you see the 2.1.2 version).

During bundle resolution of journal-content-web, OSGi is going to look for an implementation from the listed version to the next major release. So OSGi is going to try to find a version in the range of (2.0.0,3.0.0] (that's 2.0.0 thru 3.0.0 but excluding 3.0.0 itself). So whether 2.0.1 or 2.1.2 is deployed, journal-content-web will be happy with it and will resolve and start.

If you use a limited version like 2.1.2, then that becomes the lowest supported version and OSGi will look for an implementation from (2.1.2,3.0.0].

As long as the Liferay you're deploying to has 2.1.2 or newer, then it is no problem.

But, if you are running 7.0.4 but your production environment is, say, 7.0.2 it is a good chance that it will not have 2.1.2 and therefore your module will not resolve or start. So you get in this weird scenario where everything works fine for you but not in your upper lanes.

And this is quite common, at least for me. My dev environment is always at the latest version, but I don't always have control over when the production systems are updated.

One exception, as I mentioned, is picking the minimum version you can get away with. This doesn't mean always use 2.0.0, sometimes you may be forced to pick a higher version. For example, I recently was building some code against the Configuration classes and was trying to use the com.liferay.portal.kernel.settings.SystemSettingsLocator to get to a global configuration instance. Worked fine in my environment, I was correctly using com.liferay.portal.kernel version 2.0.0 and everything was good in my environ.

However, when I pushed the code to test, the module failed, I got a ClassNotFoundException on SystemsSettingsLocator. See OSGi had determined that the version of the kernel API jar was there and was greater than 2.0.0 so therefore my code could start, but this class was not available in older versions of the kernel API jar.

At this point I faced a choice - I could find what version SystemSettingsLocator was added to the kernal API jar (2.31.0 if I remember correctly) and set that as my minimum version, or I could change my code so I didn't use the SystemSettingsLocator class.

If I changed the version to 2.31.0, I could continue to use SystemSettingsLocator, but I would not be able to deploy to an older version of Liferay.

I chose to refactor my code rather than impose a version requirement, but I am usually developing generally and not targeting a closed environment. There are legitimate cases to use the 2.31.0 to ensure the module is deployed to a compatible environment.

All of this said, I think in general this is like and edge case. Most of the time sticking with the 2.0.0 is definitely the choice you want to make.







Come meet me at Devcon 2017 or 2017 LSNA!
thumbnail
6年前 に Jon Ander Gonzalez によって更新されました。

RE: Some doubts about Bnd.Bnd and Build.gradle

Junior Member 投稿: 28 参加年月日: 17/05/30 最新の投稿
thank you very much for the clarification, David. I have some issues, for example in the util-java.jar the portal version is 2.3.0 but in the maven repository the latest version is 2.2.2 and in the url: "https://cdn.lfrs.sl/repository.liferay.com/nexus/content/groups/public" aswell. is there a private liferay repository?

i have this problem with my code:
org.osgi.framework.BundleException: Could not resolve module: net.bizkaia.bipo.accessibility.web [566]_  
Unresolved requirement: Import-Package: net.bizkaia.bipo.accessibility.model; version="[1.0.0,2.0.0)"_    -> 
Export-Package: net.bizkaia.bipo.accessibility.model; bundle-symbolic-name="net.bizkaia.bipo.portlet.accessibility.api"; 
bundle-version="1.0.0"; version="1.0.0"; 
uses:="com.liferay.expando.kernel.model,com.liferay.portal.kernel.annotation,com.liferay.portal.kernel.bean,com.liferay.portal.kernel.exception,com.liferay.portal.kernel.model,com.liferay.portal.kernel.service,com.liferay.portal.kernel.util"_       
net.bizkaia.bipo.portlet.accessibility.api [567]_    Unresolved requirement: Import-Package: com.liferay.util.portlet; version="[7.0.0,8.0.0)"_ [Sanitized]


in the past i solved putting: compileOnly group: "com.liferay.portal", name: "com.liferay.util.java", version: "2.0.0" (the latest maven version 2.2.2. it doesnt work too) in the build gradle but now it doesnt work and i dont know why, in theory this jar has 7.0.0 version and its compatible with version="[7.0.0,8.0.0)". I want to use PortletProps class in my code.
what is happening?
thumbnail
6年前 に Jon Ander Gonzalez によって更新されました。

RE: Some doubts about Bnd.Bnd and Build.gradle

Junior Member 投稿: 28 参加年月日: 17/05/30 最新の投稿
David H Nebinger:
thank you very much for the clarification, David. I have some issues, for example in the util-java.jar the portal version is 2.3.0 but in the maven repository the latest version is 2.2.2 and in the url: "https://cdn.lfrs.sl/repository.liferay.com/nexus/content/groups/public" aswell. is there a private liferay repository?

i have this problem with my code:
org.osgi.framework.BundleException: Could not resolve module: net.bizkaia.bipo.accessibility.web [566]_  
Unresolved requirement: Import-Package: net.bizkaia.bipo.accessibility.model; version="[1.0.0,2.0.0)"_    -> 
Export-Package: net.bizkaia.bipo.accessibility.model; bundle-symbolic-name="net.bizkaia.bipo.portlet.accessibility.api"; 
bundle-version="1.0.0"; version="1.0.0"; 
uses:="com.liferay.expando.kernel.model,com.liferay.portal.kernel.annotation,com.liferay.portal.kernel.bean,com.liferay.portal.kernel.exception,com.liferay.portal.kernel.model,com.liferay.portal.kernel.service,com.liferay.portal.kernel.util"_       
net.bizkaia.bipo.portlet.accessibility.api [567]_    Unresolved requirement: Import-Package: com.liferay.util.portlet; version="[7.0.0,8.0.0)"_ [Sanitized]


in the past i solved putting: compileOnly group: "com.liferay.portal", name: "com.liferay.util.java", version: "2.0.0" (the latest maven version 2.2.2. it doesnt work too) in the build gradle but now it doesnt work and i dont know why, in theory this jar has 7.0.0 version and its compatible with version="[7.0.0,8.0.0)". I want to use PortletProps class in my code.
what is happening?


Any suggestion?