TIP: run maven-bundle-plugin on <packaging>jar</packaging>

[Steinar Bang]

Personally, I prefer this, to using <packaging>bundle</packaging>:
https://github.com/steinarb/authservice/blob/master/pom.xml#L387

[Tatu Saloranta]

On Thu, Oct 10, 2019 at 10:49 AM Steinar Bang <s...@dod.no> wrote:
>
> Personally, I prefer this, to using <packaging>bundle</packaging>:
> https://github.com/steinarb/authservice/blob/master/pom.xml#L387

Could you expand a little bit on this? Would this help by reducing
need to indicate artifact type (by being defined in one of uber-parent
poms)? Or is there some downside(s) to indicating packaging type in
pom.xml (aside from one extra line)?

-+ Tatu +-

[Steinar Bang]

>>>>> Tatu Saloranta <ta...@fasterxml.com>:

> Could you expand a little bit on this? Would this help by reducing
> need to indicate artifact type (by being defined in one of uber-parent
> poms)? Or is there some downside(s) to indicating packaging type in
> pom.xml (aside from one extra line)?

I know I've had some tools confused by packaging bundle, but I can no
longer remember which ones. I think it was earlier versions of eclipse
and m2e, but I can't remember for sure.

When packaging became jar, all of the issues went away. I don't think
it is an issue any longer, but once I got it working I thought it looked
tidier.

(not a big thing. Today either way works)

[Tatu Saloranta]

Ah ok.

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

-+ Tatu +- 

 

[Steinar Bang]

>>>>> Tatu Saloranta <tsalo...@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)

[Tatu Saloranta]

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 +-

[Steinar Bang]

>>>>> Tatu Saloranta <ta...@fasterxml.com>:

> 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.

Integration tests verifying OSGi bundle loading, are possible to do
using the pax exam framework
https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/overview

However: This worked fine for me during the java 8 days. Unfortunately
in java 9+ I've had so many problems getting the tests to work that I
eventually ended up disabling the integration tests. Karaf have working
pax exam tests in java 9+ and I have tried replicating their setup, but
so far without success (I also need to have the integration tests
working on travis-ci).

I'm hoping the pax exam/java 9+ stuff will stabilize at some point, so I
can reenable the tests...:-/

So in short: integration tests like what you're requesting should be
possible at some future time, but perhaps not right now.

[Tatu Saloranta]

On Fri, Oct 11, 2019 at 11:02 AM Steinar Bang <s...@dod.no> wrote:
>
> >>>>> Tatu Saloranta <ta...@fasterxml.com>:
>
> > 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.
>
> Integration tests verifying OSGi bundle loading, are possible to do
> using the pax exam framework
> https://ops4j1.jira.com/wiki/spaces/PAXEXAM4/overview
>
> However: This worked fine for me during the java 8 days. Unfortunately
> in java 9+ I've had so many problems getting the tests to work that I
> eventually ended up disabling the integration tests. Karaf have working
> pax exam tests in java 9+ and I have tried replicating their setup, but
> so far without success (I also need to have the integration tests
> working on travis-ci).

Java 9+ has been quite a challenge all around...

FWIW, I would be perfectly happy to only have tests that work on JDK
8, however, given that as things are all Jackson components and
branches (including master (3.0)) are built on and for Java 8.

> I'm hoping the pax exam/java 9+ stuff will stabilize at some point, so I
> can reenable the tests...:-/
>
> So in short: integration tests like what you're requesting should be
> possible at some future time, but perhaps not right now.

Ok. We'll get what we can. And when we know what would be ideal it's
easier to see opportunities as they arise.

-+ Tatu +-