There is also my little build system, builder. Here are some instruction how to build osgi bundles:
1. Checkout the build system (which contains a repository of build plugins and examples) $ svn co https://scm.ops4j.org/repos/ops4j/laboratory/users/andreas/builder 2. Install build system (i.e. install the core builder plugin which is responsible of installing other builder plugins) $ cd builder $ ant 3. Install the builder plugins for the osgi equinox product example. This product consists of three projects: 2 bundles modules and a product module descriping start levels etc. The example/osgi-equinox/product.x/build.xml specifies which builder plugin is needed to build it (build.xml specifies the ant property builder.plugin.main=equinox and includes the core builder ant script) To install this builder plugin (which in turn consist of several other builder plugins, like java and ivy) type: $ cd example/osgi-equinox/product.x $ ant The build will fail with a message: "Please build again, since the build script has been updated" 4. Build the osgi equinox example $ ant build-all 5. Run it cd ~/tmp/builder/example/osgi-equinox/product.x/target/dist/demo $ run.bat This has been tested on java5 and java6 on both windows and linux (except the run.bat :-) Ivy configuration of product.x ============================== >From the ivy.xml file an equinox config.ini file is genererated. Notice that two configurations are generated, demo and production with different set of bundles included example/osgi-equinox/product.x/ivy.xml: <?xml version="1.0" encoding="ISO-8859-1"?> <ivy-module version="1.3"> <info organisation="ops4j" module="product.x"/> <configurations> <conf name="demo" extends="all" description="devices being simulated"/> <conf name="production" extends="all" description="real devices in a production environment"/> <conf name="bundle" visibility="private" description="bundles this product needs"/> <conf name="all" visibility="private" description="artifacts that will be included in all other configuration"/> </configurations> <publications/> <dependencies defaultconf="demo,production->bundle"> <!-- OSGi container --> <dependency org="org.eclipse" name="org.eclipse.osgi" rev="3.2.0.v20060214"/> <!-- should be available in all configurations --> <dependency org="ops4j" name="bundle.a" conf="demo->bundle" rev="latest.integration" start-level="1" state="start"/> <!-- should be only available when the devices are being simulated --> <dependency org="ops4j" name="bundle.b" rev="latest.integration" start-level="2" state="start"/> </dependencies> </ivy-module> Cheers, Andreas On 5/4/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. > > 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 > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
