On Fri, Oct 11, 2019 at 10:09 AM Steinar Bang <s...@dod.no> wrote: > > >>>>> Tatu Saloranta <tsalora...@gmail.com>: > > > The reason Jackson components are defined to be released as bundles is > > because AFAIK that is what is required for proper functioning within OSGi > > container. I was under impression this is not true for regular jars, > > although relevant metadata can of course be included under META-INF/MANIFEST > > All that OSGi containers care about is that what it loads have the > format of a jar file with a META-INF/MANIFEST.MF that contains the > headers required for an OSGi bundle. > > Creating an OSGi compliant MANIFEST.MF can be accomplished in various > ways > 1. Adding the headers manually using the <manifestEntries> > configuration of the maven-jar-plugin (a lot of work and kind of > fragile, but I've seen it used) > 2. Using the maven-bundle-plugin (the most common way) > 3. Interactively in the eclipse MANIFEST.MF editor (possibly how most > of the eclipse bundles are created...?) > 4. By alternatives to the maven-bundle-plugin (I have seen some > mentioned earlier, but I was unable to google them up today, so I'm > guessing they are mostly dead) > > Using the maven-bundle-plugin to create an OSGi compliant MANIFEST.MF > can be done, by: > 1. Using <packaging>bundle</packaging> (what jackson does) > 2. Using <supportedProjectTypes> in the maven-bundle-plugin config, to > make it run on jar projects (what I do) > 3. Binding maven-bundle-plugin to a phase in the maven build (not > commonly done anymore) > > As for actually loading the bundle into the OSGi runtime there are > various ways > 1. Earlier versions of the eclipse target platform consisted of a > directory containing jar files with names based on the > bundle-symbolic-name (an OSGi MANIFEST.MF header), and the version > (a regular MANIFEST.MF header) > 2. Current versions of the eclipse target platfom consist of XML files > defining what jar files should be loaded as OSGi bundles > 3. Apache Karaf has a heap of ways of getting bundles into the OSGi > runtime, off the top of my head, here are some of them: > 1. Loading bundles interactively from the karaf console command > line, using the bundle's maven coordinates (maven central and a > couple of other apache repos are built-in to karaf, other maven > repos, eg. a local nexus installation can be configured in). > Here's an example of a karaf console bundle install, picked > completely at random...:-) > bundle:install > mvn:com.fasterxml.jackson.core/jackson-annotations/2.10.0 > 2. Loading bundles using features (this is a higher level > dependency resolution mechanism. To use an analogy: if bundles > are .deb packages, then karaf features are debian APT) > Both other feature files and bundles are referred to by maven > coordinates > 3. Dropping bundles into a directory that karaf scan and then load > all jar files dropped into that directory > 4. kar files, which are zip files containg an XML feature > definition and all jar files required by the feature file > (ie. it doesn't require access to a maven repository) > 5. (there are more but the above are the ones I could remember) > > As to the actual file type supported when loading bundles: > 1. AFAIK all OSGi implementations support jar files with an OSGi > compliant MANIFEST.MF > 2. karaf supports both jar files and war (web archive) files > 3. earlier versions of the eclipse equinox OSGi runtime supported > "directory bundles" that are directories consisting of an unpacked > jar files > > For playing around with loading OSGi bundles I recommend following the > karaf quick start guide (basically: download and unpack the most recent > karaf binary as a tar.gz or .zip file, cd-ing into the unpack directory > and running the command "bin/karaf") > https://karaf.apache.org/manual/latest/quick-start.html > > The karaf console is the command line that opens when starting karaf > interactively (it's also possible to ssh into a running karaf and do the > same commands there). > > commands to try > bundle:install (install a bundle by its maven coordinates) > feature:repo-add (install a karaf feature repository by its maven > coordinates) > feature:install (install a feature by its name) > bundle:list (lists installed bundles) > bundle:capabilities (lists the OSGi capabilities of an installed bundle)
Thank you for a thorough explanation. It does make sense that jar contents, only, make a difference. If use of `jar`, then, makes sense, I can definitely change that. But as is probably obvious from this (and our interchanges on issues), my OSGi knowledge is shallow since I do not use OSGi directly for anything, so learning has been limited to trying to figure out minimal set of information necessary to maintain Jackson build to produce working artifacts. Anyway, I think one important area that is lacking wrt OSGi bundles is that there is no testing to validate ability to properly load and resolve dependencies. It would be great to have some sort of integration testing to -- for example -- at least validate SNAPSHOT sets before publishing. With that I'd be less hesitant to merge bigger changes to build. Same is true for Java 9+ module info too, although getting bit better with Marc M's work on externally testing Jackson via JLink, downstream dependencies. -+ Tatu +- -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAL4a10j4hfER3CX9hXDTs5PmLaX-MqQsT%3DZ_YQ%3DYq7VNPq26Og%40mail.gmail.com.
