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

[Peter Kriens <Peter.Kriens@xxxxxxxxx>]

PO> I think it is rather elegant to use the same file for design and
PO> runtime.

I could support that if the manifest was designed for this
purpose, but it clearly was not. A manifest was designed for easy
processing on a potentially limited target. It therefore has no variable
substitution, no syntax oriented towards users (72 character line
limit is from punch cards!), nor does it have programming
constructs to minimise information redundancy. Nor should it ...

For its primary run-time purpose it is not a problem because
you could generate this information from a single source (like e.g. the POM
file in maven). However, because this exploded format is also a design
time format, you are forced to write out the evil redundancy. For example:

- Package attributes for each package must be repeated for each
  package; you can not parameterize it.
- You can not just generate your imports depending on what your code refers
  to (as is done in the OSGi plugin for maven).
- Many times the package names start with a prefix that is the project
  name, which is the bundle symbolic name etc.
- The vendor and copyright information is usually the same between
  projects.

I can go on ...

I think using the manifest as both the design and runtime artifact is
a classic OO mistake of combining two entities that look very similar
but have -very- different roles in life. Because you have harsh
constraints on the syntax based on its runtime role, you can no longer
optimize it for its design time role. Why do you think we have .java
and .class files, we could write the .class files directly as well?

I also wrote some more about this in my blog www.osgi.org/blog
yesterday.

Still love Eclipse though :-)

Kind regards,

     Peter Kriens






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

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

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

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

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

PO> :-)

PO> --
PO> Cheers
PO> Philippe

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

PO> _______________________________________________
PO> equinox-dev mailing list
PO> equinox-dev@xxxxxxxxxxx
PO> https://dev.eclipse.org/mailman/listinfo/equinox-dev


-- 
Peter Kriens                              Tel +33467542167
9C, Avenue St. Drézéry                    AOL,Yahoo: pkriens
34160 Beaulieu, France                    ICQ 255570717
Skype pkriens                             Fax +1 8153772599