Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> [VOTE] Apache Kafka Release 0.8.0 - Candidate 2


Copy link to this message
-
Re: [VOTE] Apache Kafka Release 0.8.0 - Candidate 5
Joe, another thing I noticed in the staging repo:

The POM for 2.8.2, 2.9.1, 2.9.2, and 2.10 include scala-compiler and
some other stuff that is not included in 2.8.0

2.8.0
https://repository.apache.org/content/groups/staging/org/apache/kafka/kafka_2.8.0/0.8.0/kafka_2.8.0-0.8.0.pom
2.8.2
https://repository.apache.org/content/groups/staging/org/apache/kafka/kafka_2.8.2/0.8.0/kafka_2.8.2-0.8.0.pom

Here's a diff of those two:
https://gist.github.com/mumrah/7bd6bd8e2805210d5d9d/revisions

I think maybe the 2.8.0 POM is missing some stuff it needs (zkclient,
snappy, yammer metrics). And there is a duplicate ZK entry for the POMs
 >2.8.0

-David

On 12/2/13 12:57 PM, Joe Stein wrote:
> Neha, as far as the release process is this what you had in mind
> https://cwiki.apache.org/confluence/display/KAFKA/Release+Process or
> different content or more of something or such?
>
> Per the POM, I was able to use the artifacts from the maven repository
> without having to-do anything more than just specifying the artifacts with
> sbt.
>
> resolvers += "Apache Staging" at "
> https://repository.apache.org/content/groups/staging/"
>
> libraryDependencies ++= Seq(
>          ...,
> "org.apache.kafka" % "kafka_2.10" % "0.8.0",
>          ....
> )
>
> and on the pure maven side
> <repositories>
>          <repository>
>              <id>ApacheStaging</id>
>              <url>https://repository.apache.org/content/groups/staging/</url>
>          </repository>
> ...
>          <dependency>
>              <groupId>org.apache.kafka</groupId>
>              <artifactId>kafka_2.9.2</artifactId>
>              <version>0.8.0</version>
>              <exclusions>
>                  <exclusion>
>                      <groupId>log4j</groupId>
>                      <artifactId>log4j</artifactId>
>                  </exclusion>
>              </exclusions>
>          </dependency>
>
> which very closely mirrors what David was talking about with ivy as well...
> I didn't really think much of it just a matter of XML we can document
> (there is actually no using maven documentation on the site at all we
> should correct that in any case TBD post release) but if folks find it to
> be a pain then we should definitely fix it for sure.  off the top of my
> head I don't see how to-do that in the Build.scala but I really don't
> expect it to be too difficult to figure out... the question is do we hold
> it off for 0.8.1 since technically nothing is breaking (like the null
> pointer exceptions we had for the bonked pom in beta1 that I shipped to
> maven central).
>
> Before canceling the vote can we at least get consensus to what we are
> canceling and exactly what fixes should be in RC6 or ... agree to ship RC5
> and hold whatever is left for 0.8.1
>
> I am totally fine with working on RC6 (actually just cancelled my plans for
> the evening because of a whole slew of client work that hit my plate) but I
> want to make sure we have everything covered that everyone that is voting
> expects to be in there.
>
> David, a few items below don't make sense I sent another email on the
> thread in regards to the LICENSE
>
>
> /*******************************************
>   Joe Stein
>   Founder, Principal Consultant
>   Big Data Open Source Security LLC
>   http://www.stealth.ly
>   Twitter: @allthingshadoop <http://www.twitter.com/allthingshadoop>
> ********************************************/
>
>
> On Mon, Dec 2, 2013 at 12:19 PM, Neha Narkhede <[EMAIL PROTECTED]>wrote:
>
>> I think we should maintain a wiki describing the release process in detail,
>> so we save the turnaround time on a release. We can have a VOTE thread to
>> agree on the release guidelines and follow it. Having  said that, it is
>> worth having the correct .pom file at the very least, since the release is
>> not very useful if people cannot consume it without pain.
>>
>> Thanks,
>> Neha
>>
>>
>> On Mon, Dec 2, 2013 at 8:59 AM, Joe Stein <[EMAIL PROTECTED]> wrote:
>>
>>> General future thought comment first: lets be careful please to raising