> Don't repackage per env!!!! Could you expand on that concept a little bit for me.
My question is whether you should run a "mvn deploy -P Test" to get your artifact(s) up to your Test environment, because that will re-package right? Or do you use some other way to take existing artifact(s) from your repo and push them out to the test server (or any server)? Based on your comment, I am assuming the latter but not sure how one could go about doing that...I guess I just assumed that the proper thing to do was use deploy for this, as I didn't see another option. Should I always deploy to my repo and then perform some separate task which takes artifacts from my repo and pushes them over to one of my app servers? If so, how the heck do I do that within Maven or, upon reflection, outside of Maven? Based on what I have read: "Maven's responsibility for building your artifact ends when it has delivered an environment independent artifact into the Maven Repository." ...and... "deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects." It sounds like if you use Cargo (or similar) you would almost create a new Phase (or goal, or something) which would bypass all parent phases (so you don't repackage) and simply grab your artifact(s) from your repo and push them over. That seems a bit dramatic. I found this old article as an example of what I was considering: http://dpillay.wordpress.com/2009/04/12/maven-cargo-tomcat-auto-deployment/ However, here he is making it part of the "install" phase which I don't think strictly adheres to the Maven lifecycle (install - install the package into the local repository, for use as a dependency in other projects locally) nor to your admonition. It sounds to me like Maven washes it hands of you once you place an artifact in the repo and everyone using Cargo to perform artifact pushes to their dev/test/prod environments is breaking the spirit of Maven. Therefore, I would have to rely on tools other than Maven to do this. Well, now I think I talked myself into the "external tool" camp ... argh! Thanks scott -----Original Message----- From: Maven User [mailto:[email protected]] Sent: Thursday, December 27, 2012 7:47 AM To: Maven Users List Subject: Re: Maven profiles and resource filtering 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-w > ay.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] > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 7838 (20121227) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 7839 (20121227) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
