Tools for building and testing - Enterprise OSGi in Action - page 203

OSGIJC
An alternative to the Eclipse headless build is a third-party tool called osgijc. Osgijc is
a replacement for the Ant <javac> task that reads the contents of an Eclipse .classpath
file and adds it to the compile classpath. Users will need to manually add in their own
classpath entries for bundles that haven't been explicitly included in the .classpath
file. The most convenient way of doing this is to add the directory containing the tar-
get runtime to the Ant classpath.
Unlike the Eclipse headless build, osgijc doesn't validate that a bundle imports all
the packages it needs to compile, or that those packages have been exported by some
other bundle. Despite the name, osgijc does a conventional Java compile in a flat and
open class space.
The osgijc tool, therefore, relies on manifest validation having been done earlier,
in the IDE environment. If team members inadvertently deliver code that couldn't
compile in Eclipse because of missing manifest imports or exports, osgijc will build
the broken bundle without complaint. Problems will only be discovered during the
test phase when classes can't be loaded.

ROLLING YOUR OWN, CHEATING, AND OTHER OPTIONS
The osgijc tool isn't complex, and many teams opt to roll their own Ant tasks to con-
sume Eclipse metadata instead. Parsing the Eclipse .classpath file allows you to identify
what other projects need to be on an individual project's classpath, and then you can
bulk-add the bundles from the target OSG i environment. If you're feeling enthusias-
tic, you can even read in all the .classpath files to work out the right order to build the
projects, so that all the dependencies get built in the right order. But unless you parse
the MANIFEST.MF files themselves (at which point you're venturing dangerously close
to writing your own OSG i framework), you'll still be dependent on the Eclipse IDE to
validate that the manifests are as they should be.
A more basic approach, which can be effective for many smaller projects, is to
manually maintain both the IDE .classpath and Ant or Maven build files in parallel.
Although this violates the software engineering practice of not writing anything down
more than once, you may find it's a simple and pragmatic solution to getting things
building. (This is how the Fancy Foods sample code is built, for example.)

8.2.4 Maven Tycho

Although most attempts to build OSG i bundles from Eclipse projects have focused on
Ant, a promising new project called Eclipse Tycho brings together Eclipse and Maven.
Tycho reuses Eclipse metadata to keep pom files small and ensure that automated
builds behave the same way as builds within the IDE . Tycho appears to be providing a
true manifest-first OSG i build, rather than building in a flat classpath and relying on
the IDE to catch manifest problems.
Because it's so tightly integrated with Eclipse PDE , Tycho is a peculiar hybrid of
Maven and Eclipse. Many familiar Maven idioms have disappeared. The default disk
layout for source and resources is an Eclipse layout, rather than a Maven one. You no