incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noa Resare <...@spotify.com>
Subject Re: What is the status of xapi (deps/XenServerJava)?
Date Sat, 19 Jan 2013 22:51:41 GMT
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 <david@gnsa.us> wrote:

> On Sat, Jan 19, 2013 at 5:32 PM, Noa Resare <noa@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message