On 07/20/2012 03:13 PM, David Nalley wrote:
In one of the OSCON discussions, I noted the recent polite discussion re binary jars in source releases on general@incubator. While this is apparently tolerated (if you don't mind wearing Nomex), it's considered a Bad Thing (TM) generally speaking. Folks suggested that we look at how subversion handles this. In short, Subversion has a script that downloads all of their dependencies in binary form - and they also provide a download for the deps as a tarball.This made me think that perhaps we should add a .gitignore entry for .jars in deps/ (and tools/), and write a script that downloads the specific versions of the dependencies that we need and depending on argument, either places them in the deps/ directory or creates a tarball. (hopefully verifying {md5|sha1}sum for each binary along the way)
Getting rid of the .jars in the source tree is great and I am a very strong proponent of this, as stated in another thread a while back.
I question the need to download anything automatically, and thus the proposed script.
From a developer point of view I would say one would want to know what is getting used. Automatic downloading hides things and thus opens the door for "oh I didn't know" or "oops I didn't realize...". I think dependency in tools are things the developer is responsible for and a developer better know what is needed on the build system.
Packagers should create a cloudstack-devel package that depends on all the things needed to set up a development system and all these dependencies should be spelled out explicitly in the documentation such that a developer that uses a distro that does not package cloud stack can easily get the dependencies and install them.
The automatic download has the additional disadvantage that there is potential over lap between a package manager and the script. For example if I know I need x.jar to develop cloudstack and x.jar is available from my distros repo then I will install it and get hacking. Now if we have a script that automagically does me favors I get another copy of X.jar on my system. This of course may be different then the one from the distribution and there might be interference at some point in some unexpected way.
In summary: - Lets get rid of the jars - spell out everything needed in the doc - make sure that all these dependencies can be built by distros My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU SUSE-IBM Software Integration Center LINUX Tech Lead rjsch...@suse.com rschw...@ca.ibm.com 781-464-8147
