byte-buddy sources bundle specifies symoblic name "net.bytebuddy.byte-buddy"

[trancexpress]

When downloading byte-buddy and the respective source bundle from maven (https://repo1.maven.org/maven2/net/bytebuddy/byte-buddy/1.10.11/), both bundles have the same manifest contents:

Manifest-Version: 1.0
Bundle-Description: Byte Buddy is a Java library for creating Java cla
 sses at run time.        This artifact is a build of Byte Buddy with 
 all ASM dependencies repackaged into its own name space.
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
Bundle-SymbolicName: net.bytebuddy.byte-buddy
Built-By: runner
Bnd-LastModified: 1591292975197
Bundle-ManifestVersion: 2
Tool: Bnd-3.5.0.201709291849
Main-Class: net.bytebuddy.build.Plugin$Engine$Default
Export-Package: net.bytebuddy;version="1.10.11",net.bytebuddy.agent.bu
 ilder;version="1.10.11",net.bytebuddy.asm;version="1.10.11",net.byteb
 uddy.build;version="1.10.11",net.bytebuddy.description;version="1.10.
 11",net.bytebuddy.description.annotation;version="1.10.11",net.bytebu
 ddy.description.enumeration;version="1.10.11",net.bytebuddy.descripti
 on.field;version="1.10.11",net.bytebuddy.description.method;version="
 1.10.11",net.bytebuddy.description.modifier;version="1.10.11",net.byt
 ebuddy.description.type;version="1.10.11",net.bytebuddy.dynamic;versi
 on="1.10.11",net.bytebuddy.dynamic.loading;version="1.10.11",net.byte
 buddy.dynamic.scaffold;version="1.10.11",net.bytebuddy.dynamic.scaffo
 ld.inline;version="1.10.11",net.bytebuddy.dynamic.scaffold.subclass;v
 ersion="1.10.11",net.bytebuddy.implementation;version="1.10.11",net.b
 ytebuddy.implementation.attribute;version="1.10.11",net.bytebuddy.imp
 lementation.auxiliary;version="1.10.11",net.bytebuddy.implementation.
 bind;version="1.10.11",net.bytebuddy.implementation.bind.annotation;v
 ersion="1.10.11",net.bytebuddy.implementation.bytecode;version="1.10.
 11",net.bytebuddy.implementation.bytecode.assign;version="1.10.11",ne
 t.bytebuddy.implementation.bytecode.assign.primitive;version="1.10.11
 ",net.bytebuddy.implementation.bytecode.assign.reference;version="1.1
 0.11",net.bytebuddy.implementation.bytecode.collection;version="1.10.
 11",net.bytebuddy.implementation.bytecode.constant;version="1.10.11",
 net.bytebuddy.implementation.bytecode.member;version="1.10.11",net.by
 tebuddy.matcher;version="1.10.11",net.bytebuddy.pool;version="1.10.11
 ",net.bytebuddy.utility;version="1.10.11",net.bytebuddy.utility.privi
 lege;version="1.10.11",net.bytebuddy.utility.visitor;version="1.10.11
 ",net.bytebuddy.jar.asm;version="1.10.11",net.bytebuddy.jar.asm.signa
 ture;version="1.10.11",net.bytebuddy.jar.asm.commons;version="1.10.11
 "
Bundle-Name: Byte Buddy (without dependencies)
Bundle-Version: 1.10.11
Multi-Release: true
Created-By: Apache Maven Bundle Plugin
Build-Jdk: 1.8.0_252

In particular both bundles specify the same symbolic name, which can confuse tooling (in our case, we validate that no 2 bundles with the same symbolic name and versions are included in our Eclipse based product).

In contrast, e.g. byte-buddy-agent has a mostly empty manifest in the respective sources bundle.

[trancexpress]

Not really sure how r where to report this, so I'm reporting it here. Would be great if the sources bundle manifest is not a copy of the actual bundle.

[raphw]

From a bit of research, this seems to be expected behavior. How is this a problem? Are you including the sources jar in your application?

[trancexpress]

From a bit of research, this seems to be expected behavior.

Odd, in our Eclipse platform this is the first source bundle to have the same symbolic name as the bundle itself. E.g. for Eclipse JDT core source bundle we have:

Bundle-SymbolicName: org.eclipse.jdt.core.source

Are you including the sources jar in your application?

Yes, we include source bundles (when available) in our Eclipse platform. When doing so, debugging an Eclipse application from Eclipse itself is streamlined.

How is this a problem?

In our case, our tooling validates that we don't include a bundle twice, so we check the symbolic name and version. I believe this prevents OSGI problems later down the line, though this is not my area. I'll ask in my team and will provide more info.

[raphw]

I see. I just checked and the reason the symbolic name is added to the source jar is a result of the shade plugin's application. I will try to remove the OSGI headers from the source manifest.

[raphw]

This would need to be fixed in the Maven Shade plugin, I created a patch and issue: apache/maven-shade-plugin#59

[trancexpress]

Thanks!

[joeshannon]

Just experienced the same issue when building an Eclipse p2 repository (using Tycho) including byte-buddy as a dependency. This resulted in very inconsistent behaviour in the consuming Eclipse application as the Tycho p2 build would sometimes match the correct (classes) jar but other times match the sources jar resulting in runtime failures.

If this area is being looked at then a nice improvement would be to add headers (including Eclipse-SourceBundle) to the source bundle that allow Eclipse/p2 to be capable of including the source jar automatically when materializing. A typical manifest would look like e.g. https://github.com/h2database/h2database/blob/master/h2/src/installer/source-manifest.mf. Instead of including a template file this is often configured in the maven-source-plugin e.g. https://github.com/jline/jline3/blob/master/pom.xml#L490. I'm not sure how all this plays with the Shade plugin however.

[raphw]

Sure, I am still waiting for the (merged) PR to be released but once the new version of the shade plugin is out the door, I can try adding this.

[sithmein]

Any news on this? Especially the wrong Export-Package headers in the manifest will lead to errors when your application or target platform contains the source bundle. And this is really hard to track down.

[joeshannon]

Waiting for a new release of maven-shade-plugin I guess. The current release is 3.2.4 (from May 2020).

[raphw]

Yes, I am waiting for the release of the patch I sent them a couple of months ago. It's already merged, even.

[henryju]

We were affected by this bug of having two bundles with the same symbolic name. We managed to fix that by configuring the Maven Source plugin this way:

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <executions>
          <execution>
            <id>parse-version</id>
            <goals>
              <!-- Populate variables parsedVersion.osgiVersion -->
              <goal>parse-version</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-source-plugin</artifactId>
        <configuration>
          <archive>
            <manifestEntries>
              <Bundle-ManifestVersion>2</Bundle-ManifestVersion>
              <Bundle-Name>${project.name} Source</Bundle-Name>
              <Bundle-SymbolicName>${project.groupId}.${project.artifactId}.source</Bundle-SymbolicName>
              <Bundle-Vendor>${project.organization.name}</Bundle-Vendor>
              <!-- Variables parsedVersion.osgiVersion is provided by build-helper-plugin::parse-version -->
              <Bundle-Version>${parsedVersion.osgiVersion}</Bundle-Version>
              <Eclipse-SourceBundle>${project.groupId}.${project.artifactId};version="${parsedVersion.osgiVersion}";roots:="."</Eclipse-SourceBundle>
            </manifestEntries>
          </archive>
        </configuration>
      </plugin>

[raphw]

The source jar is copied, that is the issue. It would require a release of the linked change but unfortunately, there was no release yet.

[joeshannon]

A new version of maven-shade-plugin (3.3.0) has finally been released.

[raphw]

Brilliant, just added it to the build.

[trancexpress]

Brilliant, just added it to the build.

Thanks, which byte-buddy version will have the updates sources bundle?

[raphw]

It's set for 1.12.10 which I released yesterday.

[trancexpress]

It's set for 1.12.10 which I released yesterday.

Great, tyvm!