Thanks for the detailed reply, Raffael, and sorry for my delayed response. >From what I can tell, Pax Construct builds OSGi-Maven projects. If that is correct, then I think I'd prefer not to go down that route.
I'm going to take a look at Loom and see if I can get it to do anything for me. :) I also find myself interested in Silk, since it seems to be based upon the same idea. Perhaps it can be resurrected. Hopefully I'll have something to report back. Thanks, - Jeremy On 5/2/07, Raffael Herzog <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
