Maven Best Practices

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Maven Best Practices

cjdaniels4
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Maven Best Practices

Arnaud Héritier
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:[hidden email]]
> Envoyé : vendredi 13 mai 2005 01:10
> À : [hidden email]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Best Practices

cjdaniels4
Oops! I accidentally replied directly to Arnaud rather than the list.
For completeness, here is the additional dialog with Arnaud. If
anybody has further input, please don't hesitate to provide it.

Thanks again Arnaud! By the way, what is SGBD?

>
> Thanks Arnaud! That appears to be right on topic, as far as I
> am concerned!

Hope this help ;-)

>
> My additional question may be off topic though, which is, how
> can I achieve the same thing using WebLogic and WebSphere? I
> imagine that these app servers must support something similar
> to the Tomcat context files. Can anybody point me in the
> right direction?

I didn't use weblogic or websphere since several months...
I remember that in weblogic it was possible to define external
resources (SGBD, ..) in the management console.
I think that there are some other solutions
(http://edocs.beasys.com/wls/docs61/ConsoleHelp/webservices_ddehelp.html)
but I never
tried them

>
> [As an aside, since your Tomcat context files are specific to
> each environment, do you maintain them under source control?
> If so, where do you keep them within your project structure?]

Personally we store them in src/deployment/tomcat
But we didn't yet create a mechanism to deliver them automatically to our team
It's on our todo list ..


Arnaud

>
> On 5/12/05, Arnaud HERITIER <[hidden email]> wrote:
> > 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:[hidden email]] Envoyé
> : vendredi
> > > 13 mai 2005 01:10 À : [hidden email] 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Maven Best Practices

Arnaud Héritier
>
> Oops! I accidentally replied directly to Arnaud rather than the list.
> For completeness, here is the additional dialog with Arnaud.
> If anybody has further input, please don't hesitate to provide it.
>
> Thanks again Arnaud! By the way, what is SGBD?

Ooops, It's the french acronym (Système de gestion de base de données) used for DBMS (Database management system)

Arnaud

>
> >
> > Thanks Arnaud! That appears to be right on topic, as far as I am
> > concerned!
>
> Hope this help ;-)
>
> >
> > My additional question may be off topic though, which is, how can I
> > achieve the same thing using WebLogic and WebSphere? I imagine that
> > these app servers must support something similar to the
> Tomcat context
> > files. Can anybody point me in the right direction?
>
> I didn't use weblogic or websphere since several months...
> I remember that in weblogic it was possible to define
> external resources (SGBD, ..) in the management console.
> I think that there are some other solutions
> (http://edocs.beasys.com/wls/docs61/ConsoleHelp/webservices_dd
> ehelp.html)
> but I never
> tried them
>
> >
> > [As an aside, since your Tomcat context files are specific to each
> > environment, do you maintain them under source control?
> > If so, where do you keep them within your project structure?]
>
> Personally we store them in src/deployment/tomcat But we
> didn't yet create a mechanism to deliver them automatically
> to our team It's on our todo list ..
>
>
> Arnaud
>
> >
> > On 5/12/05, Arnaud HERITIER <[hidden email]> wrote:
> > > 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:[hidden email]] Envoyé
> > : vendredi
> > > > 13 mai 2005 01:10 À : [hidden email] 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: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Maven Best Practices

Felipe Leme
On Fri, 2005-05-13 at 04:40 +0200, Arnaud HERITIER wrote:
> > Thanks again Arnaud! By the way, what is SGBD?
>
> Ooops, It's the french acronym (Syst?me de gestion de base de donn?es) used for DBMS (Database management system)

Interesting, in Portuguese it's the same (Sistema Gerenciador de Banco
de Dados)...


--
Felipe Leme <[hidden email]>
Falcon Inform?tica


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Maven Best Practices

Adam Hardy-2
In reply to this post by cjdaniels4
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:[hidden email]]
> 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:[hidden email]]
> > Envoyé : vendredi 13 mai 2005 01:10
> > À : [hidden email]
> > 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Maven Best Practices

jferrer
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 <[hidden email]> 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:[hidden email]]
> > 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:[hidden email]]
> > > Envoyé : vendredi 13 mai 2005 01:10
> > > À : [hidden email]
> > > 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> > >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]