Skip to main content

[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

-----Original Message-----
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Pascal Rapicault
Sent: Friday, July 07, 2006 1:18 PM
To: Equinox development mailing list
Cc: Equinox development mailing list; equinox-dev-bounces@xxxxxxxxxxx
Subject: Re: [equinox-dev] OSGI Bundles: alternate manifest.mf location


>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


Back to the top