Greetings,

We're looking to re-implement/replace our current continuous
integration system, which has been building our OSGi project for the
past 10 months or so.  The current builder was quickly hacked together
over a period of a week, and we're starting to run into its
limitations now that our project has surpassed 150 bundles.

Some of the big requirements that we set for our current system were:
1. Automatic discovery of new bundle projects in the source
repository.  We didn't want to configure the builder each time we
added a new bundle to the project.
2. Build as much as needed, but no more.  Based on what was changed
since the previous build, we wanted to use OSGi dependency analysis to
figure out what needed to be built (i.e., changed bundles and bundles
depending upon them).  Because of this need, the builder must be able
to fetch dependencies required for build from our bundle repository.
3. Resolve build dependencies based upon OSGi metadata (not, for
instance, Maven dependencies).
4. Build Eclipse PDE bundle projects, since that's what we use as our
development environment.

To cover these requirements, we wrote a custom continuous integration
system consisting of:
1. A repository scanner (written using JavaSVN) able to detect new
projects in our repository; and
2. A bundle builder based around Eclipse PDE export operations.

We did not use the PDE build system but rather do the equivalent of
launching an Eclipse instance, selecting bundles and invoking "Export
Deployable plug-ins and fragments".

This system has worked fairly well for us.  However, it's becoming
slower and slower, and it is not easily extensible.  We'd like to be
able to make use of some existing builder for integrated
testing/reporting/etc.

I've noticed that a lot of people are using Maven to build OSGi
bundles.  However, as far as I can tell, Maven requires its own
dependency format, and cannot be extended resolve based upon OSGi
dependency metadata. Please correct me if this is incorrect.

Does anyone have any systems similar to this, or any pointers to build
systems that can be easily extended to support these types of
features?

Thanks,
Jeremy Volkman
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev

Reply via email to