> 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
