AHHHH - yes, all your "configuration" should be OUTSIDE your war/ear/jar files!
Don't repackage per env!!!! Also, don't force someone to unfurl your artifact, alter config, then re-roll it.... On Wed, Dec 26, 2012 at 3:05 PM, Stephen Connolly < [email protected]> wrote: > When artifacts get installed into the remote repository or local repository > cache, you do not have information about what profiles were active when the > artifact was built. as a result, in multi-module builds, if you are working > in a sub-module, you can end up with mixed artifacts, etc. > > Plus when you do your release you need to ask what profiles were active > when the release was cut. > > It is a seductive idea... until you dig deep enough. The real way to work > is to have the configuration externalized so that you don't need to rebuild > to deploy to a different environment. > > -Stephen > > > On 26 December 2012 18:54, Niranjan Rao <[email protected]> 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< > 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: users-unsubscribe@maven.**apache.org< > [email protected]> > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >>> > > > > ------------------------------**------------------------------**--------- > > To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org< > [email protected]> > > For additional commands, e-mail: [email protected] > > > > >
