ace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toni Menzel <t...@okidokiteam.com>
Subject Re: Migration to Pax Runner...
Date Tue, 06 Oct 2009 10:42:29 GMT
Hi Angelo,Thanks for looking into it.
See below.

Toni

On Tue, Oct 6, 2009 at 12:13 PM, Angelo van der Sijpt <
angelo.vandersijpt@luminis.nl> wrote:

> Hi Tony,
>
> I just checked the patch, and for the most part it looks good: targets
> work, and I like the idea of being to produce a standalone zip without the
> need for managing our own framework.
> However, I do have some issues with the proposed solution,
> - The runtime properties show up in a number of locations in the release
> versions, both in the .sh and .bat, and in the config.properties. I would
> prefer it if they would only be set in the config.properties file.
>

I guess you refer to the zippped version cause i don't see duplications in
the normal package output.
In the zipped output (release) platform-* files are irrelevant cause pax
runner is out of business at this stage.
So, yes, they should not be zipped up.
Same for runDev.sh / runDev.bat.

However, i saw the properties show up still in run.sh + felix's config which
is unclear to me why pax runner does this.
Will check this out.


> - We now have fixed references to the targets we want to create in the main
> build.xml. Would it be possible to, for instance, make one target that
> checks for the existence of a platform.setup in any of the conf/<target>
> directories?
>

Okay, so, let me try to see what what you really want in the end. Is it the
fact that the targets are referenced one by one in build.xml or is it just
that it should not be done if no platform.setup is present.
I really thought of migrate and fix the targets we want and drop all others.
Same time i would like to get rid of dev-*.xml xmls cause things are
happening in platform.setup/properties only.
So, in the end there should not be a target witihout platform.setup anymore.

About referencing them hard instead of iterating over folders: i am not sure
about this. Of cause it would be simple to do, but somhow i see benefit in
mentioning them in "package" and "zip" so one could enable/disable targets
easily.

Though this is all ANT hackery and could be different of a more declarative
thing is in place (maven.. okay that was my last shot on
this list about this .. for this week ;))



> - We are now no longer able to build the existing targets, since the
> 'package' target has been reused. I agree that most of these are no longer
> necessary, might it be an idea to just remove them for now?
>
yes (see above).

Before (in older patches) i had extra targets for the new stuff.
But somehow i got confused by myself, too and i think this is not a good
sign in general.
Also, we will need to remove the target-dev-*.xml   because they now contain
duplication.

In the very end, one should just deal with conf/{targetname}/ to change
target settings. Thats at least my (current) conclusion.


> My two cents,
>
> Angelo
>
>
>
> On 6 Oct 2009, at 00:28, Toni Menzel wrote:
>
>  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 <
>> marcel.offermans@luminis.nl> 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
>> toni@okidokiteam.com
>> http://www.ops4j.org     - New Energy for OSS Communities - Open
>> Participation Software.
>>
>
>


-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message