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

[Jeff McAffer <Jeff_McAffer@xxxxxxxxxx>]

Peter Kriens wrote on 07/07/2006 07:10:49 AM:

> JM> ....  The PDE need to have the manifest at
> JM> a particular spot is driven by "self hosting" usecases.
 PDE
> JM> developers do not have to "build" or "deploy"
or take any other
> JM> action between saving changes to a plugin and running it.
> This is not really true. You map around the class path to get the
bin folder
> on the class path (the magic source.. and output.. properties), they
> are normally in the
> root of the bundle. Why you could not have a magic meta.. property?
> 
> You do have a "deploy" phase before you launch, you just
distributed most
> of the work during editing. E.g. before you launch you must commit
all
> your files and I am pretty sure you internally do some more things
> before you launch, however, as far as I know that point is not
> available to run a script.

The point here was that *developers* do not have to
do anything.  It is a workflow thing.  They just code and run.
 It's not clear that anyone is confused that they have to save their
files if they want to run the code they just wrote.  As for the source
and output mappings, in general developers do not have to touch these.
 If they do, it is very very in frequently (e.g., when defining the
source folder structure)  So again, the developers do not have to
do anything special in their minute by minute workflow.

> JM>   This is a fundamental part
of the Eclipse philosophy and workflow.  
> Unfortunately :-( As I have argued in vain too many times, it just
does
> not work very well for bundle development. It might work for big
> Eclipse plugins development, for my kind of work where I have lots
and
> lots of small bundles and complex packaging requirements it just
> does not work. 

Just to be clear here, the model works fine for thousands
of Eclipse plugin/bundle developers.  There is nothing particularly
big or small about Eclipse bundles -- they vary from 10K to several MB.
 Eclipse developers routinely work with systems of thousands of bundles
using PDE and the development workflows and models it supports.  In
light of that, claims that it "does not work" seem somewhat rash.

> The Eclipse model with 1 project = 1 bundle is
too constrained.
> It also forces you to put the same information in lots of places
> because you can not define variables in a single point and use them
> in many places, causing the root of most software evil: redundancy.
A
> build tool can easily generate the imports, now you must edit them
by
> hand.

We have this discussion over and over again.  While
I agree that you can detect the use of various packages and thus generate
the simple Import-Package statements, I disagree that you can detect and
generate the correct version constraints and/or matching attributes.  These
are things that developers craft.  In fact, we have developer communities
that want to lock down manifests so that developers cannot stray from what
a particular bundle is allowed to use. If in fact imports can be completely
generated by code analysis then OSGi should just get rid of them as they
are redundant.  All the information needed would be embedded in the
code.

In light of these issues and usecases, the PDE approach
is to add developer support around managing imports (e.g., detecting missing
imports, suggesting values, and going forward, help with version management).

Jeff