[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
manifest.mf is both design and run-time [was RE: > [equinox-dev] OSGI Bundles: alternate manifest.mf location]
- From: Mel Martinez <melm@xxxxxxxxxx>
- Date: Wed, 12 Jul 2006 13:37:48 -0400
- Delivered-to: firstname.lastname@example.org
"Philippe Ombredanne" <pombredanne@xxxxxxxxx> wrote on 07/12/2006 01:36:03
> Subject: manifest.mf is both design and run-time [was RE:
> [equinox-dev] OSGI Bundles: alternate manifest.mf location]
> 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.
> 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.
I believe that that is part of the problem. The manifest.mf was not
be a project definition file. It is a runtime manifest. In a sense it is
a runtime artifact analogous to a compiled .class file.
Overloading its use as a development artifact is problematic because the
manifest.mf syntax is not
semantically oriented towards that use. In fact, it is highly constrained.
A better model would be to have distinct development-time artifact(s) that
represents the 'source' for the manifest.mf and generate the manifest when
building the runtime artifacts.
But hindsight is 20/20. We have to work from what we have right now. Is
it possible to evolve towards such a better, decoupled model?