Well, is it possible to contribute code completion etc to the pde manifest editor from the outside? Adding it in pde would be wrong in terms of dependency as pde is about osgi and not platform. Or is my understanding here incorrect?
PDE does contribute the DSEditor. IMO, PDE is pragmatically the best component where to add support for a new MANIFEST.MF header. Sure, one could start a new dedicated project for that, and make the MANIFEST.MF editor extensible so that the new project would contribute support for an extra header, and then you'll want to make sure this new project plugins are part of the SDK build; but then it becomes a matter of months before full completion of that task and it would require more maintenance.
Concretely, I don't see a better alternative to just supporting this feature directly in PDE MANIFEST.MF editor; and I don't think there is a real need for more flexibility.
> - create builder that scans manifest and add error markers (e.g. file not present), and scans for plugin.xml with "old" fragemnt registration
Would that require all plugin projects to add the builder to their .project? That wouldn't be a pleasant thing to introduce such requirement to leverage this new core extensibility model. This is IMO a feature that's better to support directly in the MANIFEST.MF and related existing builder themselves.
> - add qucik-fix to the marker to help assisting in fix the problem (e.g. convert plugin.xml->manifest header)
This is not a requirement for proper usage. There is no compelling reason to encourage people who use a plugin.xml to use a MANIFEST header instead, and since the MANIFEST header wouldn't be backward compatible, it's dangerous to recommend it before a few releases when we can expect most of the consumer market is using a compatible release.
So IMO it's best to not touch that part for the moment.
