On Sat, Jan 19, 2013 at 5:32 PM, Noa Resare <n...@spotify.com> wrote: > (My apologies if this has already been discussed) > > Looking around in the build infrastructure I found what seemed like a > strange dependency, namely xapi 5.6.100-1-SNAPSHOT. Since dependencies with > -SNAPSHOT semantics is something I would very much like to get rid of from > cloudstack I looked and the setup seems a bit surprising. > > My understanding of the setup is the following: > > When building cloudstack there is a dependency on an artifact with > artifactId xapi and groupId org.apache.cloudstack. It is not built as part > of the build, as are the other dependencies sharing that groupId but > instead it is pulled from the apache snapshots repository that gets pulled > into the repository resolution chain as a side effect of the parent > declaration in the top level pom.xml > > Looking around some for the source i eventually found deps/XenServerJava/ > which contains what seems to be the source code used to build said > artifact. There is no README or similar in that directory, and the pom.xml > file holds an ASF copyright but the *java code holds a Citrix copyright and > what seems to be a 2 clause BSD license. > > I think this setup breaks the principle of least surprise in a few ways, > and I would like to see it changed: > > - Let's not depend on -SNAPSHOT releases, since it effectively means that > reproducibility of builds is uncertain. > > - I think the code should either be merged with the cloudstack projects, > which I assume means at least a donation and license updates, or split out > into a separate project with some presence on the web and a maven groupId > distinct from the cloudstack project. > > (Splitting it out need not be an advanced operation. Just put the code > somewhere public, spend an hour writing a readme and follow the guide on > http://maven.apache.org/guides/mini/guide-central-repository-upload.html to > get a release in the maven repo) > > /noa > >
So it's complicated.... So there is a xenserverjava project that does release source code, and binaries. Unfortunately the version that we need carries several modifications, hence our 'fork' living under org.apache. This wasn't part of the grant of code that Citrix made to the ASF, and thus copyright is still held by Citrix, though it is entirely possible that we should move our fork to its own repo. At one point we were trying to get our patches upstreamed, but I have no clue how well thats gone. --David
