Hi folks, 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. cd /tmp mkdir TEST cd TEST svn co https://scm.ops4j.org/repos/ops4j/laboratory/users/stuart/tools cd tools mvn install cd ../.. mkdir PROJECT cd PROJECT # note: must use absolute path to run this script # as it uses it to find the settings.xml fragment sh /tmp/TEST/tools/example/SIMPLE_OSGI_PROJECT.sh ( 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). Cheers, Stuart On 15/03/07, Stuart McCulloch <[EMAIL PROTECTED]> 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. https://scm.ops4j.org/repos/ops4j/laboratory/users/stuart/spring-osgi-refactored 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: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: 15-Mar-2007 19:10 Subject: svn commit: r5818 - in laboratory/users/stuart/spring-osgi-refactored To: [EMAIL PROTECTED] Author: mcculls Date: Thu Mar 15 12:10:12 2007 New Revision: 5818 Log: 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 file). 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. NOTES: 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.
