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;) ---- 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 http://issues.apache.org/jira/browse/ACE-18 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) [b] means: we cannot just provide a single Pax Runner config file. We need to copy those configuration files to a certain position. 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: https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/. This would make starting with ace very simple: ./pax-run.sh --profiles=org.apache.ace.gateway and in exam: profile("org.apache.ace.gateway") 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 http://issues.apache.org/jira/browse/ACE-18 ---- I will provide a new patch for ACE-32 to meet the criterias in PART 2. Anyone additional thoughts ?? Cheers, Toni On Mon, Sep 21, 2009 at 10:35 AM, Marcel Offermans < [email protected]> wrote: > Toni, Angelo, > > I was wondering what the current status is of migrating all targets to Pax > Runner? There has been a lot of discussion in > http://issues.apache.org/jira/browse/ACE-32 about this. Is there anything > I can do to help? > > Greetings, Marcel > > -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
