[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] OSGI Bundles: alternate manifest.mf location
- From: Niclas Hedhman <niclas@xxxxxxxxxxx>
- Date: Sat, 8 Jul 2006 06:10:30 +0800
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:organization:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=jiolLsD3PmL8l4pDui49w0NlUgw5dBj3z/hiY9U+v2gYs84+DxckDX8WUPTVVwQz9GpPVLa7Nugcn+1FrAfVK+GulPevc0p54hO3caYuqk+oGSSV+UCeIVDRzmNcZsbzSBvfPlReoFfn+Id7ukrJKXPE63LHhEa0lDcR4ppicPs=
- Organization: Private
- User-agent: KMail/1.9.1
On Friday 07 July 2006 19:10, Peter Kriens wrote:
> It would be interesting to know how many people on this
> list would like to be able to do something before launching/packaging
> and get rid of the project==bundle constraint?
Generally, I am personally Ok with 1:1 and did so long before I used OSGi. I
think the developer community at large is fairly divided on the issue, and I
don't want to get into a religious war over it.
Maven is also following the 1:1 in general, although it can have multiple
outputs of different types.
I think that the idea that Manifest.MF must be a non-copied file, is pure
non-sense, result of a historical heritage and possibly in-grained into the
codebase so much it is hard/expensive to change (which of course is a valid
point). The .project file could contain the information of such, just like
source dirs and output destination.
Having a single 'target' directory where all derived material ends up is IMHO
even better than the single source, as it allows me to manipulate the source
prior to committing it into the final artifacts, for instance BuildTime and
Version manifest headers. It is also extremely clear what is source and not.
OTOH, don't listen to me, because I don't use Eclipse :o) Instead, I let my
Maven system build the Manifest.mf and place that into the META-INF/ (where
PDE expects) it instead, for the developers in my group who still prefers