Hi Adam, <advertisement> EasyConf[1] offers several ways to support distinct environments without involving the build environement. The (currently) preferred way is described in: http://easyconf.sourceforge.net/user/properties/multienvironments.html Feedback about it is welcome. </advertisement>
Hope this helps you. Cheers, Jorge [1] http://easyconf.sourceforge.net/ On 5/13/05, Adam Hardy <[EMAIL PROTECTED]> wrote: > This is fine for web projects, but how could one do something similar for > non-web, non-J2EE projects? > > I'm imagining a shell script that sets up a JNDI context before calling the > project's jar. > > > > -----Original Message----- > > From: Arnaud HERITIER [mailto:[EMAIL PROTECTED] > > Sent: 13 May 2005 01:07 > > To: 'Maven Users List'; 'Charles Daniels' > > Subject: RE: Maven Best Practices > > > > > > Hi, > > > > This is a little bit off topic but ... > > > > We often deploy my web applications on tomcat. > > What we do is to define some deployment parameters on our web > > applications (web.xml) : Some parameters > > <context-param> > > <param-name>environment</param-name> > > <param-value>Development environment</param-value> > > </context-param> <context-param> > > <param-name>scriptInterpreter</param-name> > > <param-value>/bin/sh</param-value> > > </context-param> > > ... > > A SGBD : > > <resource-ref> > > <description>Oracle Datasource</description> > > <res-ref-name>jdbc/mySQBD</res-ref-name> > > <res-type>javax.sql.DataSource</res-type> > > <res-auth>Container</res-auth> > > </resource-ref> > > > > We deliver the war to others team (tests, production, ...) > > and they define the own deployment settings in tomcat with a > > context file > > : > > <Context path="/ourWebApp" docBase="ourWebApp.war" debug="0"> > > <Parameter name="environment" value="Integration > > environment" override="false"/> > > <Resource name="jdbc/mySGBD" auth="Container" > > type="javax.sql.DataSource"/> > > <ResourceParams name="jdbc/mySGBD"> > > <parameter> > > <name>factory</name> > > <value>org.apache.commons.dbcp.BasicDataSourceFactory</value> > > </parameter> > > <parameter> > > <name>driverClassName</name> > > <value>oracle.jdbc.driver.OracleDriver</value> > > </parameter> > > <parameter> > > <name>url</name> > > <value>jdbc:oracle:thin:@localhost:1521:mySGBD</value> > > </parameter> > > <parameter> > > <name>username</name> > > <value>myUser</value> > > </parameter> > > <parameter> > > <name>password</name> > > <value>myPassword</value> > > </parameter> > > <parameter> > > <name>maxActive</name> > > <value>20</value> > > </parameter> > > <parameter> > > <name>maxIdle</name> > > <value>10</value> > > </parameter> > > <parameter> > > <name>maxWait</name> > > <value>-1</value> > > </parameter> > > <parameter> > > <name>removeAbandoned</name> > > <value>true</value> > > </parameter> > > <parameter> > > <name>removeAbandonedTimeout</name> > > <value>60</value> > > </parameter> > > <parameter> > > <name>logAbandoned</name> > > <value>true</value> > > </parameter> > > <parameter> > > <name>validationQuery</name> > > <value>SELECT 1 FROM DUAL</value> > > </parameter> > > </ResourceParams> > > </Context> > > > > We filter resources only to copy pom informations in our web > > application (the current release for example). > > > > Arnaud > > > > > > > -----Message d'origine----- > > > De : Charles Daniels [mailto:[EMAIL PROTECTED] > > > Envoy� : vendredi 13 mai 2005 01:10 > > > � : [email protected] > > > Objet : Maven Best Practices > > > > > > Hi All, > > > > > > The Maven documentation is looking great! I have read the > > > section on Best Practices > > > (http://maven.apache.org/using/bestpractices.html) and have a > > > question regarding generating deployments. One bullet point > > > states the following: > > > > > > "Avoid the need to filter resources. While this can be useful > > > in a development environment, it usually requires rebuilding > > > of an artifact between different phases of deployment. The > > > best alternative is to externalise the configuration - for > > > example in J2EE (where this is a common occurrence), make > > > sure all configurable information such as database connection > > > properties are in the deployment descriptor, provided through > > > JNDI outside of the webapp or other deployable item. > > > This means the particular artifact can be deployed > > > identically into different servers, with just the external > > > configuration differing." > > > > > > Can somebody elaborate on how to achieve this? I certainly > > > would love to be able to do this, as this is one of the pain > > > points I have on my projects. Currently we have separate > > > properties files containing settings for our separate > > > deployment environments. When we build our webapps for > > > deployment, we specify the target environment so that we > > > filter resources with the corresponding properties file. This > > > ensures that the configuration files deployed with the > > > application contain the settings appropriate for the target > > > environment. > > > > > > How can we use the best practice quoted above to avoid this? > > > What do others do to address this issue? > > > > > > Thanks, > > > Chuck > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > http://www.bbc.co.uk/ > > This e-mail (and any attachments) is confidential and may contain > personal views which are not the views of the BBC unless specifically > stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in > reliance on it and notify the sender immediately. Please note that the > BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
