如何在OSGI中导出第三方JAR里无包声明的类

Hey there, let's work through this problem of getting those un-packaged (default package) classes from your embedded third-party JARs properly exported via your Maven configuration. I’ve run into this exact scenario before—default package classes are easy to overlook since Maven’s plugins tend to prioritize structured packages by default. Here’s how to fix it, split into two common use cases:

Scenario 1: Include Default-Package Classes in Your Project’s Output JAR #

If you just need those default-package classes to end up in your project’s main JAR alongside your own code, you’ll need to combine the maven-dependency-plugin to extract the classes and maven-jar-plugin to ensure they’re included:

1. First, define your third-party JAR dependency
   If you’re using a local JAR (not hosted in a repo), use the system scope to reference it. Adjust the group/artifact IDs and path to match your setup:

   <dependencies>
       <dependency>
           <groupId>com.your.thirdparty</groupId>
           <artifactId>custom-lib</artifactId>
           <version>1.0.0</version>
           <scope>system</scope>
           <systemPath>${project.basedir}/lib/your-third-party.jar</systemPath>
       </dependency>
   </dependencies>
   

2. Extract default-package classes with maven-dependency-plugin
   Add this plugin to unpack only the root-level .class files (the default package ones) from your third-party JAR into your project’s compiled output directory:

   <build>
       <plugins>
           <plugin>
               <groupId>org.apache.maven.plugins</groupId>
               <artifactId>maven-dependency-plugin</artifactId>
               <version>3.6.0</version>
               <executions>
                   <execution>
                       <id>pull-default-package-classes</id>
                       <phase>process-classes</phase>
                       <goals>
                           <goal>unpack</goal>
                       </goals>
                       <configuration>
                           <artifactItems>
                               <artifactItem>
                                   <groupId>com.your.thirdparty</groupId>
                                   <artifactId>custom-lib</artifactId>
                                   <version>1.0.0</version>
                                   <outputDirectory>${project.build.outputDirectory}</outputDirectory>
                                   <includes>*.class</includes> <!-- Target only default-package classes -->
                               </artifactItem>
                           </artifactItems>
                       </configuration>
                   </execution>
               </executions>
           </plugin>
       </plugins>
   </build>
   

3. Ensure maven-jar-plugin includes the default-package classes
   While the JAR plugin usually includes all compiled classes, it’s safe to explicitly allow default-package files to avoid any accidental filtering:

   <plugin>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-jar-plugin</artifactId>
       <version>3.3.0</version>
       <configuration>
           <includes>
               <include>*.class</include> <!-- Keep default-package classes -->
               <include>**/*.class</include> <!-- Keep all other packaged classes -->
           </includes>
       </configuration>
   </plugin>
   

Scenario 2: Package Everything into an Executable JAR with maven-shade-plugin #

If you’re building a fat/executable JAR that includes all dependencies, the shade plugin is your best bet—it can merge the default-package classes directly into your final JAR:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>3.5.1</version>
            <executions>
                <execution>
                    <phase>package</phase>
                    <goals>
                        <goal>shade</goal>
                    </goals>
                    <configuration>
                        <filters>
                            <filter>
                                <artifact>com.your.thirdparty:custom-lib</artifact>
                                <includes>
                                    <include>*.class</include> <!-- Preserve default-package classes -->
                                    <include>**/*.class</include> <!-- Preserve other packaged classes -->
                                </includes>
                            </filter>
                        </filters>
                        <!-- Optional: Add your main class if building an executable JAR -->
                        <transformers>
                            <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                                <mainClass>com.yourproject.Main</mainClass>
                            </transformer>
                        </transformers>
                    </configuration>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Quick Notes to Avoid Headaches #

• Avoid default packages if possible: Java’s classloader can behave unpredictably with default-package classes, and most IDEs flag them as bad practice. If you have access to the third-party JAR’s source, moving those classes into proper packages will save you future trouble.
• Test the output: After running mvn package, unzip your generated JAR and check the root directory—you should see the default-package .class files there if everything worked.
• Use up-to-date plugin versions: The versions I listed are stable, but double-check for newer releases if you run into compatibility issues.

内容的提问来源于stack exchange，提问作者Johna