The only way I do this is for my clients to compile and export only the binaries then I then do a search of the fold for updated (current date) files. I then zip those and provide a link to my clients. they download and run the zip file if they are using linux then it downloads the zip exports the files and deletes the zip.
Most of my clients are running on servers I host it is part of the service. Christopher Snow sent the following on 2/27/2010 10:19 AM: > Hi BJ, I was hoping a binary patches could be made available without > users have to use svn. > > The "should" be possible with the framework, but the applications would > be harder to patch because they usually require customization. > > BJ Freeman wrote: >> there are two forms of customization that lend them selves to begin >> patched. >> The suggested in best practices is using hot-deploy for all >> customization. >> The one I use is additional folders at the ofbiz-home level. >> either way core patches for ones distribution, should be done locally. >> this is easily accomplished by use the svn to create patches once the >> image is up and running with no modification. >> >> when I want to update from the trunk I make a separate folder to put in >> the new version >> then I add my customization and test it, once satisfied I update my >> original code. >> >> >> >> >> >> >> >> >> Christopher Snow sent the following on 2/27/2010 8:06 AM: >> >>> Hi Forum, >>> >>> I've been pondering how a stable binary release of ofbiz (i.e. upcoming >>> 10.04) could be kept up-to-date with the latest patches. One potential >>> method would be have each components' config directory configurable to a >>> folder external to the $OFBIZ_HOME, in the case of linux this may be >>> /etc/ofbiz/ - this would enable binary patches (e.g. replacement >>> ofbiz-entity.jar) to be provided that wouldn't over write any existing >>> configuration. This mechanism could work for a standalone ofbiz >>> framework on the premise that binary users do not want to modify the >>> framework code. >>> >>> A mechanism for providing the applications would be more difficult I >>> guess because the assumption would be that the applications almost >>> always have to be customized to fit the individual business? Any >>> thoughts? >>> >>> Many thanks, >>> >>> Chris >>> >>> >>> >> >> > >
