Oh, I see. Looking at this one more round I notice the deps/XenServerJava module reference in the top level POM as well, which I missed the first time. The fact that maven pulls the build from the build server in my particular test invocation seems to be just a by-product of maven being maven.
In that case I have simpler wish list item: A brief README in deps/XenServerJava referencing it's upstream projects and explaining the rationale for keeping a patched version in the local tree. And a proper version name :) /n On Sat, Jan 19, 2013 at 11:41 PM, David Nalley <da...@gnsa.us> wrote: > 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.htmlto > > 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 > -- Engineering Experience, Infrastructure tribe, Spotify
