ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <>
Subject Re: Migration to Pax Runner...
Date Mon, 21 Sep 2009 20:56:25 GMT
Hello Toni,

On Sep 21, 2009, at 11:18 , Toni Menzel wrote:

> Glad you asked, Angelo and I had further discussions on gchat and  
> agreed on
> a way to go.
> Here's the current status (lengthy version;)

Thanks for the warning! ;)

> PART 1: General things
> First of all, what makes ace assemblies so different from other Pax  
> Runner
> setups:
> a. Artifacts are flat file artifacts up until now (See
> for some thoughts on this)
> b. Artifacts are highly configured through config files who must be  
> at a
> certain place on startup
> We can (and should) overcome [a] easily. (see ideas on using Pax  
> Runner
> Profiles in part 3)

Agreed, see below for comments on ACE-18.

> [b] means:
> we cannot just provide a single Pax Runner config file. We need to  
> copy
> those configuration files to a certain position.

Like you say, a target consists of code (a set of bundles) and  
configuration (now done with our configurator which reads  
configuration files from a directory, but essentially anything that  
imports Configuration Admin configs should do, we also have code to  
use the XML format defined in the Auto Config section, which is used  
together with the resource processor.

In the end we should be able to deploy all these targets using  
deployment packages (containing bundles and configuration).

Have you thought about adding some kind of support for configurations  
to Pax Runner (except the system properties)?

> PART 2: Result of discussion so far
> We need a number of pre-defined targets: a default target, a default  
> server,
> a server-obr combo, etc.
> For each of these, we would like a 'release' version containing a  
> framework
> of our choice (latests felix), and does not require anything else at
> runtime.
> The 'dev' version is based on pax runner, can be configured to use any
> framework you like, and contains possibly some additional bundles  
> (e.g. for
> logging)
> So, that would lead to something like six target xml's, resulting in  
> twelve
> directories in the deploy/target directory.
> Each of those targets will be produced by Pax Runner.
> Release targets will have no pax runner reference and will be static  
> to
> known (recommended?) target configuration set.
> Benefit of using Pax Runner even in that scenario instead of the  
> current way
> is (amonngst others): simple to switch to a different frameework and
> version, same "language" used to define the assembly as in dev-  
> versions
> (who will be just a pax runner config file).


> PART 3: Ideas on using profiles
> One other thing i see  as well:
> Pax Rummer has the notion of profiles / composites.
> So, if we decide to publish ace artifacts to a snapshot repository  
> (maven)
> somewhere, we can add ace profiles for each target here:

Can we also make this work when deploying to your own local Maven  
repository (keeping everything you need local)?

> This would make starting with ace very simple:
> ./ --profiles=org.apache.ace.gateway
> and in exam:
> profile("org.apache.ace.gateway")

Agreed, I would definitely like this if we can find some way to  
provide the configuration along with the bundles.

I would also like something like:

./ --profiles=org.apache.ace.framework-with-ma - 

For launching with a deployment package.

> anyhow, this depends on how simple we can integrate the bridge to  
> maven (ant
> will keep being the buildsystem for ace as far as i know).
> See

I think you already mentioned the biggest issue, the different  
versioning scheme that Maven uses (having to use "snapshot" names for  
anything that's not a release). I think we should be able to come up  
with some kind of scheme for that.

> I will provide a new patch for ACE-32 to meet the criterias in PART 2.

Ok, thanks!

Greetings, Marcel

View raw message