maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From emerson <echofloripa.y...@gmail.com>
Subject Re: how to centralize configuration accross multiple modules
Date Thu, 07 Oct 2010 18:56:55 GMT
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 <echofloripa.yell@gmail.com> 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 <waynefay@gmail.com> 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message