maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Haszlakiewicz, Eric" <>
Subject RE: Can't specify distributionManagement in settings.xml
Date Mon, 04 Oct 2010 19:51:41 GMT
>-----Original Message-----
>From: Thiessen, Todd (Todd) []
>I don't think it is arbitary. Where you deploy your artifacts TO, I
>should be fixed. I think that is the intent. It is a one off thing that
>applicable to the build at hand and isn't something you will want to
>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
>exactly where the artifact will go. Using it as a property or variable
>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
>that are produced by some other project that you need as
>you should have control over where they will be found and that may
>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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message