Our current internal builder is based upon the Eclipse PDE and builds our bundles based only on OSGi metadata. The problem with our current solution is that it's internal, not easily customizable, and pretty messy. So, I know that it is definitely possible to build OSGi bundles using only OSGi metadata, however it needs to be done in the framework of an extensible and well-supported build environment.
You mention the need for a product description file in your build. We don't need such a file, since all bundle artifacts from our builds are delivered straight to a central repository which the running OSGi instances use to populate themselves upon startup. Our product description file is used at runtime, not build time. I guess these are things that would need to be kept in mind. Jeremy On 5/5/07, Andreas Ronge <[EMAIL PROTECTED]> wrote: > > 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. > > I agree. > This is an interesting question: how to only use the OSGI manifest for > compile time dependencies in order avoid duplicated dependency > information. > > The PDE resolve dependencies against a Target Platform + workspace projects. > My builder equinox plugin generates an PDE target platform by downloading > bundles using the product ivy.xml file. > > I think it is possible to remove all the ivy.xml files for bundle > projects and only have OSGi metadata. But we still need a top > configuration file in order to specify which bundles should be > included in a product and their start levels (as my product > ivy.xml file specifies) > > /Andreas > > > > > 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 > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > _______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
