ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Using Pax Runner as prime deploy/target framework ?
Date Sun, 05 Jul 2009 10:52:06 GMT
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.


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

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/ (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  
  - 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.


Greetings, Marcel

View raw message