Hey,
Just attached a new patch on ACE-32 which also includes the new pax
runner
version 1.2.1.
Plus:
1. Flexible Development Targets
with "ant package" you will get pax runner based configuration
scripts for
the afromentioned targets in the usual deploy/target/ folders.
(runDev.sh, runDev.bat)
2. Standalone Outputs (just as before, but flexible as paxrunner
generates
many things)
with "ant zip" a pax runner instance will pre-load all requirements
and
config files and zip them up at the usual release folder.
3. Single Point of Entry
All target relevant configuration now sits in
conf/{target}/platform.properties (just parameters) and
platform.setup (all
bundles required as well as pax runner options).
Target Framework and Version "can" be set in platform.properties but
is
super-configured by settings made in "packageDevelopment" and
"packageProduction" targets in build.xml.
(currently it is Felix 2.0.0)
Though we should really change the artifacts to at least match some
the
snapshot version classifier.
(0.8.0-SNAPSHOT i would suggest). Cause this shows there is already
some
meat behind (liQ).
This way, we could easily go on with ACE-18 (maven exports)
On Mon, Sep 21, 2009 at 10:56 PM, Marcel Offermans <
[email protected]> wrote:
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
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)
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)?
Not yet, feel free to suggest. ;)
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).
Agreed.
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/.
Can we also make this work when deploying to your own local Maven
repository (keeping everything you need local)?
yes, we can !
This would make starting with ace very simple:
./pax-run.sh --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:
./pax-run.sh --profiles=org.apache.ace.framework-with-ma
-Ddeploymentpackage=file:dp/ace-server.dp
For launching with a deployment package.
Already thought about it before.
Actually more in a form of a url handler like so:
pax-run.sh dp:composite:file:local/profile/pr.composite
where: dp:[CompositeURL] turns any composite (which is a list of
bundles as
plain test file, which are the root of pax runner profiles) into a
deploymentpackage..
This way we can do it easily. Will have a look at it soonish.
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 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
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
[email protected]
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
