Re: Re: RE: RE: [equinox-dev] OSGI Bundles: alternate manifest.mf locati

["Alex Blewitt" <alex.blewitt@xxxxxxxxx>]

On 07/07/06, Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> wrote:
> Tom wrote on 07/06/2006 10:31:59 AM:
>
>  > Easy solution: add a (maven) plugin to the generate-resources phase
>  > that copies META-INF/Manifest.MF to target/classes.
>  > (although I don't know how Eclipse or  OSGi will react to the fact
>  > that there are now two manifests in the plugin classpath)
>
> Manifests are not on the classpath (at least we never treat them as they
> are) since they in fact define the classpath for a bundle.
>
> I'm not sure I followed all of this but if these solutions are available in
> Maven, why not use them?

Firstly, there's no need to write a maven builder (or plugin) that
copies the META-INF to the right place. Maven is perfectly capable of
doing that, by having a number of resources specified individually (or
using wildcards, like icons/* above). The fact is that Maven is highly
customisable to do a whole host of things, like finding resources from
any location.

The problem is that *developers* who use Maven expect things to be in
particular places. The convention is to have a resources/ directory
under which items are put (e.g. resources/META-INF/MANIFEST.MF). Ergo,
the problem is not changing Maven but changing developers's mind sets.

Unfortunately, PDE is pretty limited in what can be where. Unlike a
Java project, where you can have multipe source folders (and the Maven
plugin for Java development sets up a source folder for each of
resources/, src/main/java, src/main/test ... ) so that the contents of
the 'runtime' is available in the output location (classes, or build,
or target/, or whatever). When a Java application runs, it finds files
using getResource(), and the output location is the merged contents of
all the individual source directories (of which non-Java resources are
copied over).

I don't see why a similar approach couldn't be used for PDE. That is,
configure the PDE with a set of src folders, and obtain MANIFEST.MF
using the equivalent of getResource(). Note that although this
discussion has centred around MANIFEST.MF, the same applies to *any*
resource (e.g. icons/helloworld.gif, thing.properties). Unfortunately
PDE has no way of having resources located in anything other than the
root project, almost as if it were a Java project and the default
output location was '/'. Most Java developers don't follow the default
output location, but choose to have separate build and source folders
(including possibly multiple source folders, or
source-folder-as-resource-folder). The structure of the output
location will now be *exactly* the same as an output Jar will be, and
you can use that as the bundle's classpath for runtime scenarios.

To be honest, it's not just the MANIFEST.MF that bugs me; it's the
fact that all my other non-Java resources have to be located at the
root of the project folder, and that I have to name them individually
(because if I said 'bin.includes = .' then I'd get all the other
source files in there too). Having a separate resources directory
allows you to specify just a resource directory and then everything
comes in (but without the directory name as a prefix).

My proposal:

o Set up PDE so that it looks at a project's classpath only for its
resources (*)
o Effectively update the source folders so that there's one default
output folder and one (or more) source folders taht copy into that
o Modify the build process so that it's a Jar of the default output
folder (or folders?)

You'd then be able to structure the source code the way you want it to
be structured, not the way any one specific tool wants it to be
structured. (Again: it's not Maven that's inflexible, it's that what a
Maven developer would want to structure is not possible with PDE).
FWIW I did show how it was possible to use Maven to build an RCP
application in the EclipseCon tutorial, so it's possible -- just with
a lot of PDE-specific workarounds.

(*) Yes, I know that the PDE variables contain the dependent bundles
classpath entry. You'd have to do something specific for that; but
then again, the MANIFEST is only going to be particular to that
project, ergo it must live in that project's default output location.
It would be relatively easy to adjust the classpath container to scan
for ${output}/META-INF/MANIFEST.MF, instead of just
META-INF/MANIFEST.MF, to compute the rest of the classpath. The only
information you need for the location of the manifest file is the
output folder, or (in the case of a clean build) the list of source
folders.