Using Pax Runner as bootstrap
Alin Dreghiciu
What about using Pax Runner (http://wiki.ops4j.org/confluence/x/A4A6)
for starting up ModuleFusion. Advantages I can see on short notice:
1. Support for Felix and Equinox (virtually any version) +
Knopflerfish. Any any other that may be added in the future. This will
make easy for users to test/use any version they require. The only
"problem", I see right away is that pax runner does not know to use
the already present jars that were downloaded, but I can find a
solution for that if you guys are interested.
2. Initial provision of bundles form different sources as for example
maven repositories, directory scanning, zips, url... This will make
easy for a developer to setup which bundles he wants to deploy along
with already available from ModuleFusion
3. Easy framework setup as for boot delegation, framework packages,
execution environment, ...
So, if you find it interesting let me know and lets discuss how we can
implement that.
Alin Dreghiciu
Alin Dreghiciu
---------- Forwarded message ----------
From: Alin Dreghiciu <adreg...@gmail.com>
Date: Mon, Sep 22, 2008 at 7:12 PM
Subject: Re: Using Pax Runner as bootstrap
To: Roman Roelofsen <roman.r...@googlemail.com>
I may not even need one, but sounds a nice to have at least to be able
to start up/test against virtually any version any of
felix/equinox/knopflerfish just as a cost of command line switch. More
it abstracts the user for knowing how to setup / configure
specifically for each platform as pax runner will make that for you.
Of course that all of this benefits are = 0 when you only deploy to
one platform and you already know the version :)
Another useful option are the scanners and divers url handlers. Yo may
have a zip of bundles tou wanna install, you may have then in a
directory (as in dirinstaller), or you may specify them in a file.
They all works and are pretty handy when it come to initial
provisioning of bundles. Adn you may have as many of this scanned
sources as you want to combine in order to fulfill your need. Then
with the mavn url handler is quite easy to reference a bundle to be
installed that can come up form your local repository, maven central
or any other one. And the mvn:protocol know how to take a specific
version, latest one or choose the highest from a range.
Then there are some others as the wrap: one. Easy to bundle-ize any
classic jar, using default instructions or custom ones. On the fly, nu
previous build required, the war:/war-i: protocol handlers that takes
a WAR file as we know it and "transforms" it into a bundle that can by
picked up by Pax Web Extender.
Also note that all parts of Pax Runner (beside bootstraping and some
glue code) are standalone osgi bundles that can perform their job
without being part of Pax Runner. E.g. mvn: protocol handler can be
deployed as a standalone bundle and will bring the mvn: protocol in
any running osgi framework. Same with scanners.
Now about the "self containing directory"-way: Pax Runner does not
contain by default any bundle. Depending on your scanners/urls the
bundles will be "downloaded" to a local cache directory and those
bundles will be used to instruct the target platform to load. Once
abundle is already in the cache the bundle will not be downloaded
again only on a special request (option in the scanner url) or when
you specifically instruct Pax Runner to do so via command line
options. This bundles are stored in a "working directory" which is by
default a subdirectory of the current directory, named "runner". This
directory can be configured. Due to this you can take an directory
where Pax Runner already has been started, move it to another computer
and fire it up.
Here is a point where some work has to be done as in ModuleFusion
scenario it will be nice that bundles that are already included into
the distribution to be found by Pax Runner before he does it's job of
downloading those artifacts.
The dir installer indeed overlaps a bit the DirInstaller functionality
but not really. The fact that both deploy the bundles in a directory.
But scanner-dir: from Pax Runner does that only as initial
provisioning and does not handle future changes in that directory
afterwards, as DirInstaller does. Also it does not handle
configurations found in that directory. And yes, they can work
together without any problem.
P.S. There is a plan to support the re-scan for bundles with scan-dir
and other scanner but we never put it in practice.
BTW (curious), this functionality resembles very much Peter's K.
FileInstall. Did you already had it? Or there is another reason why
file install was not used.
> We never felt the need to have some help with the bootstrapping.
> However, Pax Runner certainly looks interesting and I will look at it
> more in detail over the next couple of days. Is it possible to use pax
> runner in a "self containing directory"-way? E.g. where will the
> platforms be saved on the disk? User-wide, local to the pax runner
> installation or local to the current dir? An important requirement for
> MF is, that I can zip a ModuleFusion installation, copy it to another
> machine and directly use it.
>
> There will be some overlap with DirInstaller (http://code.google.com/p/
> modulefusion/wiki/DirInstaller) but it should not be a problem to use
> both at the same time.
>
> Cheers,
>
> Roman
>
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
http://malaysia.jayway.net - New Energy for Projects - Great People
working on Great Projects at Great Places
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
http://malaysia.jayway.net - New Energy for Projects - Great People
working on Great Projects at Great Places
Roman Roelofsen
Thanks. I always forget the the shortcut 'A' in google groups is
different from google mail :-/
> Participation Software.http://www.qi4j.org- New Energy for Java - Domain Driven Development.http://malaysia.jayway.net- New Energy for Projects - Great People
>
> --
> Participation Software.http://www.qi4j.org- New Energy for Java - Domain Driven Development.http://malaysia.jayway.net- New Energy for Projects - Great People
Roman Roelofsen
> to start up/test against virtually any version any of
> felix/equinox/knopflerfish just as a cost of command line switch. More
> it abstracts the user for knowing how to setup / configure
> specifically for each platform as pax runner will make that for you.
> Of course that all of this benefits are = 0 when you only deploy to
> one platform and you already know the version :)
different downloads since some bundles are different depending on the
platform you use. But it still helps to e.g. easily switch to a new
version.
> Another useful option are the scanners and divers url handlers. [...]
Yes, this sounds very nice and will be reason to look at it ;-)
> BTW (curious), this functionality resembles very much Peter's K.
> FileInstall. Did you already had it? Or there is another reason why
> file install was not used.
actually taken from fileinstall. We had some problems with the
behaviour of fileinstall (e.g. does not remember invalid bundles ->
repeating error messages) and some important features were missing
(e.g. scan all sub-dirs).
Hendy Irawan
wrote:
Hi, as long time user of Pax Runner, (and Pax-* for that matter) I'm
very interested if ModuleFusion can incorporate Pax-Runner.
It will mean less work for ModuleFusion developers for configuration
(since configuration will be uniform). With Pax Runner, it's possible
to have one zip with both Felix and Equinox (can be chosen at
runtime), or two individual zips like what it is now.
In addition, users will be able to use advanced Pax-Runner
functionality, like what I'm used to. It's a pain to revert back to
(manual configuration of) plain Equinox/Felix/* from Pax-Runner, but
it's very easy the other way around.
IMHO DirInstaller and Pax-Runner is not overlapping at all, just as
Equinox/Felix's autostart configuration vs. File/DirInstaller...
they're technically different things.
Roman Roelofsen
> Hi, as long time user of Pax Runner, (and Pax-* for that matter) I'm
> very interested if ModuleFusion can incorporate Pax-Runner.
>
> It will mean less work for ModuleFusion developers for configuration
> (since configuration will be uniform). With Pax Runner, it's possible
> to have one zip with both Felix and Equinox (can be chosen at
> runtime), or two individual zips like what it is now.
>
> In addition, users will be able to use advanced Pax-Runner
> functionality, like what I'm used to. It's a pain to revert back to
> (manual configuration of) plain Equinox/Felix/* from Pax-Runner, but
> it's very easy the other way around.
>
> IMHO DirInstaller and Pax-Runner is not overlapping at all, just as
> Equinox/Felix's autostart configuration vs. File/DirInstaller...
> they're technically different things.
of bundles (DS, ConfigAdmin, ...). It is therefore hard to provide one
zip file for both implementations. Also, we have to configure them
differently (e.g. setting system package versions) in order to be able
to use technologies like JTA.
We are still evaluating how to integrate PAX runner in the best
possible way.
Hendy Irawan
Pax-Runner has profiles, which make it possible to specify those "different set of bundles", and even other things that aren't part of an OSGi implementation, such as Spring and Spring-DM.
Using Pax-Runner in the cases you described would mean simply changing the profile, while all the bundles are available in the respective directories. (i.e. the "local repository", which is inside the zipped dist)
For example, to run with logging, Spring, and Spring-DM:
pax-run --profiles=spring-dm
Changing to equinox is simply with adding: --platform=equinox
More explanation: http://wiki.ops4j.org/confluence/display/ops4j/Pax+Runner+-+Spring+DM
--
Best regards,
Hendy Irawan
http://hendyirawan.com/
Roman Roelofsen
Thanks for the feedback! This certainly looks interesting!
We are currently working on ModuleFusion's infrastructure (build,
layouts, ...) so maybe we find a way to intergrate PAX runner more
tighter with profiles.
Cheers,
Roman