Handling SNAPSHOT versions [Jason, please read!]

[Rafal Krzewski <rk...@ngo.pl>]

jvanzyl@apache.org wrote:
> jvanzyl     2003/02/02 07:42:13
> 
>   Modified:    src/plugins-build/java plugin.jelly
>   Log:
>   o When the jar:deploy-snapshot goal is run there will be a file generated in
>     the repository of the form ${pom.artifactId}-snapshot-version. This
>     will contain the real snapshot version. So when we do releases we can
>     collect all the real snapshot versions for any SNAPSHOT version identifiers
>     in the POM.

I noticed your commit and I thouhgt I should tell you about an idea I
had on making SNAPSHOT-using builds repetable over time. I wrote about
that idea in a comment to some message last week but it was overlooked
by everybody. That's why I made the subject note to draw your attention.
Now on to the idea:

Assume that instead storing the actulual version of the SNAPSHOT
artifact in an {$pom.artifactId}-snapshot-version, you append the
actual version of the snapshot being deployed to the
...-snapshot-versions file. The dependency resolver would download the
file and choose the newest available snapshot considering the current
time. Of course it should check all configured repositories to check
which one has the newest version. If the local repository already
contains the snapshot that is listed as newest in the remote repository,
the artifact doesn't get downloaded. This saves bandwidth because a
version file containg hudreds of entries would be still smaller
than a typical jar file. Notice that this renders the -SNAPSHOT.${type}
links unnecessary. The dependecy resolver would know the actual name
of the file that should be dowloaded.
This approach has another advantage (to bandwidth savings, and
uncluttering repository dirs): The dependency resolver could be
configured to look for snapshots that are not newest, but *were* newest
at the specified point of time. This would be great for hunting for
regressions. A command line argument similar to CVS' -D could be used
for this purpose.
An implementation note: we should take care that -versions files stay
valid at all points of time because peple can be downloading from the
repository at the time it's being updated. I'd copy the -versions file
to -versions.tmp, append to -versions.tmp and then mv it onto the
original name, which is an atomic opertaion on all sane OS'es. This
should keep us out of trouble.

R.

Re: Handling SNAPSHOT versions [Jason, please read!]

[Jason van Zyl <ja...@zenplex.com>]

On Mon, 2003-02-03 at 04:50, Rafal Krzewski wrote:
> jvanzyl@apache.org wrote:
> > jvanzyl     2003/02/02 07:42:13
> > 
> >   Modified:    src/plugins-build/java plugin.jelly
> >   Log:
> >   o When the jar:deploy-snapshot goal is run there will be a file generated in
> >     the repository of the form ${pom.artifactId}-snapshot-version. This
> >     will contain the real snapshot version. So when we do releases we can
> >     collect all the real snapshot versions for any SNAPSHOT version identifiers
> >     in the POM.
> 
> I noticed your commit and I thouhgt I should tell you about an idea I
> had on making SNAPSHOT-using builds repetable over time. I wrote about
> that idea in a comment to some message last week but it was overlooked
> by everybody. That's why I made the subject note to draw your attention.
> Now on to the idea:
> 
> Assume that instead storing the actulual version of the SNAPSHOT
> artifact in an {$pom.artifactId}-snapshot-version, you append the
> actual version of the snapshot being deployed to the
> ...-snapshot-versions file. The dependency resolver would download the
> file and choose the newest available snapshot considering the current
> time. Of course it should check all configured repositories to check
> which one has the newest version. If the local repository already
> contains the snapshot that is listed as newest in the remote repository,
> the artifact doesn't get downloaded. This saves bandwidth because a
> version file containg hudreds of entries would be still smaller
> than a typical jar file. Notice that this renders the -SNAPSHOT.${type}
> links unnecessary. The dependecy resolver would know the actual name
> of the file that should be dowloaded.
> This approach has another advantage (to bandwidth savings, and
> uncluttering repository dirs): The dependency resolver could be
> configured to look for snapshots that are not newest, but *were* newest
> at the specified point of time. This would be great for hunting for
> regressions. A command line argument similar to CVS' -D could be used
> for this purpose.
> An implementation note: we should take care that -versions files stay
> valid at all points of time because peple can be downloading from the
> repository at the time it's being updated. I'd copy the -versions file
> to -versions.tmp, append to -versions.tmp and then mv it onto the
> original name, which is an atomic opertaion on all sane OS'es. This
> should keep us out of trouble.

You want to take a stab at implementing this?

I'm working on the other part of tool to take the snapshot info and
update the POM for the release, build the distributions and then flip
the POM back. Maybe we could team up on this and get it done faster.

You idea for snapshots is certainly better than mine but I've got an
impending Tambora release so my time is limited. Not that yours isn't,
I'm just looking for a little help :-)

> R.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-maven-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-maven-dev-help@jakarta.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society