[RT] SNAPSHOT semantics
dleangen at canada.com
Sat Dec 11 05:37:30 EST 2004
If we are going to use the idea of a separate svn repository for
"laboratory", "production" etc., then like you say, the SNAPSHOT idea
becomes irrelevant. Perhaps even the "DEV" concept becomes irrelevant, since
"DEV" happens in the laboratory, not in the production release.
Anything remotely related to a SNAPSHOT release should only happen in the
laboratory and the users should be sheilded from having to worry about this.
BTW - what does "RT" stand for?
> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org
> [mailto:dev-dpml-bounces at lists.ibiblio.org]On Behalf Of Niclas Hedhman
> Sent: 11 December 2004 19:28
> To: dev-dpml at lists.ibiblio.org
> Cc: Brett Porter
> Subject: [RT] SNAPSHOT semantics
> 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
> 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
> external project.
> 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
> name suggests.
> 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 /
> dev-dpml mailing list
> dev-dpml at lists.ibiblio.org
More information about the dev-dpml