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

[Marcel Offermans <marcel.offermans@xxxxxxxxxx>]

On Jul 7, 2006, at 15:03 , Jeff McAffer wrote:

> 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.

Stating "it does not work" might be a bit too strong, but it's definitely not the model we have been using (or want to use) in our projects. Within our projects we create several subprojects where each subproject usually consists of a limited set of bundles. This allows us to delay the decision of exactly how to package the code into bundles until the actually "packaging" stage of the life-cycle.

> 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.

If auto-generation of import works, depends on how you actually design your projects and if you need to and want to deal with these version and matching constraints you talk about. For a lot of cases, generating the imports automatically is convenient and sufficient, so I think there is some merit to using that whenever possible. I agree with you that you probably cannot completely eliminate the need for manual specification.

Actually locking down the manifests is an interesting scenario. You're doing this to enforce a specific architecture/design and not for security reasons, right?

I still think it would be nice if Eclipse would support a model where you could define projects that have some kind of descriptor that you can use to actually define how this code is split into bundles. This is definitely a model we would like to use. On the other hand, we have been using this model with Eclipse, completely ignoring PDE tooling, and it's very useable. I would be interested to see if others share this model or if everybody is happy with the 1 project = 1 bundle model.

Greetings, Marcel