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] > >
