I didn't mean huge changes for the different platform. The usual changes
for the specific environments switched with profiles are usually those
property files you're talking about.
So the codebase remains the same, but assuming I build my ear using property
files for the validation platform, then the property files for the jar
dependencies in that ear would be automatically customized for the
validation platform as well. This means that some language properties
change, also the validation software needs to connect to another server,
also on the validation platform, so that url and its properties need to be
specific as well. And then also the property files for JUnit and for the
different databases. This way there is almost no human error possible, the
artifact is the same for all platforms, but with different config settings,
etc.
Or am I missing something?
stephenconnolly wrote:
>
> On 14 December 2010 08:06, fhomasp <[email protected]> wrote:
>>
>> After reading a bit of the debate I wonder a few things. I read "stay
>> away
>> from profiles" a lot but I do find them to be very useful.
>>
>> So what's the alternative on profiles? Assuming there is a modular
>> project
>> with several jars, several wars and several ears. Each of those
>> artifacts
>> can be built for a different environment (development, test (1,2,3),
>> staging, validation,...)
>
>
> Here is your issue.
>
> The Maven Way is to build one artifact that works in any environment.
> You don't go building environment specific artifacts on the Maven Way.
>
> You use things like JNDI or properties files added to the classpath to
> provide the environment customisations....
>
> In situations like branding, you produce a brand artifact for each of
> the customer specific brands and you would load that into your
> application, by e.g. loading from the classpath, or by installing into
> the deployed application.
>
> If you have an existing application that is not designed this way,
> then I can see that you might find it hard to avoid profiles.... but
> you will have a better application if it is designed for the kind of
> pluggable customizations I describe.
>
> The Maven Way is about best practices.... and one of the best
> practices there is is ensuring that you only build an artifact once
> and re-use that tested artifact... it reduces the scope of testing
> (i.e. you only have to test the JNDI names exist, or you only have to
> test that the branding is correctly applied, rather than have to
> retest the entire application because you have rebuilt it with the
> alternate profile.
>
> -Stephen
>
>>
>> Then an ear/war can be deployed using Maven to those different
>> environments,
>> be it from a local machine or Hudson or some other contineous integration
>> tool.
>>
>> How would one automate such situations without profiles and without a
>> huge
>> amount of redundant maven xml?
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Reasonable-use-of-profiles-tp3300650p3304188.html
>> 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://maven.40175.n5.nabble.com/Reasonable-use-of-profiles-tp3300650p3304241.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
