According to a comment to answer related to BND, it does not export packages named ".impl.":
ok, never mind. I found that some packages were named ".impl." in the code, and BND does not export them by default. I renamed the packages and this solved this particular problem. look like the error message wasn't too specific. – Alex Sep 12 '11 at 19:20
Is there a reliable way to make BND always export those packages for wildcard exports like foo.*?
That is not a Bnd thing. That is a maven-bundle-plugin thing. maven-bundle-plugin configures Bnd with some behavior.
Related
Suppose you're developing some library, myproj, using CMake for build configuration; supporting the cmake --install (using install() commands); and supporting use of myproj with CMake config mode, i.e. by making relevant .cmake files accessible to dependent projects.
Now, ,given an install root directory - where should I install my project's configuration .cmake files? Is there an idiomatic standard(ish) location?
Sorush Khajepor's R&D blog suggests ${LIB_INSTALL_DIR}/cmake/myproj - and it's the newest.
Foonathan's blog suggests placing the config .cmake files in ${LIB_INSTALL_DIR}/. So does Falkor's blog.
The documentation page for the CMakePackageConfigHelpers module suggests: ${LIB_INSTALL_DIR}/myproj/cmake.
What's the most popular/idiomatic choice? And what are its pros and cons relative to the other ones?
I advocate for setting a cache variable to override this and defaulting it to <LIBDIR>/cmake/ProjName (as you suggest in your answer):
cmake_minimum_required(VERSION 3.21) # for saner CACHE variables
project(ProjName VERSION 0.1.0)
# ...
include(GNUInstallDirs)
include(CMakePackageConfigHelpers)
set(ProjName_INSTALL_CMAKEDIR "${CMAKE_INSTALL_LIBDIR}/cmake/ProjName"
CACHE STRING "Path to ProjName CMake files")
install(EXPORT ProjName_Targets
DESTINATION "${ProjName_INSTALL_CMAKEDIR}"
NAMESPACE ProjName::
FILE ProjNameConfig.cmake
COMPONENT ProjName_Development)
write_basic_package_version_file(
ProjNameConfigVersion.cmake
COMPATIBILITY SameMajorVersion)
install(FILES
"${CMAKE_CURRENT_BINARY_DIR}/ProjNameConfigVersion.cmake"
DESTINATION "${ProjName_INSTALL_CMAKEDIR}"
COMPONENT ProjName_Development)
I wrote a blog post with an expanded version of this a while back: https://alexreinking.com/blog/building-a-dual-shared-and-static-library-with-cmake.html
In general, setting an install() destination to anything other than "${SOME_CACHE_VARIABLE}" is bound to cause headaches for some package maintainer. Where GNUInstallDirs doesn't provide a valid configuration point, you must create your own.
I'll argue in favor of ${LIB_INSTALL_DIR}/cmake/myproj.
If you're installing to some library-specific install location, e.g. /opt/myproj - then it doesn't really matter all that much anyway. But think about what happens when you install to, say, /usr/local.
If you place the scripts in ${LIB_INSTALL_DIR}, that library now becomes full of foo-config.cmake and foo-version-config.cmake, instead of just library files (and some subdirs). Less fun for browsing and searching.
If you place the scripts in ${LIB_INSTALL_DIR}/myproj/cmake, then - the same thing happens, but with per-project subdirs instead of sets of files. Better, perhaps, but instead - why don't we just replace the path elements of myproj and cmake, and that way we would get a cmake/ directory with many subdirs, instead. That's cleaner and more convenient IMHO.
If I run :
pnpm install eslint
Then my node_modules directory ends up containing:
node_modules
.bin/
.pnpm/
#eslint/eslintrc
eslint
eslint-scope
eslint-utils
eslint-visitor-keys
.modules.yaml
I can't seem to find anything particularly special about eslint or its dependencies that would cause that, but maybe I'm not looking at the right place.
The only thing that makes sense is that pnpm is hoisting these dependencies at the top solely based on the fact that they are prefixed by the name of the package I actually installed. That really doesn't seem right though.
What am I missing here?
In case someone else hits that head-scratcher:
The answer is simply that the default value of public-hoist-pattern contains *eslint*, so all eslint-related modules are special-cased.
see: https://pnpm.io/npmrc#public-hoist-pattern
I'm following Maven's Standard Directory Layout for my project.
Is there a preferred directory to put my checkstyle.xml file? I've seen it on at least 3 possible locations:
src/main/resources/checkstyle.xml
src/main/checkstyle/checkstyle.xml - Example: Joda-Time
src/checkstyle/checkstyle.xml - Example: Spring Boot
Since this is mostly a file for developers, the first option gives me doubts. Would it make sense to include checkstyle.xml into the JAR file?
Thanks,
Fede
Putting checkstyle.xml in src directory doesn't really make sense, as it is not part of source code.
The most common convention I've observed in my projects is putting it into config/checkstyle/checkstyle.xml. Thousands of projects use it (filename:checkstyle.xml path:config/checkstyle) and Gradle uses this location by default.
Inside ee.j2se-1.8 the package org.w3c.dom is included.
org.osgi.framework.system.packages = \
...
org.w3c.dom,\
...
org.osgi.framework.bootdelegation = \
...
org.w3c.*,\
org.xml.*,\
....
The bundle xml-apis_1.4.1.20140905-131237.jar contains the same package org.w3c.dom, but with one important class more ... ElementTraversal.class more.
So here my questions...
How can I provide the missing class inside my Equinox OSGi runtime?
You are suffering from the fact that people do not take packages seriously. We have a similar problem in the jta API. The version delivered by the VM is not identical to the version that is delivered as a special package.
The solution is to include the JAR with the extra packages on the class path where the framework resides. It looks like you're using bnd (good!) so this would look like:
-runpath: xml-apis__xml-apis;version="[1.4.1,2.0.0)"
If this had been a bundle with proper exports then you would have automatically gotten its exports as system packages. Looking at the packages in this bundle it seems all packages are already in the standard exports of the VM. However, if you have packages int his JAR that are not exported by the VM then you can add them as follows:
-runsystempackages: javax.xml.foo
I have seen two different syntax in Karaf to add a repo, e.g.,
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/
xml/features
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/
xml
Can someone explain the difference between the 2? I believe they are both referring to a features file but they are in different locations?
features:addurl mvn:org.apache.camel/camel-example-osgi/2.10.0/xml
Doesn't actually work for me. BUT I think can break down what is happening.
mvn:org.apache.camel/camel-example-osgi/2.10.0 is a maven URl with an implicit 'type' and 'classifier'. The type is 'jar' and the classifier is empty, by default. Therefore it resolves to a file called camel-example-osgi-2.10.0.jar. (artifactId-version[-classifier].type)
In this case:
mvn:org.apache.camel/camel-example-osgi/2.10.0/xml is a type of 'xml' and no classifier. This resolves to a file called camel-example-osgi-2.10.0.xml, which doesn't exist.
mvn:org.apache.camel/camel-example-osgi/2.10.0/xml/features is a type of 'xml' and a classifier of 'features'. This, then, resolves to a file called camel-example-osgi-2.10.0-features.xml . We can look on the server and see that this file exists: http://repo1.maven.org/maven2/org/apache/camel/camel-example-osgi/2.10.0/
I can't find good documentation for it but 'classifier' adds the -$classifier to the filename. This is how some maven artifacts have a classifier of -jdkN and -jdkM or -jdbc4 or -jdbc3 on them.
References: https://ops4j1.jira.com/wiki/display/paxurl/Mvn+Protocol
http://maven.apache.org/pom.html#POM_Relationships