Currently, when developing an Eclipse plugin, the Bundle's manifest has to be located at /META-INF/MANIFEST.MF. Not only that, but all resources in the Bundle have to be in the project root, because the build isn't capable of allowing you to have directories that aren't mirrored in the output Jar. In other words, if you have resources/icons/example.gif, then it's exported as out.jar!resources/icons/example.gif. It seems to be a weird PDE restriction; after all, JDT's more than happy to allow you to put resources anywhere (e.g. following the standard Maven project layout) -- and when you export a Jar from JDT, it simply zips up the contents of the output directories, and away you go.

If you'd like to see this changed, please vote for (and comment on) bug 153023 in the Eclipse bugzilla database.

For historic reasons, more than anything else, PDE has been built on the assumption that the project as a whole is representative of the output folder. The excuse goes that the folder could be dropped directly into an OSGi runtime and it would just work. (Actually, it wouldn't. The classes are stored in a subdirectory e.g. bin and the Bundle-Classpath wouldn't point to it, so it would fail if you tried. PDE runtime bodges the Bundle-Classpath to put a bin/ on the end; just see the org.eclipse.pde.core folder underneath the configuration folder next time you run a PDE runtime workbench; it's here that it stores the bodge factor.)

So, we're stuck with META-INF/MANIFEST.MF, plugin.xml, and all your other resources (icons, about notices, documentation etc.) having to be under the project root. Doesn't it just remind you of when Eclipse used to be under the quaint notion that a Java project's source folder and output folder had to be the project root? That's right -- even though the Java world has moved on (and everyone pretty much uses a resources directory, or src/main/resources or src/test/resources directory to host their resources in -- PDE still can't handle it.

One of the big problems is that some of the resources (e.g. MANIFEST.MF) are used at both build-time and run-time. Well, that's fair enough -- but compiled Java code is used both at build-time and run-time, and they don't have a hard time dealing with that in JDT. Heck, tools such as JibX have code that needs to run at build time too, but they don't force you to store a resource at a particular location. The tool is supposed to work for you, not against you.

Peter Kriens (of OSGi fame) wrote a detailed post about the problems with PDE, and its lack of flexibility.

"The PDE discussion [on the equinox-dev list http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg01272.html] evolved around the flexibility of the environment. It got started by a request from the maven people to make the location of the manifest flexible. This touched a nerve with me because it is right at the heart why I am not using the PDE. I unfortunately still use the normal JDE because the PDE does not cut it for me. ...

"The reason why I am not using the PDE architecture is because it contains a number of harsh constraints. My key problems are:

"A project = a bundle. It is impossible to deliver multiple artifacts from the same code base with the provided tools. For the OSGi build it would mean 300++ projects.

"The project directory layout must look like the root of the bundle, well eh, sort of. The PDE does perform some magic under the covers before it runs your code or packages the bundle, but the idea is that there is a 1:1 relation.

"The manifest must be up to date at all time, forcing the developer to enter the dependency information in literal form. There is no possibility to generate information for the manifest during build time.

...

"Despite my complaints, rants, or other kinds of obnoxious behavior with the Eclipse guys, I did not get one iota further. I have been going through Eclipse 3.0, 3.1, and 3.2 without making even a dent in this model."

The big problem is that the PDE guys have a hard time understanding why anyone would want to put their resources into a specific location (and why those other tools have a hard time looking in the project root); as well as them being so used to the way that PDE works to actively dismiss this as a notion that is never going to happen. One of them even confused the request with moving the resulting file into a different location in the output Jar (which wasn't what the bug was about at all) and suggested that we petition the OSGi for a new name! Seriously.

So I'm asking you, if you develop under the Eclipse PDE and have seen the number of open-source projects that distinguish between project metadata (.project, pom.xml) and resources (MANIFEST.MF, logos, icons etc.) and want to make PDE a better place; please add your votes, comments and support to bug 153023. Clearly, it will be a lot of work to move from a hard-coded solution to a more flexible one, and the only way that the PDE teams will justify the work (not to mention the migration that may be required by other dependent teams) is if enough people show a desire to have this feature. Your vote, and your opinions, counts!