Eclipse RCP项目中多META-INF文件夹及包交互疑问

Hey there! Let's unpack this Eclipse RCP setup—this kind of modular structure is standard for RCP, but it can feel confusing at first if you're new to bundles and PDE. Here's a breakdown to help you make sense of it:

Why Three META-INF/MANIFEST.MF Files? #

In Eclipse RCP, every bundle (plug-in) requires its own MANIFEST.MF—this file is the "heart" of the plug-in, defining critical metadata like:

• Bundle-SymbolicName: The unique ID of the plug-in
• Require-Bundle: Other plug-ins this bundle depends on
• Export-Package: Packages this bundle exposes to other plug-ins
• Extension/Extension-Point: How the plug-in integrates with the RCP framework or other plug-ins

So those three packages with META-INF are almost certainly separate RCP plug-ins (bundles). The fourth package without a META-INF is likely either:

• A plain Java library project (not configured as an RCP plug-in)
• A plug-in that hasn't been fully initialized with PDE (Plug-in Development Environment) tools yet

What's Up With the Missing build.properties? #

The build.properties file is specific to Eclipse PDE—it tells the build system which resources, source folders, and libraries to include when packaging the plug-in into a JAR. If a package doesn't have this file:

• If it's a plain Java library, it doesn't need one (since it's not being built as an RCP plug-in)
• If it's supposed to be a plug-in, you might need to run Configure > Convert to Plug-in Project on it (right-click the project) to generate the necessary PDE files

How Do These Bundles Interact (Even Without Direct Class References)? #

RCP plug-ins often communicate without explicit compile-time class references—here are the common ways this happens:

• Extension Points & Extensions: One plug-in defines an extension point (e.g., a menu contribution or a data provider), and another plug-in implements that extension. Eclipse uses its registry to discover these at runtime, so you won't see direct imports in the code.
• OSGi Services: Plug-ins can register services (via BundleContext.registerService()) and look up services dynamically (via BundleContext.getServiceReference()). This is a loose-coupled way to share functionality without compile-time dependencies.
• Modular Preparation: Sometimes projects are split into plug-ins upfront for future scalability—maybe the code hasn't been wired together yet, but the structure is set up to support separation of concerns (e.g., UI vs. core logic vs. data access).

Practical Steps to Explore the Structure #

• Dig into the MANIFEST.MF files: Open each one with the PDE Manifest Editor (double-click it) and check the Overview, Dependencies, and Extensions tabs. This will tell you each plug-in's purpose and what it depends on.
• Use the Plug-ins View: Go to Window > Show View > Other... > Plug-in Development > Plug-ins to see all bundles in your workspace. You can right-click a plug-in to inspect its runtime details or open its declaration.
• Check the Target Platform: Go to Window > Preferences > Plug-in Development > Target Platform—this defines the set of plug-ins your project is built against, which can explain why certain dependencies are present.
• Look for a Product File: If your project has a .product file, open it—this defines which plug-ins are included in the final RCP application, showing how all these pieces fit together.

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