incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: [DISCUSS] Binaries (jars) in our source tree/source releases.
Date Fri, 27 Jul 2012 16:51:28 GMT
On Fri, Jul 20, 2012 at 3:13 PM, David Nalley <david@gnsa.us> 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)
>
> Thoughts? comments? flames?
>
> --David

As a followup to this, I am proposing that at least for the time being
[1] that we just make this an optional ant target, something along the
lines of:


<project name="CloudStack Deps Resolver" default="help" basedir=".">
  <description> This downloads binary copies of dependencies for
building CloudStack</description>
  <target name="resolveDependencies">
   <mkdir dir="deps" />
   <get src="http://search.maven.org/remotecontent?filepath=log4j/log4j/1.2.9/log4j-1.2.9.jar"
dest="deps/log4j-1.2.9.jar" usetimestamp="true" />
   <get src="http://www.libvirt.org/maven2/org/libvirt/libvirt/0.4.7/libvirt-0.4.7.jar"
dest="deps/libvirt-0.4.7.jar" usetimestamp="true" />
  </target>
</project>


If I don't get any pushback, I'll start working on this more next week.
[1] Yes, I know, temporary becomes permanent. But I think this is far
better than our current intolerable situation, and is still quick and
easy (compared to learning Ivy or switching to Maven) to implement.
Unless someone else wants to pick up the work to do that.

--David

Mime
View raw message