> 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
> 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 http://dev.eclipse.org/viewcvs/index.cgi/equinox-incubator/ 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.