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 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 ? 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. 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 -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
