Re: [log4j] Is `bnd` a curse or a blessing?

[Gary Gregory]

The optional bit I hope can be solved by refactoring Maven modules to have
zero optional dependencies.

Gary

On Thu, Dec 7, 2023, 10:32 AM Piotr P. Karwasz 
wrote:

> Hi Gary,
>
> On Thu, 7 Dec 2023 at 15:46, Gary Gregory  wrote:
> >
> > Note that there is also the Maven moditect plugin but I don't know if it
> > deals with OSGi which brings up the issue of how much we should care
> about
> > OSGi (I don't know).
>
> We can disable JPMS descriptor generation in BND and switch to
> Moditect. From what I have seen it has less problems than BND 6.x,
> since it uses official tools like `jdeps` to compute module names and
> module dependencies.
>
> Optional dependencies **still** require a configuration override, but
> we probably can not do anything about that.
>
> Piotr
>

Re: [log4j] Is `bnd` a curse or a blessing?

[Volkan Yazıcı]

As I stated, I like `bnd` and am glad to see that its 7.x version will help
us lose some extra weight. And indeed we can fix some shortcomings I have
mentioned. Though my points still stand:

   1. We need extensive tweaking
   2. It doesn't always blend well (IDEs, `spring-boot:repackage`, etc.)
   3. Using `bnd` makes us an outlier in the ecosystem

"We can fix issue X by doing Y" is not the conversation I am after. I would
like to discuss its advantages that are so compelling enough to
outweigh its disadvantages.

On Thu, Dec 7, 2023 at 4:29 PM Piotr P. Karwasz 
wrote:

> Hi Volkan,
>
> I have supplied a PR to generate the service descriptors before Unit
> tests, but keep the module-info.class only in the JAR:
>
> https://github.com/apache/logging-parent/pull/75
>
> On Thu, 7 Dec 2023 at 15:41, Volkan Yazıcı  wrote:
> > *Bad: Programmatic configuration is not enough*
> >
> > We still need to tweak the generated `module-info.class` in several
> places.
> > We have hundreds of lines of manual treatment: you can simply search for
> > `
> Most of the additional configuration is due to:
>
>  1. BND 6.x does not support multi-release JARs, so the module names
> of **modern** dependencies are wrong. It is fixed in BND 7.x (requires
> JDK 17).
>
>  2. **Old** dependencies do not even have an `Automatic-Module-Name`
> and BND 6.x uses a different algorithm than Modulefinder#of to
> generate file-base module names. Peter Kriens fixed it in:
>
> https://github.com/bndtools/bnd/issues/5792
>
> which is due to be published in version 7.1.x. There is only one
> problem remaining: old dependencies **should** only be added as
> `static` (optional). We still need a manual override for that, but I
> don't think anybody will run `log4j-cassandra` on the module path.
>
> 3. Optional dependencies: we need to explicitly mark some imported
> packages as optional. This is an explicit decision of the BND Team:
>
> https://github.com/bndtools/bnd/issues/2713
>
> > *Bad: IDEs cannot discover services*
> >
> > Since `META-INF/services` is only available in the generated JAR, IDEs
> are
> > not able to discover services.
>
> This is fixed in my PR.
>
> > *Bad: `bnd:jar` attaches the generated files always at the end*
> >
> > Currently, if the `package` phase has multiple plugin executions,
> `bnd:jar`
> > removes the Maven Jar plugin execution and adds its own at the end (not
> > sure if that is fixable). E.g.: adding `spring-boot:repackage` in a naive
> > way, causes `spring-boot:repackage` to be executed before `bnd:jar` and
> > effectively missing all `bnd:jar`-generated files.
>
> That might be fixable with a PR. I could look into that.
>
> Piotr
>

Re: [log4j] Is `bnd` a curse or a blessing?

[Piotr P. Karwasz]

Hi Gary,

On Thu, 7 Dec 2023 at 15:46, Gary Gregory  wrote:
>
> Note that there is also the Maven moditect plugin but I don't know if it
> deals with OSGi which brings up the issue of how much we should care about
> OSGi (I don't know).

We can disable JPMS descriptor generation in BND and switch to
Moditect. From what I have seen it has less problems than BND 6.x,
since it uses official tools like `jdeps` to compute module names and
module dependencies.

Optional dependencies **still** require a configuration override, but
we probably can not do anything about that.

Piotr

Re: [log4j] Is `bnd` a curse or a blessing?

[Piotr P. Karwasz]

Hi Volkan,

I have supplied a PR to generate the service descriptors before Unit
tests, but keep the module-info.class only in the JAR:

https://github.com/apache/logging-parent/pull/75

On Thu, 7 Dec 2023 at 15:41, Volkan Yazıcı  wrote:
> *Bad: Programmatic configuration is not enough*
>
> We still need to tweak the generated `module-info.class` in several places.
> We have hundreds of lines of manual treatment: you can simply search for
> `https://github.com/bndtools/bnd/issues/5792

which is due to be published in version 7.1.x. There is only one
problem remaining: old dependencies **should** only be added as
`static` (optional). We still need a manual override for that, but I
don't think anybody will run `log4j-cassandra` on the module path.

3. Optional dependencies: we need to explicitly mark some imported
packages as optional. This is an explicit decision of the BND Team:

https://github.com/bndtools/bnd/issues/2713

> *Bad: IDEs cannot discover services*
>
> Since `META-INF/services` is only available in the generated JAR, IDEs are
> not able to discover services.

This is fixed in my PR.

> *Bad: `bnd:jar` attaches the generated files always at the end*
>
> Currently, if the `package` phase has multiple plugin executions, `bnd:jar`
> removes the Maven Jar plugin execution and adds its own at the end (not
> sure if that is fixable). E.g.: adding `spring-boot:repackage` in a naive
> way, causes `spring-boot:repackage` to be executed before `bnd:jar` and
> effectively missing all `bnd:jar`-generated files.

That might be fixable with a PR. I could look into that.

Piotr

Re: [log4j] Is `bnd` a curse or a blessing?

[Gary Gregory]

Note that there is also the Maven moditect plugin but I don't know if it
deals with OSGi which brings up the issue of how much we should care about
OSGi (I don't know).

Gary

On Thu, Dec 7, 2023, 9:41 AM Volkan Yazıcı  wrote:

> We use `bnd`, in particular, `bnd-maven-plugin`
> <
> https://github.com/bndtools/bnd/blob/master/maven-plugins/bnd-maven-plugin
> >
> to programmatically declare JPMS/OSGi module exports and service providers.
> Effectively, it generates `module-info.class`, `META-INF/services`, and
> (OSGi-related) `MANIFEST.MF` files. We also enhance this experience with
> `bnd-baseline-maven-plugin`
> <
> https://github.com/bndtools/bnd/tree/master/maven-plugins/bnd-baseline-maven-plugin
> >
> to enforce API compatibility between versions.
>
> I really like this! We use `@Export`, `@Version`, `@ServiceConsumer`,
> `@ServiceProvider`, etc. annotations in the code and `bnd` takes care of
> the rest. Though in the last couple of months, I have noticed several
> nuances that started to make me consider pros/cons of this convenience.
>
> *Good: Programmatic configuration*
>
> No need to manually populate `module-info.java`, `META-INF/services`,
> `MANIFEST.MF` files. Everything is in the code. Great!
>
> *Bad: Programmatic configuration is not enough*
>
> We still need to tweak the generated `module-info.class` in several places.
> We have hundreds of lines of manual treatment: you can simply search for
> `
> *Good: Absence of `module-info.java`*
>
> We use `bnd:jar` goal to populate `module-info.class` and attach it to the
> generated JAR. That is, there are no `module-info.java` and
> `module-info.class` files anywhere in the `target` folder. This makes life
> with IDEs a lot easier. IDEs simply work [not really, but I will talk about
> that later], since they think there are no JPMS descriptors to deal with.
>
> *Bad: IDEs cannot discover services*
>
> Since `META-INF/services` is only available in the generated JAR, IDEs are
> not able to discover services.
>
> *Bad: `bnd:jar` attaches the generated files always at the end*
>
> Currently, if the `package` phase has multiple plugin executions, `bnd:jar`
> removes the Maven Jar plugin execution and adds its own at the end (not
> sure if that is fixable). E.g.: adding `spring-boot:repackage` in a naive
> way, causes `spring-boot:repackage` to be executed before `bnd:jar` and
> effectively missing all `bnd:jar`-generated files.
>
> *Bad: Switching to `bnd:bnd-process` is not a cure either*
>
> Piotr and I have been thinking about switching from `bnd:jar` to
> `bnd:bnd-process`, since the latter will output everything generated to the
> `target` folder. Though this is not a cure without any side effects either.
> <
> https://github.com/apache/logging-parent/issues/69#issuecomment-1845373576
> >
>
> *Bad: Mismatch with the community and ecosystem*
>
> AFAIK, almost no major project uses `bnd-maven-plugin`. (This is more of a
> gut feeling, I haven't done an empirical study on this.) We are alone with
> our problems and others' solutions (catered against mainstream which
> hand-craft `module-info.java`, etc. files) don't work for us.
>
> *What now?*
>
> `bnd-maven-plugin` is a great tool with an active community. It delivers
> its promises perfectly. Though the surrounding ecosystem (IDEs,
> not-JPMS'ed-yet libraries, etc.) doesn't always play nice with it and
> eventually we end up tweaking it, *a lot*. I am sitting on the fence
> whether it is a curse or a blessing. I will appreciate your thoughts on the
> matter.
>

[log4j] Is `bnd` a curse or a blessing?

[Volkan Yazıcı]

We use `bnd`, in particular, `bnd-maven-plugin`

to programmatically declare JPMS/OSGi module exports and service providers.
Effectively, it generates `module-info.class`, `META-INF/services`, and
(OSGi-related) `MANIFEST.MF` files. We also enhance this experience with
`bnd-baseline-maven-plugin`

to enforce API compatibility between versions.

I really like this! We use `@Export`, `@Version`, `@ServiceConsumer`,
`@ServiceProvider`, etc. annotations in the code and `bnd` takes care of
the rest. Though in the last couple of months, I have noticed several
nuances that started to make me consider pros/cons of this convenience.

*Good: Programmatic configuration*

No need to manually populate `module-info.java`, `META-INF/services`,
`MANIFEST.MF` files. Everything is in the code. Great!

*Bad: Programmatic configuration is not enough*

We still need to tweak the generated `module-info.class` in several places.
We have hundreds of lines of manual treatment: you can simply search for
`https://github.com/apache/logging-parent/issues/69#issuecomment-1845373576>

*Bad: Mismatch with the community and ecosystem*

AFAIK, almost no major project uses `bnd-maven-plugin`. (This is more of a
gut feeling, I haven't done an empirical study on this.) We are alone with
our problems and others' solutions (catered against mainstream which
hand-craft `module-info.java`, etc. files) don't work for us.

*What now?*

`bnd-maven-plugin` is a great tool with an active community. It delivers
its promises perfectly. Though the surrounding ecosystem (IDEs,
not-JPMS'ed-yet libraries, etc.) doesn't always play nice with it and
eventually we end up tweaking it, *a lot*. I am sitting on the fence
whether it is a curse or a blessing. I will appreciate your thoughts on the
matter.