We are using Karaf 4.1.7, and while creating Karaf distribution we package Jackson core 2.9.7 bundle within karaf system directory.
And in one of our applications we use Jackson-core 2.9.2 bundle which is added to a feature. When we install this feature using Karaf FeatureService.installFeature(featureName) it overrides the existing 2.9.7 bundle instead of adding a new bundle. We were expecting that both the versions would be available or coexist.
And when I type 'list' command can see the overridden bundle version 2.9.2 instead of 2.9.7. And another strange thing is when we checked through bundleContext.getBundles() I still see 2.9.7 bundle. And in the bundle cache I see version0.1 folder in which the new 2.9.2 jar is present.
Could any one provide pointers on how to resolve this or what we are missing here. Please let us know if you need more details.
Thank You,
Dheeraj
Both jackson-core bundles of different versions should be installed in the karaf instance and likely get resolved. It does not get overidden. If you call the list (which gets resolved to bundle:list by default) shell command it does print out all bundles having an OSGi start level equal or greater 50. The first line does shows this:
karaf#root()> list
START LEVEL 100 , List Threshold: 50
So the first installed bundle might get skipped. Decreasing the bundle start level threshold to 0 via command line
bundle:list -t 0
all installed bundles of the karaf instance will get listed.
Regarding the result of bundleContext.getBundles(): only one version of another bundle can be bound and thus the first/original bound bundle version gets listed for the certain bundle (context).
Related
I want to have a rpm package build with Copr1. My current build target list is Fedora 35, 36, rawhide and Centos 7 and Stream 8. I have not yet created the copr project.
Compiling on one of my machines, the package builds successfully on the Fedora variants with mock. The problem is that on Centos variants one of the build dependencies and some of its dependencies are not available. I have found appropriate srpm files and compiled them on one of my machines with the Centos Stream 8 (one of them required two custom patches). With those custom dependencies I am able to successfully compile the original package.
So just to be clear, the problem is that the spec file contains for example
BuildRequires: libsomething
where libsomething is available as a plain upstream package in some of the build targets while needs an additional custom repo for some other build targets.
The FAQ says the following about dependencies:
Can I depend on other packages, which are not in Fedora/EPEL?
Yes, they just need to be available in some yum repository. It can either be another Copr repo or a third-party yum repo (e.g jpackage). Click on “Edit” in your project and add the appropriate repositories into the “Repos” field. Packages from your project are available to be used at build time as well, but only for the project you are currently building and not from your other projects.
But this sounds like an all or nothing approach, and I absolutely do not want to override the already existing upstream packages, only provide them when they are missing.
So what strategy do people use to handle this?
Update: I have now created copr projects and made some attempts at building (after resolving dependencies of dependencies in several levels), but the problem is as I describe above. If I add copr://hlovdal/projectname as a build dependency then epel-8-x86_64 compiles fine because it is provided with the missing dependencies while fedora-35-x86_64 fails because the repository does not have any fedora packages. If I remove the repo epel fails while fedora succeeds.
I also attempted to add the base url from the corresponding /etc/yum.d.repo file, and only hardcode epel instead of $distname hoping that the fedora builds would just ignore non-existing/wrong repo setting, but the build does not like that and still fails.
1 Copr is Fedora's freely available build system.
I have a CMake project to build multiple shared libraries and tools, most of these under subdirectories:
add_directory(libFirst)
add_directory(libSecond)
add_directory(myTool)
# etc...
The install(TARGET "someTarget" COMPONENT "someTarget" ...) rules are in the respective subdirectory/CMakeLists.txt files.
I would like to generate Debian packages for all of these using a make package command from the build directory. I have CPACK_DEB_COMPONENT_INSTALL set to ON.
The problem I'm facing, is that not all of the targets have the same VERSION and/or SOVERSION. For example, libFirst is at version 1.0.0.0 and libSecond is version 4.3.0.0. This means that the generated packages should also have different version, but the only way I've found to specify the version is to specify the CPACK_PACKAGE_VERSION_MAJOR, CPACK_PACKAGE_VERSION_MINOR and CPACK_PACKAGE_VERSION_PATCH variables (and perhaps the internal CPACK_PACKAGE_VERSION variable), which set the version for all generated packages.
Is there a way to set package versions per-component, for example by setting some variables similarly to the other CPACK_COMPONENT_<COMPONENT>_* or CPACK_DEBIAN_<COMPONENT>_* variables?
I don't think this is possible at the moment but I have created a merge-request (https://gitlab.kitware.com/cmake/cmake/merge_requests/2305) which provides this functionality.
I hope it will get approved but in the meantime you can locally change your CPackDeb.cmake as shown in this diff: https://gitlab.kitware.com/cmake/cmake/merge_requests/2305/diffs. The default location of that file is in /usr/share/cmake/Modules/CPackDeb.cmake.
I've have been searching and digging around but for the life of me I can not find which version of LESS is included with AEM 6.1 (or 6.2). I know that CQ (AEM) 5.6.1 uses LESS 1.3.3 but I'd like to know if the version was updated with AEM 6.
-The compilation of the LESS logic is done on the server side using Rhino (a Javascript compiler for Java) and LESS
-If you go to your Felix console and look under Bundles you should find one called "Adobe Granite UI Clientlibs - Less Compiler(com.adobe.granite.ui.clientlibs.compiler.less)".
-To get to the JAR file for this bundle you will need to note the number next to it in the console.
(In my case it is bundle number 193.)
-Assuming the bundle number is 193, on your file system go to "/crx/quickstart/launchpad/felix/bundle193/version0.0"
-If you open bundle.jar you will find version of LESS.
(For extracting JAR file you can use jd-gui.exe jar extractor.)
-In AEM 6.1 the current version of LESS is-1.7.5
The version of LESS is included with AEM 6.1 is -1.7.5
To get to the JAR file for this bundle you will need to note the number next to it in the console in my case it is bundle number 74.
Assuming the bundle number is 74, on your file system go to "/crx/quickstart/launchpad/felix/bundle74/version0.0"
When building the project from command line using mvn clean install everything builds without any issues.
When running some tests that use precompiled C libraries from IntelliJ, tests fail with java.lang.UnsatisfiedLinkError
I may be completely off here, but does IntelliJ not see the .so file? Is so, how can it be added please?
Shared library fails to load with UnsatisfiedLinkError if:
it's not in the working directory configured in the test run configuration.
it's not in PATH environment (on Mac Terminal and GUI apps have different environment, see this answer). Run IDEA from the Terminal open -a /Applications/IntelliJ\ IDEA\ 12.app/ to make environment the same.
it's not in the location specified using -Djava.library.path VM option.
.so depends on some other library that is not found for any of the 1-3 reasons (or the dependency of that dependency is not found, etc).
I have a RCP project where I cannot fix a NoClassDefFoundError: One plugin depends on another plugin. The plugin-dependencies are set in the manifest, packages exported, and there is no error at compile time. Both plugins are in the product dependencies and visible in the installation details of the product.
But when I run the application I get a java.lang.NoClassDefFoundError when the one plugin wants to use a class from the other plugin.
Any hints how to find the reason for this are greatly appreciated.
Thanks,
Michael
I found the problem: I created the plugin which could not be loaded from an existing Java project. And somehow I deleted the "." in the entry Bundle-classpath in the plugin manifest (the plugin has some jars which -> so lib/xyz.jar was in the Bundle-classpath entry but not the ".").
For the class-loader of the bundle the "." means to search for classes from the root path of the bundle (or something like that), so it could not find the classes. However, there were no errors in the IDE so it was hard to find.
Is the configuration for running the application correct i.e. all dependencies are also put in the running configuration?