Hello Toni,
On Jul 5, 2009, at 1:39 , Toni Menzel wrote:
As part of ACE-32 i am looking in how we can integrate ready-to-use
Pax Runner Configurations into the build.
Great!
For the impatient, assuming you have pax runner installed, you can
launch most dev-* with something like
pax-run.sh --clean --log=debug
--vmo="-Dorg.apache.ace.configuratorCONFIG_DIR=../conf" bundle
while adding more options (like http port etc.) to the --vmo option
value depending on the target.
Critical parts are:
-- value of org.apache.ace.configuratorCONFIG_DIR=../conf
-- Folder of bundles to start (bundle in the sample above)
Its easy to create all those from the build.xml as part of the
package target.
Actually, the tricky part is: what are those (quite many) targets
for ?
The general answer is, there are many different deployment topologies
for the system, and these targets, when combined (and configured) in
the right way, support these topologies.
Sure, they offer a set of ready-to-use felix configurations. But the
felix part totally drops out when using pax runner. The only
interesting part left is:
- additional configuration passed in conf/config.properties (felix)
--> they go into pax runner configuration
- the list of bundles to be loaded. This is currently just a folder.
Correct, the existing configurations mainly deal with exactly the two
things you mention: what bundles must be started and what additional
configuration applied. What PAX adds to this is an easy way to do that
for an arbitrary framework, which makes it easier to use, develop and
test on different frameworks.
Questions that arised while doing this:
1. what do you prefer the ant script should drop out: a
1a. script that uses pax runner ?
Benefits: the user can choose from the full set of pax runner options,
including framework versions and flavours, ace components can be also
defined as simple profiles (list of bundles)
Drawbacks: pax runner needed at runtime, different thing than the
current setup
1b. script(s) for felix, equinox, knopflerfish, generated by pax
runner at BUILD-time
Benefits: the scripts deal just with the final framework, basically
just as before but with plenty of framework outputs (done by pax
runner at build-time
Drawbacks: no pax runner magic at runtime. User does not have the
choice anymore
As of me, i am fully for 1a. Just want to show that we can also have
something like 1b.
I'd say, it depends on the user:
- If the user is a developer, I agree that having the flexibility of
1a is a nice feature, allowing easy switching of frameworks and
versions.
- If he's an end user, just wanting to get the system up and running
and using it, he probably doesn't care., so 1b.
For 1b you say PAX runner can create a script, nod needing PAX runner
anymore at runtime? That would be ideal for people who "just want to
run it", especially if that means you don't even have to be online
anymore (I understand that for 1a, PAX gets artifacts from maven
repositories)? For those people I would like to have a system, like
now, where you can just "unzip" an archive and run it (no additional
downloads after that).
The main deal here is that configuration has to be set in a different
way than currently (just the felix configs!! the configurator stuff
stays as is)
As i see it currently, it is errorprone to syncronize the old
(currently in svn) and new way when it comes to changes in
configuration. (different ways to do it)
Which leads me to Question 2.
2. Are all targets current, meaningful, equaly important, and
working ?
As least dev-client does not look like feasable currently. At least
there are swing/forms jars copied but not recognized by felix..
dev-gateway, dev.obr + dev.server currently look like a something that
is very basic and will be used by almost any novice.
Anything other is (to me) just a flavour change..?
Not all of them are. As you correctly mention, the "dev-client" is
incomplete because the Swing related components were not donated
(instead a new web based UI will be created). I mainly put in a set of
targets as an example, we have to start figuring out what topologies
we want to support and document them.
So, what is the deal with ACE-32 ?
I see the current "target" system as working and logical.
But when applying Pax Runner as a bootstrapper, i see many things will
change on that part.
As shown above, it is, at that point not a "copying arround config
files and replacing things in ant" anymore but a "is it okay to
mantain the configuration bits in a pax runner compatible way and drop
the ant scripts for that part" ?
At that point (for targets) you can think of a more declarative way
(maven like) instead of logical activities (ant like).
So, its also the question of interest and feedback. Thats why i shared
this topic in a bit more details.
Let's see...
As a first step, I would like to have PAX runner replace the now
hardcoded version of Felix for development purposes, so we can easily
run targets on different frameworks. As far as I understand that would
not be too difficult, we would mainly have to change the way in which
some configuration settings are added. PAX runner could still use a
directory containing all bundles.
As part of this first step, I would like to see two types of targets
being deployed:
1) developer oriented targets, that use PAX runner directly
2) end user oriented targets, that use PAX runner to generate scripts
to launch our pre-defined framework (Felix)
The next step becomes more interesting, as in that step we could start
looking at how we actually define and deploy "profiles". Instead of
taking this directory of bundles as a starting point, we could define
a profile in a different way and simply launch a target with the name
of that profile. In the end of course, we should use our own
provisioning system to provision ourselves. In that case, we would
need the runner to get a profile that just contains our management
agent and some unique identification of the target. How you actually
want to do this probably depends on the types of targets you are
creating. For example, if you create a desktop client based on Swing,
you might want to use Java Web Start to bootstrap the framework and
embed the management agent as part of the system bundle (to keep
everything in one JAR file and have an update mechanism for framework
plus management agent). For a server target, the launcher might be
different again, because it might be an operating system service. For
other targets we also have used native wrappers, so you can double
click on an .exe or .app or whatever your OS uses as an extension.
To be honest, PAX runner is probably not designed to be all of these,
but for development and testing it is the most flexible solution I
know, so I would definitely want to try that first step mentioned above.
WDYT?
Greetings, Marcel
