SVN and Jars

["Markus M. May" <mm...@gmx.net>]

Hello Alan,

I just read your blog about SVN and Jars. (can be found at:
http://engrm.com/blogometer/2004/03/17/svn-and-jars.html#comments)

Maybe the following comments tends to Depot Update (formerly Ruper), but 
I believe that they are true for Maven as well.

--- snip ---
> After too long I gave up on Maven.
--- snap ---

Okay, I understood this one, but this is a personal choice and there are
other choices as well, as you are stating below. But Maven is not my
topic here.

--- snip ---
> Since Maven never worked, I never grew to hate the repository concept. I
> didn't care for ibiblio. I tried to get a contemporary version of Saxon
> uploaded. Built it. Submitted an issue with links to the jars. It was
> months before I got a response, asking why the links were taken down. By
> then I'd long abandonded ibiblio and and Maven. There was a newer
> version of Saxon anyway.
> I understand that people are busy and they can't tend to my needs. I
> understand perfectly. Hence no Maven.
--- snap ---

Well obviously this is not an issue of the repository concept itself, it
is just an issue of the process involved in updating the repository.

--- snip ---
> Take Saxon 7.8. There was an inconistency in the namespace declaration
> attributes that I dedected, patched, and submitted to Michael Kay.
> Michael rolled that into 7.9, but I needed to keep my patched 7.8 to
> keep going. A version from the one true respostiory, be it ibiblio, or
> elsewhere, would not do. I needed my own personal patched Saxon 7.8.
--- snap ---

Okay, this is a real point. You are working against a SNAPSHOT version
here (a version build nightly by e.g. gump or any other Continuous
Integration tool), and not against a "released" version.
So where is the difference between these two? The release version is
thoroughly tested and all members of the team have decided to release
this version.
This can take its time, but think about an environment where you are
using third party jars from a commercial vendor. What about bugfixes there?
But most of the jars on the repository are updated through the maven
team or the mantainer of the project itself on the ibilio repository
kind of daily. This means, you do not have to use a version like 7.8,
you can always use SNAPSHOT, which is a development version. If you do
not like to use the development version, you always have to use the 
source code yourself anyway.

--- snip ---
> Still, I had yet to learn that the repostiory concept was loathsome. I
> wrote a system using Ant and XSLT.
> The fact that I must maintain client side code, a server respository,
> and a dependencies listing, did not dissuade me. The fact that the
> debugging Ant builds is a slow and painful process (when a ten minute
> build continues to hit bugs in the last thirty seconds, say) did not
> dissuade me. I plowed on, and built an ibiblio like repository, and a
> Maven like dependency downloader.
--- snap ---

Ever thought about your build process? You do not have to restart the
full build process everytime, you can just begin with the last step,
which failed the last time. This is a feature supported by ANT as well 
as Maven.

--- snip ---
> I was still wondering if I should continue with this repostiory of mine
> with the public Subversion repository when I read Nick Chalko's blog
> entry on Ruper.
> How exactly does Ruper conserve bandwidth? Does it have a means to
> transfer a jar from a server to a client using http and no bandwidth?
> How exactly does Ruper conserve disk space? Does it manage to store each
> necessary version of a jar on a server without using the hard drive?
> I suppose it saves bandwidth because each project does not keep its own
> copy of say Saxon 7.8, but I'd much rather make sure my project has the
> right version, than make sure that some authority server has the right
> version. That is, post an issue, wait a few months.
--- snap ---

Well, it conserves bandwith in the way, like you stated, that even if
you have multiple projects on your own hard drive, you still have one
local repository and if you are using one jar (e.g. log4j) in the same
version in all of your projects, it just has to be downloaded once. If
you are using different versions in different projects (e.g. Saxon 7.8
for project1 and Saxon 7.9 for project2 and Saxon-SNAPSHOT for project3)
you have these different versions in your own local repository. The 
difference is, that you have each jar file only once, and not in each 
project (which is a redundancy, and these are not really liked in the IT 
  business).

--- snip ---
> If you are going to maintian your own repository, you are going to end
> up building a directory structure, and file naming scheme that keeps
> track of versions of these dependencies, so that they will be available
> to the different versions of the source.
--- snap ---

Correct, this is the job of Depot Update. And I
believe that this is done by Maven automatically as well. Both are going 
to maintain your local repository. This is optional, you could also use 
only the remote repository.

--- snip ---
> Talk about duplication! Instead of worrying about a duplicate copy of
> log4j on your server, fear the duplication of process you've created by
> running Ruper along side CVS. Maintaining a verioned repostiory of jars
> along side a versioned repostiory of source.
> Stop wasting disk space and bandwidth? That's the kicker. In computing
> there is little that is cheaper than disk space, nothing more expensive
> than a programmers time.
> Maybe it is a CVS experience.
> Subversion is rock solid and supports binary deltas. It is clean and
> efficent. I'm using it to store the images for The Engine Room web site.
> Why should I balk at storing jars? I've not gone and built an file based
> HTTP respostiory to version my images, why are jars any different?
--- snap ---

It is common sense to not store generated artifacts (jars, zips, even
documentation, etc.) in the repository, since this can be recreated
every time you need them. So I still believe in the Repository Concept
of Depot Update / Maven and Avalon.

--- snip ---
> I'm ready to check my jars into Subversion now.
--- snap ---

Well, your decision.

R,

Markus M. May


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org