[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] OSGI Bundles: alternate manifest.mf location



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