Hi
I implemented using the following:
In the parent pom:
<properties>
<envType>local</envType> <!-- Default Environment value -->
<envProps>../autotestProperties/</envProps>
</properties>
<build>
<resources>
<resource>
<directory>${envProps}/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
<filters>
<filter>${envProps}/env/${envType}.properties</filter>
</filters>
As far as maven goes, it works fine, but when I generate eclipse project, it
tries to add the resource entry, but all it gets is a incorrect build path
entry:
"Build path entry is missing:
home/emerson/workspace/trunk/autotests/autotestProperties/resources"
Is there anyway to stop eclipse from trying to create this entry?
The normal use of this will be for the developers and qa to create the
project structure using a maven eclipse:eclipse install -DskipTests build
once via maven
On 6 October 2010 11:31, emerson <[email protected]> wrote:
> Hi Wayne
>
> For app deployment we use anthill in such a way that we use the same build
> for all environments and the resources are processed during the deployment.
>
> that said, this is a special case, as this project and its modules are all
> jbehave and selenium projects, which won't generate artifacts and will just
> run the tests.
>
> But I agree with you in that this is somewhat of a anti-pattern when used
> to deploy final artifacts.
>
> Regards
> Emerson
>
>
> On 5 October 2010 18:27, Wayne Fay <[email protected]> wrote:
>
>> > For property values -- I setup a .properties file for each of our
>> > environments with the default being 'dev'. So for a default build, the
>> dev
>> > properties are used. but when its time to build for QA or Production,
>> you
>> > add a cmd line argument accordingly: mvn install -DenvType=QA
>>
>> IMO this is an anti-pattern for Maven usage. You should be able to
>> build one single artifact in say Dev and then promote that same
>> untouched/changed artifact through your various environments.
>> Otherwise the artifact that gets QA'ed is not the same artifact that
>> lands in Production... which defeats the purpose of QA.
>>
>> You should generally deal with these variances in the environments via
>> JNDI or other mechanisms available in the platform (JavaSE/JEE or
>> whatever container you're deploying into).
>>
>> Wayne
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
