felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch" <mccu...@gmail.com>
Subject Refactored Spring-OSGi maven build (strawman)
Date Thu, 15 Mar 2007 11:34:57 GMT
Hi Alin (and others interested in maven, osgi and eclipse)

FYI, here's a strawman refactoring of the Spring-OSGi project core which
should generate working Eclipse files, and minimise the steps needed to
keep things up-to-date.


Please let me know your views - this is a radical change to the structure,
but I think there are useful tips+hints in there for existing/future projects...

It uses the felix maven bundle plugin, which really helps with imports/exports!

Cheers, Stuart

ps: I live in Malaysia (UTC+8), so may not answer emails immediately :)

---------- Forwarded message ----------
From: mcculls@ops4j.org <mcculls@ops4j.org>
Date: 15-Mar-2007 19:10
Subject: svn commit: r5818 - in laboratory/users/stuart/spring-osgi-refactored
To: notify@lists.ops4j.org

Author: mcculls
Date: Thu Mar 15 12:10:12 2007
New Revision: 5818

A cut-down, refactored version of the Spring-OSGi project

Builds without requiring snapshot repositories and generates working
Eclipse project files.

  ( caveat: only tested on my macbook using Maven 2.0.4 and Eclipse 3.2.1 ! )

The refactored project uses pluginManagement sections to pass
configuration/version details to sub-projects, who then only need to
declare which plugins are active for their build.

This means the project can have a true hierarchical structure:

  bundles       -   all OSGi bundles
  \_wrappers    -   wrapped jarfiles
    \_common    -   common libraries
    \_spring    -   Spring framework
  \_published   -   OSGi ready libraries (migrated from common)
  \_source      -   Spring-OSGi code

  tools         -   maven archetypes (see bundle.lst files for example usage)

I decided stop refactoring once I got the core bundles working, so I
could get feedback on this as a strawman (rather than refactor all the
testcases, which is still a moving target).

Some of the antrun magic can be removed once a number of pending
patches go into the maven bundle plugin, but this won't upset the
strucure - just means less plugins in the project.

The bundle specs have all been reduced to a few lines, as the BND tool
can generate import and export directives by analyzing the classes. I
removed all uses of DynamicImport-Package, which may mean some of the
AOP bundles won't work, but it's simple to add back any must-have
directives (just add them to the local src/main/resources/details.bnd

I tested the generated bundles with the simple sample bundle from the
original project, and it appeared to work ok - the unit testcases also
pass for the internal Spring-OSGi bundles.


The top-level pom only contains critical information from the original
pom, required when building artifacts - it doesn't setup any
developer/release/site/reporting stuff and just has a profile for
Equinox (though adding the other profiles is just a copy+paste).

This project uses a patched version of the maven-bundle-plugin
(FELIX-218) which is injected into the local repository from an
embedded file repository in tools/maven2/patched-artifacts.

A sample log4j.properties file is pre-included in the log4j bundle to
help people new to OSGi. Others may want to delete this and use the
fragment technique demo'd by BJ Hargrave, or use the Pax-Logging
bundles instead.

The group/artifact/version conventions are up for grabs - I went for
the simple approach.

View raw message