maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From emerson <>
Subject Re: how to centralize configuration accross multiple modules
Date Thu, 07 Oct 2010 18:56:55 GMT

I implemented using the following:

In the parent pom:

      <envType>local</envType> <!-- Default Environment value -->

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

"Build path entry is missing:

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 <> 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 <> 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:
>> For additional commands, e-mail:

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