Return-Path: Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm Delivered-To: mailing list ibatis-user-java@incubator.apache.org Received: (qmail 47861 invoked by uid 99); 7 Dec 2004 18:34:57 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of brandon.goodin@gmail.com designates 64.233.170.197 as permitted sender) Received: from rproxy.gmail.com (HELO rproxy.gmail.com) (64.233.170.197) by apache.org (qpsmtpd/0.28) with ESMTP; Tue, 07 Dec 2004 10:34:54 -0800 Received: by rproxy.gmail.com with SMTP id g11so293667rne for ; Tue, 07 Dec 2004 10:34:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=RD8tOMxTte84JKv5xS940gg+kJ+G9XQsBM+5wPECyg4Bye2rOcAGMz8FA1VwF+joxPkDRdC9nt4XA6STToKarqAm7Jj6hbz5vIi0Uy53LwHrklZ+9HzHlmfjZMdORw1Q4pewTEF1074d8Gs0o4YdddaQ+nU+uj7pmsv1FxqwMqs= Received: by 10.38.74.34 with SMTP id w34mr719937rna; Mon, 06 Dec 2004 16:10:41 -0800 (PST) Received: by 10.38.74.31 with HTTP; Mon, 6 Dec 2004 16:10:41 -0800 (PST) Message-ID: <2fe5ef5b04120616106c34aaf3@mail.gmail.com> Date: Mon, 6 Dec 2004 17:10:41 -0700 From: Brandon Goodin Reply-To: Brandon Goodin To: Nilesh Bhattad Subject: Re: Common practice to maintain sql maps and properties file Cc: ibatis-user-java@incubator.apache.org In-Reply-To: <003a01c4dba3$001cb4d0$76a7a8c0@nils> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <003a01c4dba3$001cb4d0$76a7a8c0@nils> X-Virus-Checked: Checked If you are using cvs you can place an ignore on sqlmapconfig.properties to avoid it from being checked in and hence distributred into any other environment when perfroming a build (via ant). What we do is to keep a sample-sqlmapconfig.properties around. Then whether you are in a development, test or production environment you can rename and configure it to work in that environment. If you are looking to keep around some preconfigured sql map configs for different environments you can place them in a folder outside the src directory and use ant to copy it in on a build depending on an environment flag that is set manually. Brandon On Mon, 6 Dec 2004 09:50:59 -0500, Nilesh Bhattad wrote: > > Folks, > This is how I keep all the mapping files, SqlMapConfig.xml(each per > application) and 1 common SqlMapConfig.properties which has the database > connection parameters for all the applications. > > src > | > | > |___ XML.app1.ibatis.maps > | | > | |___ all mapping files, SqlMapConfig.xml > | > | > |___ XML.app2.ibatis.maps > | | > | |___ all mapping files, SqlMapConfig.xml > | > | > |___ SqlMapConfig.properties > > > With this approach, all these files become part of the WAR. And I think this > is not a workable solution if I have to deploy the project onto QA and > further environments. > > Just wondering, how do you guys maintain these config files? Do you keep it > in current working directory so that they are not part of WAR and each > environment can configure database connection parameters seperately? Also, > if I keep SqlMapConfig.properties inside current working directory, how do I > access it inside SqlMapConfig.xml? > > Help please! > > Regards > Nilesh >