[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Good support for PDE in build systems anyone?
- From: Niclas Hedhman <niclas@xxxxxxxxxxx>
- Date: Mon, 5 Jun 2006 11:52:33 +0800
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=BQx3idBP0kMmwKINHNuZmqceKMl5QcRw5h54WdsYV+kWg7xfOcA/gDdi94WGn7ltfcuFZbOEV9F0/Tvg+SRfH7Y01fwjnsgl1ls9dN6+B+8V7jzGkeNI2FD96tDvYqbIic5ZQ5Qq1ZXwL4m/EvpCrmNyPOeD7SdBa65EyAeNl3w=
- User-agent: KMail/1.8.3
On Monday 05 June 2006 10:28, Jeff McAffer wrote:
> Peter Neubauer wrote on 06/04/2006 03:47:51 PM:
> > 1) Manifest file
> > - one could think of a Maven builder generating new manifest.mf on
> > the fly as you edit the relevant POM/other metadata, like source code
> > triggering changed import statements
> Sure. Note that PDE does not have to do anything here. It will pick up
> any changes made to the manifest by such a builder.
So, would making the Maven OSGi plugin generating the Manifest for PDE make
any sense?? I mean that is pretty trivial...
Another interesting thing to note, would be that one could probably create a
new life cycle phase in Maven when doing OSGi bundles, which just after the
POM has been read, reads the MEAT-INF/Manifest.MF and parse it for classpath
entries and what-else needed from there and adds it to the Maven model.
Such approach would somewhat let the Manifest be the master, but I guess it is
somewhat fragile as Maven savvy people would never conceive that to be a
Also, how does PDE know what classpath to use for "unit testing" vs normal
runs?? I also suspect that the developer is responsible for knowing the
transitive dependencies, e.g. hibernate.jar needs jta.jar (among others). How
about projects within the PDE workspace? Does it figure out that Project C
needs hibernate, therefor Project F that depends on Project C will need it
too? And in that case, how would it know whether Project C only needs
hibernate during testing, and therefor Project F should not include it in its
These are the main reasons why I like to stick with Maven as the primary tool.