On 21/03/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
Hi Stuart,
Looks very interesting, just a comment though about maven usage, you can do
mvn org.ops4j.osgi.tools.maven2:osgi-project-plugin:create
-DgroupId=simple.project -DartifactId=osgi.web.app
and same for all the other calls where you pass your custom settings.xml
True - the reason I provided the settings.xml fragment was in case people
wanted to add it to their existing settings, as you can then use the shorter
"mvn osgi-project:create ..."
This is what I had in the original script, but rather than get people to install
the fragment I thought I'd drag it in using "-s" and still show the shorthand
version ... I definitely need to document this somewhere ;)
I'm probably abusing several maven conventions, but I wanted to provide
short commands that people could remember, while still using archetypes
and plugins underneath.
Also, instead of the shell script you can make osgi-project:install
and osgi-project:compile run by default in the install and compile
phases with the <executions><phase> config so running only mvn would
call that tasks
Ah, actually "osgi-project:install" is a shortcut call to the archetype
to add a new "installed" bundle to the build. Similarly, the "compile"
mojo adds a new "compiled" bundle. It wouldn't make sense to call
these during every build lifecycle as they're just there to help setup
the initial layout and don't participate in the actual build.
I should probably rename them to "add-install" and "add-compile"
to avoid confusion! And I agree it would make sense to add the
runner mojo to the build.
Thanks for the feedback - hope you find some of the ideas useful.
On 3/20/07, Stuart McCulloch <[EMAIL PROTECTED]> wrote:
> 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.
> >
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
