Re: import into svn - included jarfiles

[Craig L Russell]

As far as I'm concerned, this is a non-issue.




Craig


On Jan 27, 2008, at 3:51 AM, Janne Jalkanen wrote:

The JSPWiki team can check binary dependencies that are appropriately licensed into the jspwiki svn repo if they want. Just make an informed group decision. There's no Apache policy that prohibits approved binary dependencies from being checked in.

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

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.

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

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"/>

</target>

<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"/>

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?

/Janne

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.

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature