manifest.mf is both design and run-time [was RE: [equinox-dev] OSGI Bund

["Philippe Ombredanne" <pombredanne@xxxxxxxxx>]

Just to add my 2 cents of fun to this thread now it cooled off a bit:
I think that there may be some mis-perception of what the manifest.mf is
in an Eclipse project.
It has a dual nature which may be confusing to some.
It is used at design time *and( runtime.

Let's take the example of the .classpath file for a plain java project.
It has only a design time use: specify the project classpath to JDT.
It may be used by some build system to infer a build time classpath too
(like eclipse built-in Java builder), or the classpath info may be
duplicated in some other places (like creating an ant script, or a maven
pom, which in some cases are able to get that info from the .classpath
itself or to generate it from their onw path definition if needed).
Nevertheless, it has to be in a well known conventional place for the
Eclipse JDT to be able to get that info.
That means .classpath at the root of the project.
If I asked to possibly have the .classpath in an arbitrary location,
then I would need to get yet another file something like a
.classpathpath to point to the .classpath. And maybe a a
.classpathpathpath. And so on. Turtles all the way....

In the case of PDE, the manifests are the PDE equivalent of a .classpath
for JDT.
They define most of the essential information that make a project a
bundle project.
But they are also run-time configurations files.
I think it is rather elegant to use the same file for design and
runtime.
And I could very well imagine a similar design for JDT that could use a
manifest.mf (with some possible extra directives) instead of a
.classpath file.

What I am trying to say is that the manifest is not a resource to the
project, but is actually defining the pde project itself.

So lets' assume for a minute the manifests design time location is
arbitrary. I would need some way to get that information. Something like
the definition of a PDE manifest path. And some conventional place to
store that info: let's say a .manifestpath located at the root of a
project. But hey! I would like that .manifestpath file to be stored
somewhere else, for instance a resource directory so it accomodates the
defaults conventioanl locations of my meta-meta build system... No
problem: let's create another file that will hold that info:
.manifestpathpath. And so on. Turtles agains.

:-)

--
Cheers
Philippe

philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://EasyEclipse.org  -  irc://irc.freenode.net/easyeclipse