Re: [equinox-dev] Good support for PDE in build systems anyone?

[Peter Neubauer <peter@xxxxxxxxxxx>]

Mmmh,
On Jun 5, 2006, at 10:01 AM, Niclas Hedhman wrote:

> Perhaps Peter is interested in resurrecting Silk, which is an  
> experiment from
> 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 ;/

Jeff:
>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.

Jeff:
>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?

Jeff:
>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 ;)

Jeff:
>> 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.

> 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?
BSD.

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.


/peter