Hi Marvin,
These are not actually files compiled from our source code, but third-party
dependencies that are not published to Maven. SBT is a Scala-based build tool
where you need that JAR to run. Where exactly is the policy on including these
kinds of JARs?
The reason we went with them is
Hi Marvin,
These are not actually files compiled from our source code, but third-party
dependencies that are not published to Maven. SBT is a Scala-based build tool
where you need that JAR to run. Where exactly is the policy on including these
kinds of JARs?
The reason we went with them is
Hi Patrick,
In fact, Sonatype will let you publish non o.a.xx dependencies since
they are an approved forge as well for Central sync. So you can sign
up for an account there, but it's always good to get the buy in of the
specific community of the upstream dependency so they are aware.
These
Hey Chris,
Okay we'll focus on that distribution path for the 0.9.0 release. Thanks!
On Sun, Dec 15, 2013 at 9:47 AM, Chris Mattmann mattm...@apache.org wrote:
Hi Patrick,
In fact, Sonatype will let you publish non o.a.xx dependencies since
they are an approved forge as well for Central
+1
On 12/13/13 3:59 PM, Marvin Humphrey wrote:
Greetings,
As the next step in our ongoing efforts to reform the release voting process,
I propose that we run an experiment allowing the PPMC members of select
podlings to earn binding votes under limited circumstances by completing a
release
jclouds uses Pull Requests to a GitHub mirror of the (primary) ASF
repos as a means of collaborating on submissions with contributors
[1]. We then apply the resulting patches to the ASF repos directly [2,
3].
If you'd like more information on how this works, please hop on to
#jclouds on
You might also want to have a look at how Scala itself deals with the
issue of required binaries for the build:
https://github.com/scala/scala/blob/master/pull-binary-libs.sh
https://github.com/scala/scala/blob/master/tools/binary-repo-lib.sh
I'm not necessarily a huge fan of this (builds on
