[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: manifest.mf is both design and run-time [was RE: [equinox-dev] OSGI Bundles: alternate manifest.mf location]
|
It doesn't need to be turtles all the way down, though. The .classpath
alreay points to folders containing source (and resources) for the
current project; that's the great A'tuin. The .classpath is an
artefact of the project; the manifest.mf is a runtime resource (that
also happens to be referenced by the classpath indirectly). But it can
be edited, just like a Java source file can be edited from the source
directory (mentioned in the .classpath) or any other resource from the
resulting build folder (mentioned in the .classpath).
In fact, it's only really the PDE classpath entry 'required bundles'
that needs to be changed, because instead of looking for
/project/META-INF/MANIFEST.MF, it can look for
/project/defaultoutputlocation/META-INF/MANIFEST.MF. And once that's
done, everything will be seamless.
There's no reason why it couldn't work even without one present
initially; the project build would happen, the MANIFEST.MF would be
copied across to the output location, the PDE required libraries would
notice that the file's changed, and fire a classpath entry change
event (or similar) and then a subsequent build would be scheduled with
all the right paths.
The only types of operations that would need to be changed would be
actions such as 'PDE Tools -> Open Manifest' which uses explicit path
references to get the manifest.
Alex.
On 11/07/06, Philippe Ombredanne <pombredanne@xxxxxxxxx> wrote:
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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
