Incubating automatic manifest generation in equinox

[laeubi]

I recently added support for automatic manifest generation in PDE.

I wonder if we can use Equinox as an incubator for this feature to gather some more experience with that, I have especially those bundles in mind that currently implementing a service:

• org.eclipse.equinox.event
• org.eclipse.equinox.cm
• org.eclipse.equinox.metatype
• org.eclipse.equinox.useradmin

The rationale is that these are usually stand alone (that is no one really depends on them directly) and are already very close in the OSGi world (e.g. no need for extension points or alike) and their manifests are quite easy to understand / compare so we do not need to care about some specialties (e.g. require bundle with reexport).

Another point is that it is always good to have features of platform used in the daily work to getting aware of any issues / improvements early, also there are probably some adjustments for Tycho required.

So I'd like to ask @tjwatson as project lead and of course everyone else for concerns or ideas.

[tjwatson]

I assume tycho itself has this support also for during the platform builds? I have no issues moving forward with the listed equinox bundles as long as tycho can handle it, but that list likely an obvious pre-req to this change.

I assume we will add OSGi annotations as appropriate for managing package versions etc.

[laeubi]

I assume tycho itself has this support also for during the platform builds?

Yes I need to finish some tasks for this, but of course this would then be the ultimate test.

I assume we will add OSGi annotations as appropriate for managing package versions etc.

One can still define things in the pde.bnd file but I like to migrate as much as possible to the annotation part, if not already managed by bnd automatically.

[laeubi]

I have now created a first draft PR that should outline how such a bundle looks like and a list of different things to check:

• Move org.eclipse.equinox.event to use automatic manifest generation #246

if that works, other bundles can be adapted accordingly and we can fix issues discovered on the way.

[merks]

I'm a little concerned that org.eclipse.equinox.p2.publisher.eclipse.BundlesAction can't work until after the manifest generator generates the manifest so I don't understand very well how this will work in the IDE with freshly imported projects. Also, Oomph's targlets rely on being able to induce "rich IU"s from projects on-disks and PDE is effectively doing that as well.

[laeubi]

The IDE does not use BundlesAction (as far as I can tell) at all, this is only done when reading the data from a P2 Site, so then there should be no difference at all.
I have no clue about targlets, but you can checkout the PR with a recent SDK Eclipse (please also apply eclipse-pde/eclipse.pde#560) and check if anything special has to be taken into account.

Technically it works by telling PDE to look at a different location for a MANIFEST.MF (but if you absolutely like you can even configure that location) and whenever any classfile changes it overwrites that file with an updated one so for PDE it seems you are editing that file manually and everything works as usual.

[merks]

Yes, you are right. It's relying on org.eclipse.osgi.internal.resolver.BundleDescriptionImpl to build the state information. I'll need to investigate in more detail as you suggest, time permitting. Where can I find the logic in PDE that generates a MANIFEST.MF?

[laeubi]

Yes, you are right. It's relying on org.eclipse.osgi.internal.resolver.BundleDescriptionImpl to build the state information. I'll need to investigate in more detail as you suggest, time permitting. Where can I find the logic in PDE that generates a MANIFEST.MF?

https://github.com/eclipse-pde/eclipse.pde/blob/master/ui/org.eclipse.pde.core/src/org/eclipse/pde/internal/core/bnd/BndBuilder.java

but be aware that it slightly changed in

• Synchronize values changed in the Overview with the instructions file eclipse-pde/eclipse.pde#560