Raul:
 
For most scenarios where you need to abstract the settings for a datasource 
from the datasource itself, people have largely turned to two design patterns: 
Service Locator and Dependency Injection
 
If you use Service Locator, your application servers retain the definition of 
the datasource and you use a JNDI lookup to find it.
 
Dependency Injection (especially with something like Spring) can be helpful as 
developers can have one configuration file for their environment (maybe even a 
lightweight database like HSQLDB), but it is not the one you bundle or use in 
production.
 
We typically do both -- using DI to keep the implementation and the datasource 
definition separate, and the Spring configuration deployed to production uses a 
JndiObjectFactoryBean to get the datasource from the application server. 
 
While you could just use JNDI -- for maximum developer velocity, I prefer 
avoidance at all costs.
 
Maven is not, in my opinion, a tolerable solution for the problem of data 
source configuration management.
I think the pain you are experiencing highlights the truth in that.
 
Now, as far as distributionManagement goes --
We generally have a property in settings.xml that is placed in the 
distributionManagement tag of relevant POMs.
This, unfortunately, creates a dependency on your settings.xml for a successful 
build, but it's the only way to control what location to deploy to based on 
profile -- at least not without yet another plugin.
 
That is to say:
settings.xml
   <profiles>
       <profile>
         <id>qual</id>
         <properties>
            <my.deploy.path>scp://somewhere</my.deploy.path>
         </properties>
        </profile>
        <profile>
           <id>prod</id>
           <properties>
             <my.deploy.path>scp://somewhere.else</my.deploy.path>
           </properties>
    [....]
 
pom.xml
<distributionManagement>
    <repository>
         [...]
         <url>${my.deploy.path</url>
     </repository>
 
Hope that helps.
 
Barrett
 
::   
Barrett Nuzum
Consultant, Skill Development
Direct: 918.640.4414
Fax: 972.789.1340 

Valtech Technologies, Inc.
5080 Spectrum Drive
Suite 700 West
Addison, Texas 75001
www.valtech.com <http://www.valtech.com/>   
making IT business friendly


________________________________

From: capira [mailto:[EMAIL PROTECTED]
Sent: Tue 6/19/2007 10:10 AM
To: users@maven.apache.org
Subject: Re: profile and distributionmanagement




Thanks for the reply Arnaud.

Maybe my post has a lack of information...

We have several enviroments: developing, testing and production. Those
enviroments has its own resources, passwords, etc. People from developing
does (must) not know the settings of the application deployed (jdbc pool
password, app settings, etc). They just release the software.

Testing and production team have got a machine with continuum and a
settings.xml file with the property values that must be overriding by
filtering.

So now the problem is: is there any way to say to deploy files in differents
servers depending on the profile? The distributionManagement tag is not
available for settings.xml

Any suggestions?

Regards,

Raul


Arnaud Bailly-3 wrote:
>
> capira <[EMAIL PROTECTED]> writes:
>
>> Hi!
>>
>> I just wonder if there is a way to distribute software depending on the
>> profile.
> Did you try adding a  distributionManagement section in each profile in a
> pom.xml ?
>
> regards,
> --
> OQube < software engineering \ génie logiciel >
> Arnaud Bailly, Dr.
> \web> http://www.oqube.com <http://www.oqube.com/> 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>

--
View this message in context: 
http://www.nabble.com/profile-and-distributionmanagement-tf3946050s177.html#a11196727
Sent from the Maven - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
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]

Reply via email to