PortBinding: different services in the computer which needs to send and receive data are uniquely identified by PORT no.
I would like to see an example implementation of this Thanks James, > From: northrup.ja...@gmail.com > Date: Wed, 10 Sep 2014 11:49:30 -0700 > Subject: Re: Build once, deploy everywhere > To: users@maven.apache.org > > (http://) 12factor.net lean service deployment works well enough with > maven projects if the presence of source is not a detriment to a given sla. > I use > > git pull;mvn install;bin/run.sh > > when transitioning to production from development and I agree with 12factor > apps about ENV vars being a pretty good way to configure a service > > On Wed, Sep 10, 2014 at 11:25 AM, Martin Gainty <mgai...@hotmail.com> wrote: > > > > > > > > > > > > From: cody.a.fy...@wellsfargo.com > > > To: users@maven.apache.org > > > Subject: RE: Build once, deploy everywhere > > > Date: Wed, 10 Sep 2014 14:17:25 +0000 > > > > > > �Both of the below are good solutions. > > > > > > I've also seen folks use a run time based solution where a different set > > of properties is loaded based on an Environment Variable common to all > > servers. > > MG>one example could be %HOMEPATH%/.m2/repository/settings.xml IMHO > > MG>can your provide example of properties loaded thru a environment > > variable? > > > > > > Cody Fyler > > > Lending Grid Build Team > > > G=Lending Grid Builds > > > (515) – 441 - 0814 > > > > > > -----Original Message----- > > > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > > > Sent: Wednesday, September 10, 2014 9:15 AM > > > To: Maven Users List > > > Subject: Re: Build once, deploy everywhere > > > > > > What you want to do is have your packaged software be independent of the > > environment it is deployed to. That way you know by checking the SHA1 of > > the artifact you can know it was the one that was tested by QA. > > > > > > So what you do is have your application read its configuration from an > > external source. > > > > > > One example is you could read the configuration from the JNDI > > environment (if you are deploying in a JavaEE server). Thus you can setup > > the dev environment with the DB servers, etc defined in JNDI and the same > > for QA, PROD, etc > > > > > > Another example is you could look for a .properties file on the > > classpath or at a well known location (perhaps the user home or something > > like that) > > > > > > The application should fail fast if any of the configuration settings > > are missing to help diagnose issues. > > > > > > There are many ways to skin this cat, but rebuilding an artifact for > > each environment should be considered a critical anti-pattern > > > > > > On 10 September 2014 15:03, Jan <raghure...@gmail.com> wrote: > > > > > > > Hi All, > > > > > > > > Does anyone using Maven as Build Once and deploy Everywhere method? > > > > Like lets say i don't want to recompile my source code everytime for > > > > different environment DEV,SIT,UAT & PROD. I want to do my compile and > > > > package only at DEV then deploy the artifact to all mentioned > > > > environment. Is this possible using Maven, is there any reference any > > one could share with me Please. > > > > > > > > > �Т���������������������������������������������������������������������ХF� > > V�7V'67&�&R� R�� �â W6W'2�V�7V'67&�&T � fV�� 6�R��&pФf�" FF�F��� � 6��� > > �G2� R�� �â W6W'2ֆV� � fV�� 6�R��&p > > > > > > > -- > Jim Northrup * (408) 837-2270 *
