OSGi, Gradle, Shadow and nosebleeds

[Chris Rankin]

Hi all,

I finally managed to convert a shaded jar into an OSGi, bundle, but it was a lot trickier than I thought:

- Adding a BundleTaskConvention to the shadowJar task had no effect.

- The Bundle task expects its inputs to be a set of files, and not a jar.
- The classes in sourceSet.main.output have not been shaded yet and so are unsuitable for bundling.

I resolved this by feeding Bundle with

shadowJar.map { zipTree(it.archiveFile) }

but even so, the contents of the original shadowJar MANIFEST.MF were all lost. How do people typically package shaded jars as OSGi bundles please? Is there an existing pattern or Gradle task to do this? Or do people simply not do this kind of thing any more?

Thanks,

Chris

[BJ Hargrave]

You don't need to shade in OSGi. OSGi provide type encapsulation through visibility. If a bundle does not export a package, then other bundles can't import or see it.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/7be02beb-90c1-4985-bd99-c9c2cbd3ff95n%40googlegroups.com.

--

BJ

[Chris Rankin]

On Mon, 31 Aug 2020 at 12:50, BJ Hargrave <b...@bjhargrave.com> wrote:
> You don't need to shade in OSGi. OSGi provide type encapsulation through visibility. If a bundle does not export a package, then other bundles can't import or see it.

Sure, if the entire world were using OSGi :-). But this jar would also
need to be usable in a non-OSGi environment, and I think that
providing two jars might complicate things even further.

But even so, my root problem here was "bundling" an existing jar
rather than a set of classes.

Cheers,
Chris

[BJ Hargrave]

So I guess I would have a task which unzips the input jar into a folder as a predecessor step to the bundle task which uses that folder as from input.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAK2bqVJToYivOEzTN8wuhi4n9xRy3fFGts-odiU1qwPQNAvxhQ%40mail.gmail.com.

--

BJ

[Chris Rankin]

On Mon, 31 Aug 2020 at 13:34, BJ Hargrave <b...@bjhargrave.com> wrote:
> So I guess I would have a task which unzips the input jar into a folder as a predecessor step to the bundle task which uses that folder as from input.

OK, thanks. So it sounds like you concur with the

shadowJar.map { zipTree(it.archiveFile) }

Gradle "hocus pocus" approach, and then sorting out MANIFEST.MF afterwards.

Cheers,
Chris

[Raymond Auge]

Another approach could be to split the shadow operation and the OSGi operation into two different projects. Then putting the shadow'd project on the buildpath of the OSGi project removes all of the hocus pocus.

- Ray

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-users/CAK2bqV%2B58%3DMhJWmxFQQcwc%3D%2ByYZ12GqRrA8gnHN-rAxuz4hYYQ%40mail.gmail.com.

--

Raymond Augé (@rotty3000)

Senior Software Architect Liferay, Inc. (@Liferay)