This is exactly what I'm talking about, and its not an uncommon pattern of use and not (IMO) an anti-pattern or something to be explicitly avoided, so long as how you then USE those config jars is thought through. I think it makes some sense in some scenarios but then I also have to question the practice of deploying Production config files (with Production passwords in them!?!) to a Maven repo even if it is only internally-accessible since you may inadvertently over-share those passwords.
This can be part of the "separate your code and config" practice that we all generally agree with. Plus your config is backed up and versioned along with the app in your repo. Wayne On Mon, Jul 25, 2011 at 4:10 PM, Anders Hammar <[email protected]> wrote: > What I *think* Wayne is talking about is deploying the environment > configurations wrapped in jars and deploy them to the repo (you would deploy > a separate jar for each environment). And then during the actual copy to the > runtime environment pick the appropriate one (from the repo). > It does work if you know what you're doing, but I think that configuration > is handled best outside of the code. > > /Anders > > On Mon, Jul 25, 2011 at 22:37, Ron Wheeler > <[email protected]>wrote: > >> On 25/07/2011 4:27 PM, Wayne Fay wrote: >> >>> Do you think using a classifier to differentiate artifacts built for >>>> development and production is "hacky", is is this an appropriate >>>> solution? >>>> >>> IMHO this is OK and not hacky so long as there are ONLY >>> configuration/settings files in the jars and not actual binaries that >>> have configuration wrapped up inside them. I'm not a huge fan of this >>> approach but accept that it has its place. >>> >> Hard to figure where this is a good idea. >> >>> But then I have to ask how you're planning on using these artifacts in >>> your repo. Are you going to modify a pom dependency from "dev" to >>> "prod" in a product when you want to push it to Prod? >>> >> Breaks the "rules" about immutability of artifacts between testing and >> production deployment. >> >>> Wayne >>> >>> >>> ------------------------------**------------------------------**--------- >>> 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
