Hi Barret.
Thanks in deed!
That is what I was looking for, or at least, let me deploy the applicattion
correctly.
The problem we face is that testing and production have no idea (and should
not have) about jndi and other tips and tricks but they must know how to set
up the applications (context.xml, hibernate.cfg, struts.xml ...). We use
maven to set up all these things on the fly during deploying so they just
check that everething is fine and change the passwords when they want.
Regards,
Raul
Barrett.Nuzum wrote:
>
> 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: [email protected]
> 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]
>
>
>
--
View this message in context:
http://www.nabble.com/profile-and-distributionmanagement-tf3946050s177.html#a11198649
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
