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

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