Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: Continuous Delivery and Maven
From: Brian Topping <topping@codehaus.org>
In-Reply-To: <1289146475449-3254090.post@n5.nabble.com>
Date: Sun, 7 Nov 2010 13:02:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <88C85CEC-94E0-4809-8DF4-878AABC17435@codehaus.org>
References: <1288631667010-3245370.post@n5.nabble.com>
 <6369CB70BFD88942B9705AC1E639A3382201B0FC02@DC-US1MBEX4.global.avaya.com>
 <1289146475449-3254090.post@n5.nabble.com>
To: "Maven Users List" <users@maven.apache.org>


On Nov 7, 2010, at 11:14 AM, jhumble wrote:

> Ideally what I'd like is for Maven to explicitly support the =
continuous
> delivery model and provide snapshots that are reproducible.

Snapshots can be reproducible if developers set dependencies on the =
timestamped name of the deployed version.  I remember there being =
reasons that these strategies are discouraged (should be in the list =
archives), but those reasons may not apply here.

If I understand the paradigm, it's not that developers would want to =
reject the latest version of any dependencies, just that the snapshot =
builds should be reproducible.  Since the POM is the source of =
dependency resolution for any Maven build, it seems like the release =
plugin in use would have to update the project POMs to the currently =
resolved name of the actual dependency and check them in before the tag. =
=20

But if the release checks in a POM and this is happening over and over =
for every checkin (a one line change in a heavily connected project =
could easily cause several POMs to be updated), suddenly dependent =
versions need to have their POMs changed, checked in, and new version =
propagated iteratively.  On developer desktops, all these new POMs would =
need to be kept up to date constantly to avoid text conflicts.  Maybe a =
VFS SCM could get around this, but.... ick!  The tooling is suddenly =
very heavyweight.

Does your book discuss ways to get around these issues?=

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org