Hi Jeremy, Jeremy Volkman schrieb: > We're looking to extend/replace our current OSGi build system which > is based around Eclipse's PDE. I definitely want the new system to be > OSGi-aware rather than something like Maven which drags in its own > (inferior IMO) dependency model. I know that there have been build > system projects here in the past, and I was wondering if any of them > have been touched recently? If I was going to pick something to start > with, where should I look?
There are currently two projects that address the build problem: Pax Construct and Loom. I myself am not really into Pax Construct (as I myself am not into OSGi), so it's better, if someone else describes that one. Have a look at http://wiki.ops4j.org/confluence/display/ops4j/Pax+Construct for more information. As for Loom: It's based on Niclas Hedhman's idea that we could use Drools (http://www.jboss.com/products/rules) as the decision engine of a build system. That was the basic idea behind Silk, a project that stopped because there weren't enough resources. I picked the idea up later and started a prototype from scratch, which is today called Loom (which is a temporary name, I just needed to know how to name my directories and packages; there's no connection to the other Loom over at Codehaus). In short: Instead of expressing the build process with dependencies ("do A before you do B"), we'd express it with rules ("when A is true, do B"). E.g., in "classic" build systems, you say: a. compile the Java sources, so the classes are up-to-date b. create a Jar of the class files (depends on the Java classes being up-to-date) In a rule based system, you say instead: a. when not all class files are up-to-date, compile them b. when all class files are up-to-date, jar them up This gives you more flexibility to plug in additional steps without changing the existing steps, e.g. a. when not all class files are up-to-date, compile them b. when all class files are up-to-date and not obfuscated, obfuscate them c. when all class files are up-to-date, jar them up Drools, like any rule engine, provides several mechanisms to make make sure that the actions of b. are taken before c. I won't go into the details for now. This concept allows more modularity and flexibility in the build pro- cess, as the rules that make up the process have no direct connection to each other. It's basically just a bag of if-then rules. When there's no "then" ("consequence" in Drools speak) anymore, the build is finished ("the agenda is empty" in Drools speak). Loom is a prototype of such a build system. It can't do much right now, it's more a proof of concept. What it can do: - compile Java sources (without dependencies) - when done, compile the tests - print a message that the tests are ready to be run You see, it's not very spectacular what it does. It's more about *how* it does it. ;) Unfortunately, in it's current state, there's no build. I tried to switch from Ant/Ivy to Maven, but Maven is unable to do what it should, to get a working build, without integrating tons of Ant code using Antrun or writing an own plugin. Further, I recently changed some basic API of the underlying IoC container (HiveApp, which is basically HiveMind with some extensions for plugin based applications) and didn't have the time to update Loom yet -- so, if there was a build, it currently wouldn't compile. You might want to have a look at the sources anyway ... ;) You can find them here: https://scm.ops4j.org/repos/ops4j/laboratory/users/raffael/Loom/trunk HiveApp is located here: webdavs://scm.ops4j.org/repos/ops4j/laboratory/users/raffael/hiveapp/trunk/hiveapp There's also a Wiki page (not fully up-to-date, but not completely outdated neither): http://wiki.ops4j.org/confluence/display/ops4j/Loom You might also want to check out this E-Mail: http://lists.ops4j.org/pipermail/general/2007q2/001587.html All this is about the build system in general. Of course, it will support OSGi, however, for that, I need the help of OSGi users, because I personally don't like OSGi that much. But it will not be a OSGi-only build system, it'll also be suitable for "plain old Java projects". As an example, I'm planning a pluggable dependency resolution system, so people can use Ivy repositories, M2 repitories (maybe even read the dependencies from the M2 POMs), as well as OBR (including reading the information from the bundle's meta data) etc. Cheers, Raffi -- The difference between theory and practice is that in theory, there is no difference, but in practice, there is. [EMAIL PROTECTED] · Jabber: [EMAIL PROTECTED] PGP Key 0x5FFDB5DB5D1FF5F4 · http://keyserver.pgp.com _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
