[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [equinox-dev] OSGI Bundles: alternate manifest.mf location
|
Title: Message
And
maybe also an example in the GMF project.
--
Cheers
Philippe
philippe ombredanne | 1 650 799
0949 | pombredanne at nexb.com
nexB - Open by Design (tm) - http://www.nexb.com
http://EasyEclipse.org -
irc://irc.freenode.net/easyeclipse
>Fair enough. Related to
this, having an overview of all dependencies and graphically representing them
would help a lot here. In 100+ bundle projects it's easy to loose the
overview, both of package and service >dependencies. Is there any work in
Eclipse towards producing such views?
The closest thing we have so far is the open dependencies
action on a project (right click on a plugin project > PDE Tools > open
dependencies)
HTH
PaScaL
Marcel Offermans
<marcel.offermans@xxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
07/07/2006 03:34 PM
Please respond
to Equinox development mailing list
<equinox-dev@xxxxxxxxxxx> |
|
To
| Equinox development mailing list
<equinox-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| Re: [equinox-dev] OSGI Bundles:
alternate manifest.mf location |
|
On
Jul 7, 2006, at 20:10 , Jeff McAffer wrote:
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.
Of course
I'm not advocating to do packaging without putting thought into it, I merely
want to uncouple projects and bundles. I don't agree with your statement to
simply ban features like "organize imports" because they can be misused by
ignorant developers. Using Eclipse does not make bad programmers better.
:)
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.
Fair enough. Related to this, having an overview of all dependencies
and graphically representing them would help a lot here. In 100+ bundle
projects it's easy to loose the overview, both of package and service
dependencies. Is there any work in Eclipse towards producing such
views?
Greetings, Marcel
_______________________________________________
equinox-dev mailing
list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev