maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Hellewell <>
Subject Re: Can't specify distributionManagement in settings.xml
Date Thu, 07 Oct 2010 17:15:15 GMT
On Thu, Oct 7, 2010 at 10:43 AM, Thiessen, Todd (Todd)
<> wrote:
>> But the main thing I'm thinking about is the fact that the package
>> hasn't changed.  So why should I have to rebuild the code?
> But it has changed. Very much so. A SNAPSHOT is not a release.

Why would the package change?  Were' using the assembly plugin to
create a zip of the binaries (dlls, libs, and headers).  Why should
that change if the code it's built from hasn't changed?

>> That not
>> only wastes time but more importantly it adds risks that the build may
>> not be identical to the snapshot build that has been tested due to
>> obscure environment setting that changed on the build machine (e.g.,
>> suppose you installed a newer Windows SDK and that somehow affected
>> the build).
> You give QA a release not a SNAPSHOT. That way there is no copying AT ALL. No risk. This
is the advice that many have been giving you. Not sure why you keep going on about copying
a snapshot. No one has EVER suggested that you copy anything.

Actually, this is the first time I think I have heard someone
specifically mention not giving SNAPSHOTs to QA.

> Do your release testing on a release build and all will be well.

Ok, I think you are on to something, but I still have a problem.  The
root of my problem is that our build machines will be creating a lot
of builds all the time, maybe even automatically every time a piece of
code is checked in.  Since there are so many builds, and only some of
them will go to QA, we don't really know beforehand if a given build
is a release candidate.  So that is why I was thinking I should make
them snapshots, but once one is approved by QA it needs to be promoted
to release.

I could make it so all the builds made by build machines are release
builds, and then never worry about copying, but that would:
1. Clutter up the release repo a ton, and cleaning up a lot of unused
release builds could be painful.
2. In the depenencies section we only want to depend on release builds
that are approved by QA.  Having all builds made by build machines go
to the release repo means we no longer have an easy way to see in the
pom.xml if it is depending on a build approved by QA.


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

View raw message