On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote:
-----Original Message-----
From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com]
On
On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric
<ehas...@transunion.com>wrote:

You're missing the point of what I'm asking.  I'm not suggesting that
maven make it possible or easy to *create* the violation.  I'm
suggesting that it should be able to *detect* the violation.

I'm baffled as to why the maven community is so against the idea of
having additional (optional) checks to detect problems.


Eric,

The point is releases don't change. To "detect" means wasting bandwidth
comparing your supposedly unchanging released local artifacts to
supposedly
unchanging released remote artifacts. If anything, writing a Maven
plug-in
for this would be more appropriate, but I don't see your suggestion as
part
of Maven core.
Is it really going to be that much wasted bandwidth to download a few
checksums?

Can a plugin hook into the existing support for detecting changes in
snapshots?
You do not have to.
SNAPSHOTS are checked in exactly the way you want releases to be checked because SNAPSHOTS are supposed to change and by default you get the latest deployed SNAPSHOT. To find out if you have the latest SNAPSHOT, Maven will check the repository and download the new version for you automatically.

That is why we are so comfortable with the current system.
Only the stuff that you indicate is unstable, is checked and the stable stuff (called Releases) can be used from your local cache without problem.

The clear distinction between a stable release and a SNAPSHOT is your team's commitment to each other not to break things after you have said that they are done. With SNAPSHOTS you can decide to stick with a certain version of a SNAPSHOT or take the latest depending on your informal contract with the developer. If I tell you that today I am deploying a SNAPSHOT that is tested to do this function and that function while I am continuing to work on a third function and fix a deficiency in the first function, at least you know what you have to deal with. Youi can decide that you want to get my fixes as soon as they are deployed or you want to stick with the buggy one since your code deals with the bug and you want to go on testing with a stable version of my SNAPSHOT. But it is your choice and you know what you are getting.

If I deploy a Release of my artifact, you are assured that I am promising you a production quality artifact ready to go in the final build. If you, God forbid, find a bug in my release 2.1.4, I must issue a patched version with a new version number 2.1.5 or 2.1.4.1 and let people know that if they want the fixed version, they have to change their dependencies or suffer the bug that you found.
I can not lie to you about what you are getting.

In a team, this is a big help.

Ron


eric

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




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

Reply via email to