[
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
