On 04/05/07, Jeremy Volkman <[EMAIL PROTECTED]> wrote: > 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.
Yep - Pax Construct's first use case was to quickly create OSGi project sandpits for demos and tutorials (so people can focus on code not build). Scope has expanded since then, but it's still maven based and uses the maven dependency system... > > 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. Certainly - just register over at http://issues.ops4j.org and you can start a lab project under https://scm.ops4j.org/repos/ops4j/laboratory/users > > 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 > -- Cheers, Stuart _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
