[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Good support for PDE in build systems anyone?
- From: Peter Neubauer <peter@xxxxxxxxxxx>
- Date: Mon, 5 Jun 2006 21:04:53 +0200
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=baW5XUsGG9Dragw86ellC2vHyq/HzdEAJ7vRED9F3LsVP2V6aXNEpHkIZNwdhx8jgGL0rgPhyVjhia63jqw+16kHZ6KWqUxtcmSibzU1LxuVzSQxXFNcObfAT89dTQ+BdXQ+VbF/UHIkFdR0wUdTxS2J759zT634ldc0B6W4D6Y=
On Jun 5, 2006, at 10:01 AM, Niclas Hedhman wrote:
Perhaps Peter is interested in resurrecting Silk, which is an
last year. Key points;
Yes you know like me, it is very tempting, but I think we wait for a
very practical case to make it happen ;)
But that was not the point of my post. I am really interested in how
we can make the PDE more build systems friendly, which IMHO would
even result in making the whole build process for Eclipse based
projects and Eclipse more standard and straightforward.
I think Peters analysis of the PDE being too fixed on requiring
exactly the same information and layout to be present at both compile
and runtime is one important point to work on. At one time we had one
approach to generate the Eclipse project from maven/ivy, but in case
of breaking something, even the Eclipse project is gone and you are
back to VI to fix things ;/
>PDE works on the notion of a "target platform". This is a set of
bundles that are in the filesystem and not in your workspace. Think
of it like the Maven local repo. In 3.2 the target platform can
source bundles from several ?>locations and the expected structure of
these locations has been relaxed somewhat. This is not enough as the
Maven, for exmaple, structure is potentially deep and PDE does not
search. One also has to consider whether or >not you want the whole
local repo exposed as part of the target.
Additionally, you would need your own target platform for every
single bundle project, which of course the build system can generate,
but it would require "scoped" target platforms, which essentially
would be to open up the target platform in exactly the same way as
the dynamic classpath entries via a Container plugin concept, very
interesting thought that! After all, why not mount the correutn taret
platform approach in the same way as the JRE jars vai a default
bundle container, and open that up later? That is, take the OSGi
bundle development where the Java development tooling already is.
>by "private jars" do you mean the ones on the classpath of the bundle?
Yes exactly. Having them exposed as URLs would open for dynamic
population behind it depending on runtime/development/testing
scenario without compromising the integrety of the manifest model.
>Some of the above issues may actually turn out to be JDT things in
as much as all PDE is really doing is populating a JDT classpath. I
don't think that they support URLs in any form on the classpath. No
idea what the >technical issues would be there
Mmmh, I think I asked that before when I tried to hook Hansa/Transit
into Eclipse and run the whole beast of a Maven-like central
repository by registering another URLHandler into OSGi and working
with new URL syntaxes in the config.ini etc etc. It seems that in the
Platform there are a lot of file dependencies all over the place. Not
sure where to start the process of removing them, or whether there
are any strong opinions on why this is so. Any ideas there?
>This is possible because PDE has a complete view of the dependency
information. Certainly Maven can (and should) be updated to do
something similar in the way it handles Import-Package. Actually,
what do Maven/Ivy do > today for Import-Package.
Agree here. This is one of the strong points for PDE. Since it is
based on a running OSGi instance, it is the only tool out there that
has OSGi compatible information at development time. And there is no
way to mimic the power of that in an environment outside OSGi. So, in
the build systems everything is based on more or less duplicating the
dependency information from the manifest one way or the other, and
hard wire compile and test time jars. Merging this was part of SILK ;)
>> 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
>> 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/
>> - package the bundle with a similar structure as the development
> Is this working for you? What are the gotchas?
It works actually quite good, we use it in production for 120+
projects. Good thing is, Ivy is copying the deps into the local
project dir before compiling, making them available for the PDE
layout. Then, we are using the Manifest quite like Niclas is
suggesting by extracting everything we can to use it as a partial
master. The config.ini is generated by parsing the PDE launch
configuration, The target platform for runnning the product off PDE
is generated from Ivy dependencies and the launch config on the fly.
As I said, there is an Example project including creating the running
Equinox product in the OPS4J laboratory, quite up to date with what
we have running in production.
> BTW, what is hte license on Ivy?
Thanks a lot for all the discussion so far, it seems I'm not alone
with the problems of getting contineous integration, version handling
and good development tooling to work nicely together.