Hi Brian
It just seems like the rev ID is really useful here for identifying
> reproducible builds without creating releases every time, does it fit with
> your ideas? If so, a hypothetical repository manager plugin could be
> maintaining information about snapshot dependencies based on SCM rev
Hi Curtis
I'm the first to admit I'm no Maven expert.
So please let me just confirm. Let's assume I am working on project A which
depends on projects B and C. For the sake of argument, let's say that the
source code for A, B and C have separate roots in SVN, and are usually
checked out independe
Very interesting discussion. With all due respect to Mr. Humble, and I
am a big fan of CD, I am going to venture to say that you don't
understand Maven very well. As a thought experiment, you are correct in
saying that a build based on snapshots is not reproducible. As a more
practical matter howev
On Nov 7, 2010, at 1:29 PM, jhumble wrote:
> One possibility to get repeatable builds without filling up an artifacts
> repository too fast could be to make Maven store the fully qualified pom
> files in the artifacts repo and an md5 of the binary but not necessarily the
> actual binary. I know a
On 7 November 2010 10:02, Brian Topping wrote:
> Does your book discuss ways to get around these issues?
No, it's a patterns / practices book so we don't go into a lot of detail on
the tools because that information tends to go out of date fast. We discuss
Maven a bit at the end of Chapter 13
> I really need to have maven copy a set of "external" scoped dependencies,
> and I´d hate to have to make a "company branch" of a maven plugin
Perhaps the Flexmojos project would be willing to take ownership of
the altered Maven plugin... since they are "causing" the problem in
the first place.
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 re
Hello fellows,
perhaps it is interesting for you that the book "Agile ALM" [1],
illustrates strategies and tools (especially Maven). I'm also covering
aspects that are discussed here in this thread.
[1] http://huettermann.net/alm
Cheers
Michael
--
-Java Champion-
mich...@huettermann.net
http:/
Hey Todd
The whole point of continuous delivery is that every check-in creates a
potential release candidate.
When you're doing continuous deployment, you could be releasing multiple
times a day, so you don't bother cutting branches or tagging or any of that
stuff because of the overhead. I'd ra
http://mojo.codehaus.org/versions-maven-plugin/update-properties-mojo.html#properties
On 6 Nov 2010 23:22, "Hilco Wijbenga" wrote:
On 6 November 2010 15:25, Stephen Connolly
wrote:
> You can define a range of updates to consider... On secon...
As in version ranges? Something like [1.0b3, 10]?
10 matches
Mail list logo
