[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] Good support for PDE in build systems anyone?

Hi,
sorry for cross posting this, just felt that I would like to ask in the Equinox list too for any examples of good build system support in the PDE.


On Jun 4, 2006, at 2:20 PM, Niclas Hedhman wrote:
>On Sunday 04 June 2006 19:36, Peter Neubauer wrote:

>>Maven actually support PDE development
>What does that mean in reality??

>I mean "support" is a pretty vague word.


Mmmh,
in particular I find the use of Maven plugins and other tools not sufficient when it comes to developing OSGi bundles in the Eclipse PDE. The problem is, compile time everything is fine having dynamically mounted jars via virtual classpath containers a la MevenIDE, and the old Magic plugin I wrote. But even so, PDE requires a valid Manifest to be present under /meta-inf of the current OSGi bundle project in the workspace, and the PDE dependencies virtual classpath variable mounts the deps mentioned in the Manifest.


However, when you try to run/debug your plugin, the dependencies stated in the Classpath entry in the manifest have to be there under the bundle root folder.

Basically, the problem is that the PDE is taking the Manifest and OSGi as master, where maven and others are generating everything from a POM/Ivy file. In Ivy, we have solved that somewhat by
- reading most of the attributes from the Manifest.mf as master instead of the ivy.xml
- download the different deps locally before compiling and using them for the classpath from within the PDE. Generated by Ivy but still in harmony with the PDE we have a working build system with Ivy that works good with the PDE at https://scm.ops4j.org/repos/ops4j/ laboratory/users/andreas/builder/
- package the bundle with a similar structure as the development layout.


I'm not sure how to solve this discrepancy between the two mindsets
- runtime, OSGi rules and the PDE tries to enforce valid development time editable artifacts
- metadata rules and all runtime data is generated from POM/Ivy metadata, which is the build system approach.


I see two major points where the PDE has to be adapted to honor the build system or the other way round:

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
- flexible location of the Manifest in the bundle or at least allowance in the PDE to specify a manifest by URL (to be able to reference it as a custom protocol "artifact:mf:my/project/ manifest#1.0.2") pointing to a maven resolved repository or generated location.


2) Dependencies
- not sure that is possible but it would be great to be able to reference everything in the PDE as URLs, opening for mounting e.g. the runtime jars from the local maven/ivy repo into the right place for the PDE. Somewhat possible with Eclipse workbench links I guess but they seem to be tied into absolute file paths and protocols, making them too static for this.
- best would be to be able to even in the manifest.mf bundle classpath to use URLs for the private jars etc. in order to be able to use the same approach
- this would enable things like Hansa/Transit that is Niclas favorite pet ;) http://wiki.ops4j.org/dokuwiki/doku.php?id=hansa:hansa



Not sure how much of this sounds understandable and how much there is support for it in the OSGi spec and Eclipse PDE possibilities, just thinking aloud.


WDYT? does anyone out there have a nice working PDE system with Maven working for OSGi bundle development and a description of the process?


/peter