[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] OSGI Bundles: alternate manifest.mf location
|
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.
(Incidentally if there was one feature of JDT that I could kill, it
would be Organise Imports! Unfortunately most developers are
undisciplined and if Eclipse didn't have it then they would move to an
IDE that did. Anyway I digress.)
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.
Furthermore CVS never deletes directories, so some of these modules
are old stuff that got abandoned. If those empty directories were
inside a project then they would just get pruned on checkout with the
-P switch. But since they are at the project level, I have to see them
all the time and remember not to check them out.
Of course this problem always exists with old, dead modules in CVS but
usually they are much larger granules of work than single bundles.
- Neil
On 7/7/06, Marcel Offermans <marcel.offermans@xxxxxxxxxx> wrote:
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
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
--
Neil Bartlett
Senior Technical Consultant, Integility Ltd
Tel: +44 (0) 20 7043 8328
Fax: +44 (0) 20 7043 8329
LinkedIn Profile: https://www.linkedin.com/in/neilbartlett
