I have two OSGi bundle with same name. But there versions are different. Suppose one bundle has version 1.0 and another one is 2.0 . as 2.0 is higher version so its priroty will be first. But I want to use a piece of code from bundle 1.0 also. How can I achieve this ??
The bundle version is not reall important when OSGi selects where to import a package from. The only limitation there is that you can not install two bundles with the same symbolic name and version.
What you need is to version the packages the bundles export. Each of the packages can be exported with a different version if you want. In the client bundle you can then import each needed package with an allowed version range.
So bundle 1.0 can export package a in version 1.0 and package b in version 1.1.
Bundle 2.0 can export package a in version 2.0 and package b in version 1.2.
In the client bundle you could then
import package a with a version range of [1.0,2.0) -> would resolve to package a from bundle 2.0
import package b with a version range of [1.1,1.2) -> would resolve to package b from bundle 1.0
You can only do this on the package level though. So you can not access classes that are in the same package from different bundles - at least not without fiddling with classloader... which you should avoid.
Related
I have a question about package versioning in Golang projects.
After creating a tag, for example v1.0.0.
I can pull this tag using go get pkg_address/#v1.0.0 which is fine and works correctly.
But when I see Go packages in github I see that it's written in their installation section to install the package using pkg_address/v1.0.0.
In fact they are pulling a specific version without #.
And they even import packages in their code using pkg_address/v1 even though there is no directory called v1 in their project.
I get error if I install a specific tag without #.
Even after using pkg_address/#v1.0.0 my import paths don't change and I don't need to specify version in my import paths.
For example you install echo package using this command go get github.com/labstack/echo/v4 and you import the package using the v4 tag in your code and there is no v4 in the package directories.
How can I do versioning like github packages?
P.S. I'm using gitlab.
This is a module path naming convention and it applies to major versions higher than v1.
https://go.dev/ref/mod#module-path
If the module is released at major version 2 or higher, the module path MUST end with a major version suffix like /v2. This may or may
not be part of the subdirectory name. For example, the module with
path golang.org/x/repo/sub/v2 could be in the /sub or /sub/v2
subdirectory of the repository golang.org/x/repo.
https://go.dev/ref/mod#major-version-suffixes
Starting with major version 2, module paths MUST have a major
version suffix like /v2 that matches the major version. For example,
if a module has the path example.com/mod at v1.0.0, it must have the
path example.com/mod/v2 at version v2.0.0.
And echo's v4 module path can be found here.
I am generating conda dependencies YAML and I don't entirely understand the information that is presented there. In pandas=1.2.4=py38h1abd341_0 I know that it is pandas 1.2.4 version but what is py38h1abd341_0?
That is the build string, documented here. The py38 indicates the package is built for Python 3.8. The 8 characters after that are a hexidecimal hash of the package dependencies, to differentiate variants that can be used to satisfy different dependencies (think glibc on Linux or the MSVCRT on Windows).
After the underscore is the build number, which is incremented when the package recipe changes but the package version does not change.
The new hash was introduced with Conda Build 3
I want to use Jena OSGi 3.0.0 version in Felix 2.0.3, but when I install the bundle I get the exception:
Unresolved constraint in bundle org.apache.jena.osgi [1]: package; (&(package=org.apache.commons.cli)(version>=1.3.0)(!(version>=2.0.0)))
Does this mean that the package org.apache.commons.cli is not contained in the jena-osgi bundle?
Any ideas how to solve this issue?
Yes, this means that the jena-osgi bundle imports package org.apache.commons.cli. You need to install the bundle that exports this package.
Funnily enough, this package is exported by a bundle named org.apache.commons.cli which you can get from Maven Central:
http://search.maven.org/#artifactdetails|commons-cli|commons-cli|1.3.1|jar
I have two bundles A and B.
A exports package packA
B imports packA
This means that B depends on A, but only to get one package. Now A has further dependencies that are not fulfilled, so in the running system bundle A is only installed but not resolved.
Can Bundle B become resolved in the running system? It doesn't need bundle A, only one of its packages.
Yes. A bundle must be resolved to export or import packages or even have a class loader.
I am Unable to run slingshot sample , apache sling i have followed these steps
Click here!
the package got installed but it didn't get activated. The detail collapsed view of bundle shows
org.apache.sling.api.resource,version=[2.2,2) -- Cannot be resolved
Your bundle import org.apache.sling.api.resource,version=[2.2,2) was not resolved.
Assuming that your sling installation is running, you should verify if the package org.apache.sling.api.resource is either not exported or exported in the wrong version.
If the package is present then adapt your import.
You didn't indicate how you built or started the Sling instance where you installed the Slingshot bundle.
I just tried with a Sling launchpad built from the launchpad/builder folder of the Sling source code, the Slingshot bundle starts without problems and the /slingshot/albums.html path mentioned in the sample's README.txt works.