ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <>
Subject Using Pax Runner as prime deploy/target framework ?
Date Sat, 04 Jul 2009 23:39:36 GMT
As part of ACE-32 i am looking in how we can integrate ready-to-use
Pax Runner Configurations into the build.

For the impatient, assuming you have pax runner installed, you can
launch most dev-* with something like --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 ?
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/ (felix)
--> they go into pax runner configuration
- the list of bundles to be loaded. This is currently just a folder.

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.

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..?

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.

Any comments and "i am confused but .." Mails are appreciated.


Toni Menzel
Independent Software Developer
Professional Profile:     - New Energy for OSS Communities - Open
Participation Software.

View raw message