Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Janne.Jalkanen@ecyrd.com
 designates 193.64.5.122 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v753)
In-Reply-To: <478CE292.1020702@ops.co.at>
References: <478CD146.9040503@ops.co.at> <20080115162422.GA28435@ecyrd.com>
 <478CE292.1020702@ops.co.at>
Content-Type: multipart/alternative; boundary=Apple-Mail-1--210828368
Message-Id: <A9E052D7-8380-48A0-81E3-0577CC3BC962@ecyrd.com>
From: Janne Jalkanen <Janne.Jalkanen@ecyrd.com>
Subject: Re: import into svn - included jarfiles
Date: Sun, 27 Jan 2008 13:51:10 +0200
To: jspwiki-dev@incubator.apache.org

--Apple-Mail-1--210828368
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

> The thing from the Apache point of view is that there are about 100
> different java projects. And almost every single one of them uses
> commons-logging for example. So that would be 100 copies of
> commons-logging checked in to the subversion repository. When a new
> release is made, and each project checks in the new version, there  
> goes
> another 100 copies (since binary diffs are not very efficient). It  
> does
> add up.
>
> And when backups are made, all those bits need to be copied to the
> backup medium. It's not just disk space, but time too.

This is illogical: the web site instructions at http:// 
incubator.apache.org/guides/sites.html say that

"Regardless of which tool you use, the web site should be maintained  
in the svn repository, and include the site generation tool as a  
binary file."

Wouldn't those also end up having the same tools in the repo dozens  
and dozens of times over?

Frankly, I think this is a problem that should be solved at the  
backend level - why does SVN not e.g. calculate a hash for the binary  
files, figure out if it already has one, and then stores only just a  
link to it instead of the actual file?   An inefficient  
implementation should not burden the individual developers.

SVN FAQ suggests that the SVN binary-store algorithm is already quite  
efficient, though.

> And when somebody wants to download the source to browse it, they  
> don't
> need to wait for all the binary dependencies to download too. Probably
> less important, but still nice for non-broadband users.

I think this is a non-issue.   Nobody has in over six years ever  
mentioned that this would be a problem.

> <target name="getlibs">
>     <mkdir dir="lib"/>
>     <get dest="lib/junit-3.8.1.jar" src="${getlibs.base}/junit/jars/ 
> junit-3.8.1.jar"/>
>     <get dest="lib/logkit-1.0.1.jar" src="${getlibs.base}/logkit/ 
> jars/logkit-1.0.1.jar"/>
>     <get dest="lib/avalon-framework-4.1.3.jar" src="${getlibs.base}/ 
> avalon-framework/jars/avalon-framework-4.1.3.jar"/>
>     <get dest="lib/log4j-1.2.12.jar" src="${getlibs.base}/log4j/ 
> jars/log4j-1.2.12.jar"/>
>     <get dest="lib/servletapi-2.3.jar" src="${getlibs.base}/ 
> servletapi/jars/servletapi-2.3.jar"/>
> </target>

Unfortunately, this

a) requires you to run a separate build script after *every single  
checkout or update*.  This has the downside that some people might  
simply forget, and end up running with obsolete library versions.    
This might result in greater load to the developers, when bugs start  
appearing.
b) encourages wrong kind of JAR versioning (minor issue, could be  
subverted with clever use of scripts), which causes upgrade problems  
(you need special cleanup scripts to make sure duplicate JARs don't  
exist)
c) is inconvenient to IDE users, who will need to either drop to a  
shell, or define a separate Ant task just to be able to compile  
software.

I think the old progammer saying: "you code it once, but the user has  
to use it a thousand times" is valid here: we can either work a bit  
extra now, or we can have all the developers have to remember to  
update their libraries all the time."

It all depends on whether we think our customers in this case is the  
Apache infrastructure team, or the JSPWiki developer community.

> Are you talking here about being able to build pre-apache versions of
> jspwiki using the contents of the apache svn repository? I'm not sure
> that is necessary - or even a good idea. Having the full history of
> source files is good. But for reproducing old builds, the jspwiki cvs
> server will still exist, won't it?

It exists, subject to, well sunspots. It is still essentially  
essentially a "hobby" -computer, connected to the internet thanks to  
some very nice people I happen to know.  HW might fail, the  
connection might go away, etc.

This is BTW also the reason why I would like to move jspwiki.org to  
some better place, hosted by Apache, if possible.

/Janne
--Apple-Mail-1--210828368--