Take a look at the ship maven plugin for one way of doing this On Thursday, 27 December 2012, Scott Klein wrote:
> > 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, > > >>> > > >>> > ----- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org > < > > [email protected] <javascript:;>> > > > For additional commands, e-mail: [email protected]<javascript:;> > > > > > > > > > > > __________ 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] <javascript:;> > For additional commands, e-mail: [email protected]<javascript:;> > >
