Aside from Stephen's point which is, in itself, a reason not to use
profiles for this purpose, I would also suggest that there should be a
separation of church and state.
Programmers/developers should not be in charge of runtime environment
configurations and should produce artifacts that will run unchanged in
the environment configured by the system administrator or by an
automated installation tool.
There are well accepted solutions that make this possible. JNDI is one.
Installers are another.
Maven is development tool. Use it to develop code. Use something else to
configure run-time environments.
It should be possible to build your maven artifacts in way so that they
are tested on a programmers workstation, a CI environment, a test
environment and all the production environments without changing the
artifact.
This is a well established Best Practice.
Ignore it if you like but you have been made aware of a better way.
Ron
On 26/12/2012 1:54 PM, Niranjan Rao wrote:
I read the blog entry and still confused about why we should not be
using profiles. Perhaps I am just being dumb.
As for our particular case, maven and resource filtering actually has
been very helpful to us. We have multiple locations where development
happens, each location has its own setup of database/message queue and
other external resources application needs. With the help of resource
filtering, we are able to set right options in the configuration files
so that developers don't step on each other shoes. Each one gets his
own "namespace" as far external resources are concerned. Every
developer is required to execute the complete test suite in their own
environment before pushing their changes.
There are couple profiles we use during hudson builds - one meant for
CI, almost same as developer's profile, does run destructive unit
tests on DB - same tests developers are required to run. Other for
actually creating the build, which "skips" the unit tests and does a
build with proper properties so that build can work on QA servers and
not destroy the data QA team has built.
As far as I can see its just properties file and values get replaced
in maven way. Except for QA build, same unit tests get executed, only
difference being names/locations of external resources changed based
on profile. Only "hack" I can think of is bit of dependency injection
that sets db name slightly differently during unit tests. The reason
behind this is developers not loosing the "working" data when the
destructive units tests run. But again, its transparent to application
and application just works with the interface, concrete implementation
changes based on whether its running as part of main app or as unit test.
Am I missing something?
Regards,
Niranjan
On 12/21/2012 12:32 PM, Stephen Connolly wrote:
http://developer-blog.cloudbees.com/2012/11/maven-profiles-and-maven-way.html
Please don't do maven the way you are doing it
On Friday, 21 December 2012, Niranjan Rao wrote:
Greetings,
We have bunch of profiles and corresponding resource filtering which
all
works great. One frequent problem that we encounter team members often
forget to add new values in profile/filter property file of other
profiles
than the one they are currently using. Naturally results are
disastrous.
Normally we can find quickly which property is not filtered
correctly and
fix it but this is tedious.
I am wondering if there is any way to catch missing properties at build
time. That is when maven sees a property definition during filtering
phase
which has variable declaration and could not locate the value, can
it raise
the error and let the build fail?
Thanks,
Niranjan
------------------------------**------------------------------**---------
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]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
