[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] Quickly setup OSGi projects using Maven
- From: "Stuart McCulloch" <stuart.mcculloch@xxxxxxxxxx>
- Date: Wed, 21 Mar 2007 12:12:53 +0800
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=EtJw/Y0vHMpQVFn8SJhFwBitgDdwn9s2iTHBp7+TrlFxo4Fnl3bIwH4ji96FWo26AymPzQtZvwuxxL3KggW6EfV9LX3kkuTBfdLUNTWZNOqe7kqcBdYxJpoiaE7c3cEhzEaC+AGeSv0Y9rYHkEgNATUVXS2oRBfgtN5bExQF3J8=
As a follow on to my refactoring experiment, I've just committed some
prototype maven archetypes & plugins I developed to help people get
started with simple OSGi projects (such as demos / tutorials).
If you're interested, you can use the following commands to try out the
example on Linux/Unix - Windows users will need to rework the script.
svn co https://scm.ops4j.org/repos/ops4j/laboratory/users/stuart/tools
# note: must use absolute path to run this script
# as it uses it to find the settings.xml fragment
( It uses a maven plugin to hide away all the standard archetype cruft. )
This should install the archetypes and use them to construct a simple
skeleton OSGi web-app project, which includes a jarfile wrapped as a
bundle, a number of released bundles, and a locally compiled bundle.
The generated project will build without any modification, and can be
imported and run inside Eclipse/Equinox - however, it won't do much,
as it's just a skeleton project.
The example script will also create a provisioning pom for Pax-Runner
and automatically deploy it on the Equinox framework (which will also
be downloaded if necessary).
If anyone has problems compiling/running the example, please send
me the error output (use -X flag if error appeared when running mvn).
On 15/03/07, Stuart McCulloch <mcculls@xxxxxxxxx> wrote:
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!
ps: I live in Malaysia (UTC+8), so may not answer emails immediately :)
---------- Forwarded message ----------
From: mcculls@xxxxxxxxx <mcculls@xxxxxxxxx>
Date: 15-Mar-2007 19:10
Subject: svn commit: r5818 - in laboratory/users/stuart/spring-osgi-refactored
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
The group/artifact/version conventions are up for grabs - I went for
the simple approach.