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 cleanTargetsToni On Tue, Oct 6, 2009 at 12:42 PM, Toni Menzel <[email protected]> wrote: > Hi Angelo,Thanks for looking into it. > See below. > > Toni > > On Tue, Oct 6, 2009 at 12:13 PM, Angelo van der Sijpt < > [email protected]> 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 < >>> [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. >>> >> >> > > > -- > Toni Menzel > Independent Software Developer > Professional Profile: http://okidokiteam.com > [email protected] > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. > > -- Toni Menzel Independent Software Developer Professional Profile: http://okidokiteam.com [email protected] http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software.
