Andreas, Thanks for the pointer. Your build system seems to work nicely. However, as far as I can tell, you still have to explicitly specify module-level dependencies in the ivy configuration. My dream builder will be able to recognize and read an Eclipse PDE project (or any other project layout -- completely extensible of course :) and resolve dependencies using only the OSGi metadata.
Thanks, Jeremy On 5/5/07, Andreas Ronge <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
