>-----Original Message----- >From: Thiessen, Todd (Todd) [mailto:tthies...@avaya.com] > >I don't think it is arbitary. Where you deploy your artifacts TO, I think >should be fixed. I think that is the intent. It is a one off thing that is >applicable to the build at hand and isn't something you will want to try >and reproduce at a later date (like building from a tag). > >In this case it is good to know that if you run a mvn deploy, you'll know >exactly where the artifact will go. Using it as a property or variable in >this case I think isn't a good thing. > >Think of this way. You want to have complete control over the artifacts >that your build produces. Something fixed... predicatable. The artifacts >that are produced by some other project that you need as depedendencies; >you should have control over where they will be found and that may change >over time. These are thus not fixed.
Sure, it makes sense to have complete control for what actually gets created as the artifact. Where you deploy it to can depend on where you happen to be building. For instance, where I work we recently starting using a new set of servers for our development environment. The url that our nexus server is at is different for one environment than the other. (in one environment it's actually a transparent proxy that forwards connections over a tunnel that was only available for use by that one server) To get things to work, we had to change every single project that we have to use a new parent pom. And once we changed a project, we could no longer build in the old environment. We still ended up with the exact same artifacts as before, but we were just deploying them to a different server. We had no need to perform a new release of any of our projects for any other reason, but we still needed to change everything. That sucks. Anyway, it sounds like Phillip's solution with the property references would eliminate these issues. eric --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
