[RT] SNAPSHOT semantics
niclas at hedhman.org
Sat Dec 11 05:27:49 EST 2004
I have been thinking about the SNAPSHOT semantics over and over many times in
th elast few months (since April I think), and every time I come to the
conclusion it is really screwed up...
I think the Maven folks thought like this;
1. I need to be able to publish a "snapshot" of my artifact now, that other
people can use.
2. I need to make it effortless to depend on such snapshots.
and then things started to get blur...
The intentions seems to have been;
maven upload:snapshot (or whatever the goal name is)
would build what you have with a timestamp Jar filename, upload that to the
central repository, create a symlink named xxx-SNAPSHOT.jar pointing to the
timestamped item xxx.
And then the dependent project would just declare SNAPSHOT in the version, and
automatically get the latest build.
BUT, this is not how it seems to be used. There are plenty of non symlinked
artifacts with SNAPSHOT in their names, and often you see both the version
and SNAPSHOT in the version element in dependency declarations, as well as
SNAPSHOT in the currentVersion element of the artifact.
In short, it seems to me that the original intent got raped on the way.
Now, looking at it from Magic PoV, we have changed the rules somewhat, but I
still feel we are a long way from the goals. Yeah, What are the goals
** I don't want to update the version while I am working on the codebase.
** I do want the version when something is published.
Is that it?
>From Magic PoV that could probably be true, as it understands which other
projects are part of the build, and Maven doesn't. So for Maven, it is harder
to distinguish between a dependency of a sister project from an completely
Now, assume we do the following;
1. For <resource> dependencies, i.e. external dependencies, we do require a
proper version number. This also covers <module> dependencies.
2. For <project> dependencies, i.e. projects built together with the 'current'
project, we always use a "-DEV" marker and no version number at all.
This leads to a number of behaviors we need to deal with;
a. When something is built, it will automatically get a -DEV marker in the
b. Magic needs to know if a "publish build" is in-progress, and if so, have a
slightly different build sequence (for instance, clean, version handling,
upload and other stuff involved).
a. above is not that hard, and barely worth mentioning. But b. is a more
profound concept. I think we have a need to be able to define the way
something is produced, or perhaps WHAT is produced in the project. And
targets alone is probably not enough.
And that brings the subject to "Production Processes"... which I will deal
with in a separate RT.
So, as for SNAPSHOT semantics are concerned, I would like to propose that we
cut it out of our conscience and look at what we really need and do that. I
can't see any reason to try to do the Maven snapshot semantics when that is
not what we need. So let's look closer at the need and fix this prior to a
release. It will affect both Magic and Transit, as Transit for some reason
also have some sort of Snapshot understanding, although it is not what the
P.S. Brett Porter is a Maven developer, and I would love to hear his side of
the Maven SNAPSHOT semantics, how they are supposed to work, how they are
used, and what they are doing about it for the future.
/ http://www.dpml.net /
/ http://niclas.hedhman.org /
More information about the dev-dpml