OFBiz and Environment Configurations

[JS <jo...@gmail.com>]

Hi folks,

I'm hoping you have some ideas as to how I can accomplish something in
OFBiz. In my other Java applications, I maintain separate properties files
for each environment I will build my application, such as "testing",
"development", "live". In these files I maintain things like database
connection strings, and other environment-specific settings.

I was able to find this mailing list post from back in April:
http://ofbiz.135035.n4.nabble.com/Environment-Specific-Configurations-Best-practices-td4640727.html.
>From the way I understood this approach, an vanilla version of OFBiz is
stored in the SVN, and using the add-on manager, you're able to create
add-ons which will replace existing files or add new ones (in my case, this
would be properties files), as well as add in all of the custom
applications on top of the default OFBiz codebase.

This seems overkill for my needs; ideally, I would like to keep my already
existing codebase in the SVN (which already contains my hot-deploy apps)
and add the ability to designate an environment during the deployment
(test/development/live), which would put the respective property files on
the classpath. Just wondering if the add-on manager in this approach adds
any additional capabilities that would outweigh using a modified ant
script, or a custom shell script?

Additionally, if there are other approaches to solving the issue that I
haven't considered, please advise.

Thank you!

Re: OFBiz and Environment Configurations

[Jacques Le Roux <ja...@les7arts.com>]

Nope, OOTB they are only placeholder names (actually I have something but it's specific)

I simply added them at some point because they made sense to me.
You could have a qa between those and staging should then be rather test.

So you would have those areas:
dev (local devs machines) -> test (test cluster for load test and such) -> qa (same cluster than prod but not live) -> prod (real live system)
each whith different sets of patches.

Then you might use https://ant.apache.org/manual/Tasks/patch.html according to your needs
Note: <!-- patch task can't handle a fileset --> => use <concat

I let you figure out what you need  ;)

HTH

Jacques


JS wrote:
> Jacques Le Roux wrote
>> I believe most of us use sets of patches. The add-on way, for now, is
>> mostly used by the Neogia community.
>> 
>> Jacques
>> 
>> Adrian Crum wrote:
>>> Then follow the first reply: Maintain a set of patches - one for each
>>> environment.
> 
> Adrian, Jacques,
> 
> Thank you for the guidance. I'm essentially trying to stick as close to the
> out of box OFBiz install as possible to ensure that I'm able to smoothly
> upgrade to newer versions in the future, etc.  After your mention of using
> patches, I went through my components and realized that the
> "create-component" target in the OFBiz build.xml creates a /patches
> directory with two sub-directories: staging and production. Is there some
> significance to these directory names, i.e. can you run something like: "ant
> <some target> staging" to have the patches in the staging directory
> automatically applied, or are they simply placeholder names, and you still
> have to run 'patch' manually?
> 
> Thanks for the help

Re: OFBiz and Environment Configurations

[JS <jo...@gmail.com>]

Jacques Le Roux wrote
> I believe most of us use sets of patches. The add-on way, for now, is
> mostly used by the Neogia community.
> 
> Jacques
> 
> Adrian Crum wrote:
>> Then follow the first reply: Maintain a set of patches - one for each
>> environment.

Adrian, Jacques,

Thank you for the guidance. I'm essentially trying to stick as close to the
out of box OFBiz install as possible to ensure that I'm able to smoothly
upgrade to newer versions in the future, etc.  After your mention of using
patches, I went through my components and realized that the
"create-component" target in the OFBiz build.xml creates a /patches
directory with two sub-directories: staging and production. Is there some
significance to these directory names, i.e. can you run something like: "ant
<some target> staging" to have the patches in the staging directory
automatically applied, or are they simply placeholder names, and you still
have to run 'patch' manually?

Thanks for the help




--
View this message in context: http://ofbiz.135035.n4.nabble.com/OFBiz-and-Environment-Configurations-tp4644384p4644570.html
Sent from the OFBiz - User mailing list archive at Nabble.com.

Re: OFBiz and Environment Configurations

[Jacques Le Roux <ja...@les7arts.com>]

I believe most of us use sets of patches. The add-on way, for now, is mostly used by the Neogia community.

Jacques

Adrian Crum wrote:
> Then follow the first reply: Maintain a set of patches - one for each
> environment.
> 
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
> 
> On 10/2/2013 8:56 AM, JS wrote:
>> Hi folks,
>> 
>> I'm hoping you have some ideas as to how I can accomplish something in
>> OFBiz. In my other Java applications, I maintain separate properties files
>> for each environment I will build my application, such as "testing",
>> "development", "live". In these files I maintain things like database
>> connection strings, and other environment-specific settings.
>> 
>> I was able to find this mailing list post from back in April:
>> http://ofbiz.135035.n4.nabble.com/Environment-Specific-Configurations-Best-practices-td4640727.html.
>>  From the way I understood this approach, an vanilla version of OFBiz is
>> stored in the SVN, and using the add-on manager, you're able to create
>> add-ons which will replace existing files or add new ones (in my case, this
>> would be properties files), as well as add in all of the custom
>> applications on top of the default OFBiz codebase.
>> 
>> This seems overkill for my needs; ideally, I would like to keep my already
>> existing codebase in the SVN (which already contains my hot-deploy apps)
>> and add the ability to designate an environment during the deployment
>> (test/development/live), which would put the respective property files on
>> the classpath. Just wondering if the add-on manager in this approach adds
>> any additional capabilities that would outweigh using a modified ant
>> script, or a custom shell script?
>> 
>> Additionally, if there are other approaches to solving the issue that I
>> haven't considered, please advise.
>> 
>> Thank you!

Re: OFBiz and Environment Configurations

[Adrian Crum <ad...@sandglass-software.com>]

Then follow the first reply: Maintain a set of patches - one for each 
environment.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/2/2013 8:56 AM, JS wrote:
> Hi folks,
>
> I'm hoping you have some ideas as to how I can accomplish something in
> OFBiz. In my other Java applications, I maintain separate properties files
> for each environment I will build my application, such as "testing",
> "development", "live". In these files I maintain things like database
> connection strings, and other environment-specific settings.
>
> I was able to find this mailing list post from back in April:
> http://ofbiz.135035.n4.nabble.com/Environment-Specific-Configurations-Best-practices-td4640727.html.
>  From the way I understood this approach, an vanilla version of OFBiz is
> stored in the SVN, and using the add-on manager, you're able to create
> add-ons which will replace existing files or add new ones (in my case, this
> would be properties files), as well as add in all of the custom
> applications on top of the default OFBiz codebase.
>
> This seems overkill for my needs; ideally, I would like to keep my already
> existing codebase in the SVN (which already contains my hot-deploy apps)
> and add the ability to designate an environment during the deployment
> (test/development/live), which would put the respective property files on
> the classpath. Just wondering if the add-on manager in this approach adds
> any additional capabilities that would outweigh using a modified ant
> script, or a custom shell script?
>
> Additionally, if there are other approaches to solving the issue that I
> haven't considered, please advise.
>
> Thank you!
>