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

Neil Bartlett wrote on 07/07/2006 11:41:29 AM:

> I've generally fine with 1 project = 1 bundle, and I like being forced
> to maintain manifests as I develop my bundles. Your model of pooling
> all the source together and then sorting out the bundles later sounds
> messy to me. With no constraints on importing packages, developers
> just hit "Organise Imports" to pull in dependencies from all over the
> place, resulting in spaghetti code.

In answer to Marcel's question in another message and related to this, yes the idea of locking down a manifest is to enforce some design constraints at development time.  It is exactly the case that Neil points out that concerns these teams.  

> One problem that project=bundle does create for me is in CVS usage. 1
> project = 1 bundle = 1 CVS module, so I end up with hundreds of module
> directories at the top level of my CVS project, which I have to check
> out individually as projects. I can't rename them. When I create a new
> bundle I have to email my team to tell them to check it out.

Note that there is no need to have the CVS module be at the top level of the CVS repo.  We have lots of projects that are done this way.  Take a look at
There are a mess of projects there and they are not at the root of the Eclipse CVS repo.  All you have to do is set the location when you "share" the project.

As for telling the team, you should look at Project Set Files (Export > Team > Project Set File).  These are descriptions of a set of projects and where they are.  The description is just a file so it is itself sharable.  We often have a "releng" project that contains a set of these.  Then people just have to check them out.  Unfortunately it does not cover removing things from your workspace when they get removed from the project set.