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 19:21:11 GMT
On ACE-32 there's now a new version that mostly refines the issues with
zip/production output:- separate deploy/target/{targetname}-production/
- cleaner content (no runDev.sh and platform-* descriptors anymore)
- new task cleanTargets

Toni

On Tue, Oct 6, 2009 at 12:42 PM, Toni Menzel <toni@okidokiteam.com> wrote:

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


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