Revert "Added bnd-maven-plugin configuration as per issue #521"

[dmlloyd]

This reverts commit e7c4d2d.

@scottslewis, this commit caused the smallrye-common-annotation JAR artifact to have no content other than the manifest and a couple housekeeping files. The problem manifests as compilation errors in dependent modules. Reverting the commit restores functionality.

Unfortunately it doesn't really show up on any tests because we don't really test for the JAR contents after build.

Also, something that didn't turn up on code review was the addition of tabs and other inconsistent whitespace.

[scottslewis]

This reverts commit e7c4d2d.

@scottslewis, this commit caused the smallrye-common-annotation JAR artifact to have no content other than the manifest and a couple housekeeping files.

Hmm. I tested locally with mvn clean install and checked the resulting jar...and it had the meta-data on the pr comment. Perhaps your release build is doing something different than what I tested or post-processing the artifact. Is there a way to locally run a release build? (or whatever you did that produced the empty artifact)?

The problem manifests as compilation errors in dependent modules.

If you point me at the compilation errors/build logs from the relevant builds I will help diagnose.

Also, something that didn't turn up on code review was the addition of tabs and > other inconsistent whitespace.

Ok. If that's a problem it's easily fixed, but I don't think it's likely to be the cause of the build problems.

[dmlloyd]

The problem appeared for me on a normal mvn clean install on the #524 branch. The JAR installed into the repository contained only metadata and had no classes in it.

[scottslewis]

The problem appeared for me on a normal mvn clean install on the #524 branch. The JAR installed into the repository contained only metadata and had no classes in it.

ok. I mistakenly thought that it was the manifest that was messed up in the target jar...but rather the classes were missing...got it.

After looking at the build, I suspect that the maven-jar-plugin that I added for annotations build in the pr is somehow conflicting with the jboss bridger plugin located in the parent pom:

https://github.com/smallrye/smallrye-common/blob/main/pom.xml#L166

as this (no classes in jar) hasn't happened before in other maven build environments that I've encountered...and I didn't detect the classes omission...sorry for that.

I'm not familiar with the jboss bridger plugin...and there are not a lot of docs available publicly. Do you know what it's doing to the target jars?

A search gave this: Purpose: It bridged the gap between traditional JAR files and OSGi-compatible bundles by adding necessary metadata and adjusting bytecode.

Which seems strange since adding OSGi meta-data is what I'm trying to do...and of course it wasn't present in your jars so it's not obvious to me what the bridger is doing.

I'm inclined to look at/generate the previous jar to figure out what it's doing, but if it's changing the bytecode somehow I obviously won't be able to see that.

[scottslewis]

I've verified that the bridger plugin is at least creating a module-info.class (or perhaps moving it after compile) at the jar root directory. It also seems to be copying the classes into the target jar (and possibly changing byte code?)...which somehow confuses the maven-jar-plugin that I added.

I'm looking at configuring the maven-jar-plugin to post-process what the bridger produces to update the manifest. If you have any more details on the bridger plugin's functionality within the build I would appreciate it.

[dmlloyd]

The bridger plugin source can be found here: https://github.com/dmlloyd/bridger

It transforms the bytecode of certain classes in the project's outputDirectory. It does not do anything to the JAR (it runs beforehand).

There are also other bytecode-processing plugins that we use which operate in the same way - by processing class files during the process-classes lifecycle phase.

[scottslewis]

Please see pr #528