You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by Neha Narkhede <ne...@gmail.com> on 2011/11/01 01:44:08 UTC
[VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Hi,
This is the fifth candidate for the first incubator release for Apache
Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
those.
It also fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
*** Please download, test and vote by Nov 3rd, 6 pm
Note that we are voting upon the source (revision), binaries are
provided for convenience.
Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
The SVN revision to be voted upon:
https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS
Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before any release can be made official.
Thanks,
Neha
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
On Nov 2, 2011, at 12:36 PM, Jay Kreps wrote:
> I think we should revamp all the docs. There are changes to the consumer as
> well, and some of the quickstart and config docs are just bad. The design
> doc also needs to be updated with the new changes.
>
> Presumably that can be done asynchronously from the release itself.
Yep.
I'm quite busy today but should be able to inspect the release candidate tonight.
Regards,
Alan
>
> -Jay
>
> On Wed, Nov 2, 2011 at 12:07 PM, Joel Koshy <jj...@gmail.com> wrote:
>
>> One more change to the quickstart - the consumer's message streams now
>> need to be parameterized, and we can add a note on consumer decoders.
>>
>> Thanks,
>>
>> Joel
>>
>> On Wed, Nov 2, 2011 at 10:56 AM, Jun Rao <ju...@gmail.com> wrote:
>>> +1 from me. Tested quick start and embedded_consumer test in system_test.
>>>
>>> One thing is that we should fix the quick start page
>>> on kafka-producer-shell.sh. The server port has now changed to 9093.
>>>
>>> Jun
>>>
>>> On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <neha.narkhede@gmail.com
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> This is the fifth candidate for the first incubator release for Apache
>>>> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
>>>> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
>>>> those.
>>>>
>>>> It also fixes the following issues:
>>>>
>>>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>>>>
>>>> *** Please download, test and vote by Nov 3rd, 6 pm
>>>>
>>>> Note that we are voting upon the source (revision), binaries are
>>>> provided for convenience.
>>>>
>>>> Source and binary files:
>>>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>>>>
>>>> The SVN revision to be voted upon:
>>>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>>>>
>>>> Kafka's KEYS file containing PGP keys we use to sign the release:
>>>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>>>
>>>> Note that the Incubator PMC needs to vote upon the release after a
>>>> successful PPMC vote before any release can be made official.
>>>>
>>>> Thanks,
>>>> Neha
>>>>
>>>
>>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Jay Kreps <ja...@gmail.com>.
I think we should revamp all the docs. There are changes to the consumer as
well, and some of the quickstart and config docs are just bad. The design
doc also needs to be updated with the new changes.
Presumably that can be done asynchronously from the release itself.
-Jay
On Wed, Nov 2, 2011 at 12:07 PM, Joel Koshy <jj...@gmail.com> wrote:
> One more change to the quickstart - the consumer's message streams now
> need to be parameterized, and we can add a note on consumer decoders.
>
> Thanks,
>
> Joel
>
> On Wed, Nov 2, 2011 at 10:56 AM, Jun Rao <ju...@gmail.com> wrote:
> > +1 from me. Tested quick start and embedded_consumer test in system_test.
> >
> > One thing is that we should fix the quick start page
> > on kafka-producer-shell.sh. The server port has now changed to 9093.
> >
> > Jun
> >
> > On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <neha.narkhede@gmail.com
> >wrote:
> >
> >> Hi,
> >>
> >> This is the fifth candidate for the first incubator release for Apache
> >> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
> >> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
> >> those.
> >>
> >> It also fixes the following issues:
> >>
> >>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
> >>
> >> *** Please download, test and vote by Nov 3rd, 6 pm
> >>
> >> Note that we are voting upon the source (revision), binaries are
> >> provided for convenience.
> >>
> >> Source and binary files:
> >>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
> >>
> >> The SVN revision to be voted upon:
> >> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
> >>
> >> Kafka's KEYS file containing PGP keys we use to sign the release:
> >> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
> >>
> >> Note that the Incubator PMC needs to vote upon the release after a
> >> successful PPMC vote before any release can be made official.
> >>
> >> Thanks,
> >> Neha
> >>
> >
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Joel Koshy <jj...@gmail.com>.
One more change to the quickstart - the consumer's message streams now
need to be parameterized, and we can add a note on consumer decoders.
Thanks,
Joel
On Wed, Nov 2, 2011 at 10:56 AM, Jun Rao <ju...@gmail.com> wrote:
> +1 from me. Tested quick start and embedded_consumer test in system_test.
>
> One thing is that we should fix the quick start page
> on kafka-producer-shell.sh. The server port has now changed to 9093.
>
> Jun
>
> On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <ne...@gmail.com>wrote:
>
>> Hi,
>>
>> This is the fifth candidate for the first incubator release for Apache
>> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
>> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
>> those.
>>
>> It also fixes the following issues:
>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Nov 3rd, 6 pm
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before any release can be made official.
>>
>> Thanks,
>> Neha
>>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Jun Rao <ju...@gmail.com>.
+1 from me. Tested quick start and embedded_consumer test in system_test.
One thing is that we should fix the quick start page
on kafka-producer-shell.sh. The server port has now changed to 9093.
Jun
On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <ne...@gmail.com>wrote:
> Hi,
>
> This is the fifth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
> those.
>
> It also fixes the following issues:
>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 3rd, 6 pm
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Pierre-Yves <py...@smallrivers.com>.
Publishing to maven will be very important for users of the client
library. Since there's no separate project for that I think it is
essential, though not related to the way the daemon is distributed.
As for the daemon, it indeed seems inadequate to impose fiddling with
SBT to consumers of the daemon since some will not be using it from
scala and will have issues getting it to work.
Excited about the upcoming release!
- pyr
On Sun, 6 Nov 2011 18:21:29 -0800
Neha Narkhede <ne...@gmail.com> wrote:
> Thanks everyone for responding. Is the general consensus to let the
> distribution be as is? We can always revisit publishing to Maven once
> that ticket is resolved for next release.
>
>
> Thanks,
> Neha
>
> On Sunday, November 6, 2011, Alan D. Cabrera <ad...@toolazydogs.com>
> wrote:
> > I am of the same mind as Chris. I'm not here to pass value
> > judgments on
> what projects wish to put in their releases. If I see something odd
> I will merely point it out and let the project decide on what to do.
> >
> > On Nov 5, 2011, at 10:32 PM, Chris Douglas wrote:
> >
> >> I went through the included jars and didn't see anything that
> >> couldn't be redistributed. I also found all the licenses (included
> >> with the jars) that were required. I think the current release can
> >> go out as-is. I prefer source distributions and publishing to
> >> maven, but (again) I don't know others' downstream expectations. -C
> >
> > Thanks for slogging through all those jars. If you're willing to
> > vouch
> for the jars' licenses then I think things are good for a release.
> >
> >
> > Regards,
> > Alan
> >
> >
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Neha Narkhede <ne...@gmail.com>.
Thanks everyone for responding. Is the general consensus to let the
distribution be as is? We can always revisit publishing to Maven once that
ticket is resolved for next release.
Thanks,
Neha
On Sunday, November 6, 2011, Alan D. Cabrera <ad...@toolazydogs.com> wrote:
> I am of the same mind as Chris. I'm not here to pass value judgments on
what projects wish to put in their releases. If I see something odd I will
merely point it out and let the project decide on what to do.
>
> On Nov 5, 2011, at 10:32 PM, Chris Douglas wrote:
>
>> I went through the included jars and didn't see anything that couldn't
>> be redistributed. I also found all the licenses (included with the
>> jars) that were required. I think the current release can go out
>> as-is. I prefer source distributions and publishing to maven, but
>> (again) I don't know others' downstream expectations. -C
>
> Thanks for slogging through all those jars. If you're willing to vouch
for the jars' licenses then I think things are good for a release.
>
>
> Regards,
> Alan
>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <ad...@toolazydogs.com>.
I am of the same mind as Chris. I'm not here to pass value judgments on what projects wish to put in their releases. If I see something odd I will merely point it out and let the project decide on what to do.
On Nov 5, 2011, at 10:32 PM, Chris Douglas wrote:
> I went through the included jars and didn't see anything that couldn't
> be redistributed. I also found all the licenses (included with the
> jars) that were required. I think the current release can go out
> as-is. I prefer source distributions and publishing to maven, but
> (again) I don't know others' downstream expectations. -C
Thanks for slogging through all those jars. If you're willing to vouch for the jars' licenses then I think things are good for a release.
Regards,
Alan
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Chris Douglas <cd...@apache.org>.
Sorry, I didn't see this. I'm subscribed to kafka-dev, but not kafka-users.
As Alan has often stated, issues like these are judgement calls. Kafka
may bundle ASL-compatible jars with its release tarball. Other
projects, like Hadoop, have done this in the past. I have almost no
experience distributing or consuming Scala projects, so I can't say
anything about downstream users' expectations. Speaking generally:
In its favor, the "out of the box" experience is simpler,
configuration is trivial, one can use the software without net access,
and FAQs on handling common quirks in a user's environment are shorter
for it. Against it, the distribution is considerably larger than it
needs to be, projects depending on this one may endure more
integration hassles, and the licensing for redistribution (auditing
each jar, ensuring all attribution clauses are satisfied, etc.) is
avoidable pain. The ASF is principally about producing source code,
but if the project wants to generate and distribute a tarball with
binary artifacts then I know of no policy preventing it.
I went through the included jars and didn't see anything that couldn't
be redistributed. I also found all the licenses (included with the
jars) that were required. I think the current release can go out
as-is. I prefer source distributions and publishing to maven, but
(again) I don't know others' downstream expectations. -C
On Sat, Nov 5, 2011 at 12:04 AM, Neha Narkhede <ne...@gmail.com> wrote:
> Alan/Chris,
>
> Please can you take a look at the alternatives here and let us know
> your thoughts ?
>
> Thanks,
> Neha
>
>
> ---------- Forwarded message ----------
> From: Neha Narkhede <ne...@gmail.com>
> Date: Fri, Nov 4, 2011 at 4:20 PM
> Subject: Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
> To: kafka-users@incubator.apache.org
>
>
> Alan/Chris,
>
> As the mentors/champion, I would encourage you to chime in here. We
> really want to make progress on this release. The issue found
> yesterday actually existed since the first RC. It will help to iron
> out issues all at once, instead of one RC at a time.
>
> Thanks,
> Neha
>
> On Fri, Nov 4, 2011 at 4:16 PM, Jay Kreps <ja...@gmail.com> wrote:
>> Fully agree. I don't particularly care if we have two distribution files or
>> one, but I think it is a bad user experience for the person who just wants
>> to start using our software to have to use SBT to fetch the jar files or
>> worse yet build it from source. Relying on maven to download jars doesn't
>> actually save anyone download time, it just adds more steps (you eventually
>> need the jars).
>>
>> -Jay
>>
>> On Fri, Nov 4, 2011 at 3:35 PM, Neha Narkhede <ne...@gmail.com>wrote:
>>
>>> > Therefore a binary distribution must include the dependent libraries
>>> > to make it run out of the box.
>>>
>>> I agree with Taylor here. That means our binary distribution will not
>>> have the jars in boot/test.
>>>
>>> >> > If someone wants to run tests they are a developer and should get a
>>> > source distribution.
>>>
>>> This is also a good suggestion. That means we can upload a source
>>> distribution along with the binary distribution.
>>>
>>> I would encourage everyone to speak up here, to avoid delaying this
>>> release any further.
>>>
>>> Thanks,
>>> Neha
>>>
>>> On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier <tg...@tagged.com>
>>> wrote:
>>> > My $.02
>>> >
>>> > There are different audiences for different target distributions
>>> > - binary distribution : end user (developer) or sysadmin
>>> > - source distribution : a developer
>>> >
>>> > Therefore a binary distribution must include the dependent libraries
>>> > to make it run out of the box.
>>> >
>>> > That doesn't include tests because the audience for a binary
>>> > distribution doesn't run tests.
>>> >
>>> > If someone wants to run tests they are a developer and should get a
>>> > source distribution.
>>> >
>>> > The source distribution should NOT contain binary dependencies. In
>>> > this case Maven or another suitable build tool should resolve any
>>> > dependencies during the build stage.
>>> >
>>> >
>>> >
>>> > On Nov 4, 2011, at 8:51 AM, Neha Narkhede <ne...@gmail.com>
>>> wrote:
>>> >
>>> >> Let me state why we included *all* the dependencies in the package
>>> >> distribution. Initially I thought this distribution should just work
>>> >> out-of-the-box after the download. That includes all unit tests, all
>>> >> scripts in core as well as contrib. Note that the assumption was to not
>>> >> have the user run ./sbt udpate to download dependencies or ./sbt
>>> package to
>>> >> build the sub projects.
>>> >>
>>> >> Now, assuming we have the user do both, here is the set of jars we can
>>> >> include -
>>> >>
>>> >> ./core/lib/zkclient-20110412.jar
>>> >> ./lib/apache-rat-0.8-SNAPSHOT.jar
>>> >> ./lib/sbt-launch.jar
>>> >> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
>>> >> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
>>> >> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
>>> >> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
>>> >> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
>>> >> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
>>> >> ./contrib/hadoop-consumer/lib/piggybank.jar
>>> >> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
>>> >> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
>>> >> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
>>> >> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
>>> >> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
>>> >> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
>>> >> ./contrib/hadoop-producer/lib/piggybank.jar
>>> >> .*
>>> >>
>>> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
>>> >>
>>> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
>>> >> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
>>> >> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>>> >>
>>> >> The jars in bold are Kafka jars. The question is how will the user be
>>> able
>>> >> to run our jars, with just the stripped set of dependent jars we
>>> package ?
>>> >>
>>> >>>> Many of the issues about distribution would automatically be solved if
>>> >> Maven were used.
>>> >>
>>> >> We use maven. All the jars in "lib_managed" are downloaded from Maven.
>>> The
>>> >> question is not whether or not to use Maven. The question is whether you
>>> >> have the user download dependencies build the jars themselves or not.
>>> >>
>>> >> Once that is clear, we can reduce the set of dependent jars we include.
>>> >>
>>> >> I would encourage everyone to give your inputs now, since this is
>>> important
>>> >> to iron out for further releases.
>>> >>
>>> >> Thanks,
>>> >> Neha
>>> >>
>>> >> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>>> >> wrote:
>>> >>> It would...
>>> >>>
>>> >>> Many of the issues about distribution would automatically be solved if
>>> >> Maven were used.
>>> >>>
>>> >>> <disclaimer>I'm a Maven zealot</disclaimer>
>>> >>>
>>> >>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>> >>>
>>> >>>> In regards to the size of the distribution, wouldn't a mavenized build
>>> >> help with this?
>>> >>>>
>>> >>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>> >>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>> >>>>>
>>> >>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>> >>>>>>> Zowie. Look at all these jars that I have to make sure are kosher
>>> to
>>> >> distribute:
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> Can someone help me?
>>> >>>>>>>
>>> >>>>>> Assuming we can cut down on the boot/test jars. All we need is a
>>> table
>>> >>>>>> of "jar-name,licence", correct?
>>> >>>>> As far as the number of jars I am only concerned with regard to the
>>> >> size of the distribution, 50M. That seems excessive to me and provides
>>> no
>>> >> real value given that the consumers of the distribution can easily build
>>> >> the product themselves.
>>> >>>>>
>>> >>>>> With that said, yes, it would be helpful of there was a list:
>>> >>>>>
>>> >>>>> jar name, license, URL that indicates the license for the jar
>>> >>>>>
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>> Alan
>>> >>>>>
>>> >>>
>>> >>>
>>> >
>>>
>>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Neha Narkhede <ne...@gmail.com>.
Alan/Chris,
As the mentors/champion, I would encourage you to chime in here. We
really want to make progress on this release. The issue found
yesterday actually existed since the first RC. It will help to iron
out issues all at once, instead of one RC at a time.
Thanks,
Neha
On Fri, Nov 4, 2011 at 4:16 PM, Jay Kreps <ja...@gmail.com> wrote:
> Fully agree. I don't particularly care if we have two distribution files or
> one, but I think it is a bad user experience for the person who just wants
> to start using our software to have to use SBT to fetch the jar files or
> worse yet build it from source. Relying on maven to download jars doesn't
> actually save anyone download time, it just adds more steps (you eventually
> need the jars).
>
> -Jay
>
> On Fri, Nov 4, 2011 at 3:35 PM, Neha Narkhede <ne...@gmail.com>wrote:
>
>> > Therefore a binary distribution must include the dependent libraries
>> > to make it run out of the box.
>>
>> I agree with Taylor here. That means our binary distribution will not
>> have the jars in boot/test.
>>
>> >> > If someone wants to run tests they are a developer and should get a
>> > source distribution.
>>
>> This is also a good suggestion. That means we can upload a source
>> distribution along with the binary distribution.
>>
>> I would encourage everyone to speak up here, to avoid delaying this
>> release any further.
>>
>> Thanks,
>> Neha
>>
>> On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier <tg...@tagged.com>
>> wrote:
>> > My $.02
>> >
>> > There are different audiences for different target distributions
>> > - binary distribution : end user (developer) or sysadmin
>> > - source distribution : a developer
>> >
>> > Therefore a binary distribution must include the dependent libraries
>> > to make it run out of the box.
>> >
>> > That doesn't include tests because the audience for a binary
>> > distribution doesn't run tests.
>> >
>> > If someone wants to run tests they are a developer and should get a
>> > source distribution.
>> >
>> > The source distribution should NOT contain binary dependencies. In
>> > this case Maven or another suitable build tool should resolve any
>> > dependencies during the build stage.
>> >
>> >
>> >
>> > On Nov 4, 2011, at 8:51 AM, Neha Narkhede <ne...@gmail.com>
>> wrote:
>> >
>> >> Let me state why we included *all* the dependencies in the package
>> >> distribution. Initially I thought this distribution should just work
>> >> out-of-the-box after the download. That includes all unit tests, all
>> >> scripts in core as well as contrib. Note that the assumption was to not
>> >> have the user run ./sbt udpate to download dependencies or ./sbt
>> package to
>> >> build the sub projects.
>> >>
>> >> Now, assuming we have the user do both, here is the set of jars we can
>> >> include -
>> >>
>> >> ./core/lib/zkclient-20110412.jar
>> >> ./lib/apache-rat-0.8-SNAPSHOT.jar
>> >> ./lib/sbt-launch.jar
>> >> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
>> >> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
>> >> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
>> >> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
>> >> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
>> >> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
>> >> ./contrib/hadoop-consumer/lib/piggybank.jar
>> >> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
>> >> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
>> >> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
>> >> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
>> >> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
>> >> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
>> >> ./contrib/hadoop-producer/lib/piggybank.jar
>> >> .*
>> >>
>> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
>> >>
>> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
>> >> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
>> >> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>> >>
>> >> The jars in bold are Kafka jars. The question is how will the user be
>> able
>> >> to run our jars, with just the stripped set of dependent jars we
>> package ?
>> >>
>> >>>> Many of the issues about distribution would automatically be solved if
>> >> Maven were used.
>> >>
>> >> We use maven. All the jars in "lib_managed" are downloaded from Maven.
>> The
>> >> question is not whether or not to use Maven. The question is whether you
>> >> have the user download dependencies build the jars themselves or not.
>> >>
>> >> Once that is clear, we can reduce the set of dependent jars we include.
>> >>
>> >> I would encourage everyone to give your inputs now, since this is
>> important
>> >> to iron out for further releases.
>> >>
>> >> Thanks,
>> >> Neha
>> >>
>> >> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>> >> wrote:
>> >>> It would...
>> >>>
>> >>> Many of the issues about distribution would automatically be solved if
>> >> Maven were used.
>> >>>
>> >>> <disclaimer>I'm a Maven zealot</disclaimer>
>> >>>
>> >>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>> >>>
>> >>>> In regards to the size of the distribution, wouldn't a mavenized build
>> >> help with this?
>> >>>>
>> >>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>> >>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>> >>>>>
>> >>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>> >>>>>>> Zowie. Look at all these jars that I have to make sure are kosher
>> to
>> >> distribute:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> Can someone help me?
>> >>>>>>>
>> >>>>>> Assuming we can cut down on the boot/test jars. All we need is a
>> table
>> >>>>>> of "jar-name,licence", correct?
>> >>>>> As far as the number of jars I am only concerned with regard to the
>> >> size of the distribution, 50M. That seems excessive to me and provides
>> no
>> >> real value given that the consumers of the distribution can easily build
>> >> the product themselves.
>> >>>>>
>> >>>>> With that said, yes, it would be helpful of there was a list:
>> >>>>>
>> >>>>> jar name, license, URL that indicates the license for the jar
>> >>>>>
>> >>>>>
>> >>>>> Regards,
>> >>>>> Alan
>> >>>>>
>> >>>
>> >>>
>> >
>>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Jay Kreps <ja...@gmail.com>.
Fully agree. I don't particularly care if we have two distribution files or
one, but I think it is a bad user experience for the person who just wants
to start using our software to have to use SBT to fetch the jar files or
worse yet build it from source. Relying on maven to download jars doesn't
actually save anyone download time, it just adds more steps (you eventually
need the jars).
-Jay
On Fri, Nov 4, 2011 at 3:35 PM, Neha Narkhede <ne...@gmail.com>wrote:
> > Therefore a binary distribution must include the dependent libraries
> > to make it run out of the box.
>
> I agree with Taylor here. That means our binary distribution will not
> have the jars in boot/test.
>
> >> > If someone wants to run tests they are a developer and should get a
> > source distribution.
>
> This is also a good suggestion. That means we can upload a source
> distribution along with the binary distribution.
>
> I would encourage everyone to speak up here, to avoid delaying this
> release any further.
>
> Thanks,
> Neha
>
> On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier <tg...@tagged.com>
> wrote:
> > My $.02
> >
> > There are different audiences for different target distributions
> > - binary distribution : end user (developer) or sysadmin
> > - source distribution : a developer
> >
> > Therefore a binary distribution must include the dependent libraries
> > to make it run out of the box.
> >
> > That doesn't include tests because the audience for a binary
> > distribution doesn't run tests.
> >
> > If someone wants to run tests they are a developer and should get a
> > source distribution.
> >
> > The source distribution should NOT contain binary dependencies. In
> > this case Maven or another suitable build tool should resolve any
> > dependencies during the build stage.
> >
> >
> >
> > On Nov 4, 2011, at 8:51 AM, Neha Narkhede <ne...@gmail.com>
> wrote:
> >
> >> Let me state why we included *all* the dependencies in the package
> >> distribution. Initially I thought this distribution should just work
> >> out-of-the-box after the download. That includes all unit tests, all
> >> scripts in core as well as contrib. Note that the assumption was to not
> >> have the user run ./sbt udpate to download dependencies or ./sbt
> package to
> >> build the sub projects.
> >>
> >> Now, assuming we have the user do both, here is the set of jars we can
> >> include -
> >>
> >> ./core/lib/zkclient-20110412.jar
> >> ./lib/apache-rat-0.8-SNAPSHOT.jar
> >> ./lib/sbt-launch.jar
> >> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
> >> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
> >> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
> >> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
> >> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
> >> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
> >> ./contrib/hadoop-consumer/lib/piggybank.jar
> >> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
> >> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
> >> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
> >> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
> >> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
> >> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
> >> ./contrib/hadoop-producer/lib/piggybank.jar
> >> .*
> >>
> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
> >>
> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
> >> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
> >> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
> >>
> >> The jars in bold are Kafka jars. The question is how will the user be
> able
> >> to run our jars, with just the stripped set of dependent jars we
> package ?
> >>
> >>>> Many of the issues about distribution would automatically be solved if
> >> Maven were used.
> >>
> >> We use maven. All the jars in "lib_managed" are downloaded from Maven.
> The
> >> question is not whether or not to use Maven. The question is whether you
> >> have the user download dependencies build the jars themselves or not.
> >>
> >> Once that is clear, we can reduce the set of dependent jars we include.
> >>
> >> I would encourage everyone to give your inputs now, since this is
> important
> >> to iron out for further releases.
> >>
> >> Thanks,
> >> Neha
> >>
> >> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
> >> wrote:
> >>> It would...
> >>>
> >>> Many of the issues about distribution would automatically be solved if
> >> Maven were used.
> >>>
> >>> <disclaimer>I'm a Maven zealot</disclaimer>
> >>>
> >>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
> >>>
> >>>> In regards to the size of the distribution, wouldn't a mavenized build
> >> help with this?
> >>>>
> >>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
> >>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
> >>>>>
> >>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
> >>>>>>> Zowie. Look at all these jars that I have to make sure are kosher
> to
> >> distribute:
> >>>>>>>
> >>>>>>>
> >>>>>>> Can someone help me?
> >>>>>>>
> >>>>>> Assuming we can cut down on the boot/test jars. All we need is a
> table
> >>>>>> of "jar-name,licence", correct?
> >>>>> As far as the number of jars I am only concerned with regard to the
> >> size of the distribution, 50M. That seems excessive to me and provides
> no
> >> real value given that the consumers of the distribution can easily build
> >> the product themselves.
> >>>>>
> >>>>> With that said, yes, it would be helpful of there was a list:
> >>>>>
> >>>>> jar name, license, URL that indicates the license for the jar
> >>>>>
> >>>>>
> >>>>> Regards,
> >>>>> Alan
> >>>>>
> >>>
> >>>
> >
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Mark <st...@gmail.com>.
+1 on two separate distributions
On 11/4/11 3:35 PM, Neha Narkhede wrote:
>> Therefore a binary distribution must include the dependent libraries
>> to make it run out of the box.
> I agree with Taylor here. That means our binary distribution will not
> have the jars in boot/test.
>
>>>> If someone wants to run tests they are a developer and should get a
>> source distribution.
> This is also a good suggestion. That means we can upload a source
> distribution along with the binary distribution.
>
> I would encourage everyone to speak up here, to avoid delaying this
> release any further.
>
> Thanks,
> Neha
>
> On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier<tg...@tagged.com> wrote:
>> My $.02
>>
>> There are different audiences for different target distributions
>> - binary distribution : end user (developer) or sysadmin
>> - source distribution : a developer
>>
>> Therefore a binary distribution must include the dependent libraries
>> to make it run out of the box.
>>
>> That doesn't include tests because the audience for a binary
>> distribution doesn't run tests.
>>
>> If someone wants to run tests they are a developer and should get a
>> source distribution.
>>
>> The source distribution should NOT contain binary dependencies. In
>> this case Maven or another suitable build tool should resolve any
>> dependencies during the build stage.
>>
>>
>>
>> On Nov 4, 2011, at 8:51 AM, Neha Narkhede<ne...@gmail.com> wrote:
>>
>>> Let me state why we included *all* the dependencies in the package
>>> distribution. Initially I thought this distribution should just work
>>> out-of-the-box after the download. That includes all unit tests, all
>>> scripts in core as well as contrib. Note that the assumption was to not
>>> have the user run ./sbt udpate to download dependencies or ./sbt package to
>>> build the sub projects.
>>>
>>> Now, assuming we have the user do both, here is the set of jars we can
>>> include -
>>>
>>> ./core/lib/zkclient-20110412.jar
>>> ./lib/apache-rat-0.8-SNAPSHOT.jar
>>> ./lib/sbt-launch.jar
>>> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
>>> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
>>> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
>>> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
>>> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
>>> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
>>> ./contrib/hadoop-consumer/lib/piggybank.jar
>>> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
>>> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
>>> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
>>> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
>>> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
>>> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
>>> ./contrib/hadoop-producer/lib/piggybank.jar
>>> .*
>>> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
>>> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
>>> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
>>> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>>>
>>> The jars in bold are Kafka jars. The question is how will the user be able
>>> to run our jars, with just the stripped set of dependent jars we package ?
>>>
>>>>> Many of the issues about distribution would automatically be solved if
>>> Maven were used.
>>>
>>> We use maven. All the jars in "lib_managed" are downloaded from Maven. The
>>> question is not whether or not to use Maven. The question is whether you
>>> have the user download dependencies build the jars themselves or not.
>>>
>>> Once that is clear, we can reduce the set of dependent jars we include.
>>>
>>> I would encourage everyone to give your inputs now, since this is important
>>> to iron out for further releases.
>>>
>>> Thanks,
>>> Neha
>>>
>>> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera<li...@toolazydogs.com>
>>> wrote:
>>>> It would...
>>>>
>>>> Many of the issues about distribution would automatically be solved if
>>> Maven were used.
>>>> <disclaimer>I'm a Maven zealot</disclaimer>
>>>>
>>>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>>>
>>>>> In regards to the size of the distribution, wouldn't a mavenized build
>>> help with this?
>>>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>>>>
>>>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>>>>> Zowie. Look at all these jars that I have to make sure are kosher to
>>> distribute:
>>>>>>>>
>>>>>>>> Can someone help me?
>>>>>>>>
>>>>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>>>>> of "jar-name,licence", correct?
>>>>>> As far as the number of jars I am only concerned with regard to the
>>> size of the distribution, 50M. That seems excessive to me and provides no
>>> real value given that the consumers of the distribution can easily build
>>> the product themselves.
>>>>>> With that said, yes, it would be helpful of there was a list:
>>>>>>
>>>>>> jar name, license, URL that indicates the license for the jar
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Alan
>>>>>>
>>>>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Neha Narkhede <ne...@gmail.com>.
> Therefore a binary distribution must include the dependent libraries
> to make it run out of the box.
I agree with Taylor here. That means our binary distribution will not
have the jars in boot/test.
>> > If someone wants to run tests they are a developer and should get a
> source distribution.
This is also a good suggestion. That means we can upload a source
distribution along with the binary distribution.
I would encourage everyone to speak up here, to avoid delaying this
release any further.
Thanks,
Neha
On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier <tg...@tagged.com> wrote:
> My $.02
>
> There are different audiences for different target distributions
> - binary distribution : end user (developer) or sysadmin
> - source distribution : a developer
>
> Therefore a binary distribution must include the dependent libraries
> to make it run out of the box.
>
> That doesn't include tests because the audience for a binary
> distribution doesn't run tests.
>
> If someone wants to run tests they are a developer and should get a
> source distribution.
>
> The source distribution should NOT contain binary dependencies. In
> this case Maven or another suitable build tool should resolve any
> dependencies during the build stage.
>
>
>
> On Nov 4, 2011, at 8:51 AM, Neha Narkhede <ne...@gmail.com> wrote:
>
>> Let me state why we included *all* the dependencies in the package
>> distribution. Initially I thought this distribution should just work
>> out-of-the-box after the download. That includes all unit tests, all
>> scripts in core as well as contrib. Note that the assumption was to not
>> have the user run ./sbt udpate to download dependencies or ./sbt package to
>> build the sub projects.
>>
>> Now, assuming we have the user do both, here is the set of jars we can
>> include -
>>
>> ./core/lib/zkclient-20110412.jar
>> ./lib/apache-rat-0.8-SNAPSHOT.jar
>> ./lib/sbt-launch.jar
>> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
>> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
>> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
>> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
>> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
>> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
>> ./contrib/hadoop-consumer/lib/piggybank.jar
>> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
>> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
>> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
>> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
>> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
>> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
>> ./contrib/hadoop-producer/lib/piggybank.jar
>> .*
>> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
>> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
>> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
>> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>>
>> The jars in bold are Kafka jars. The question is how will the user be able
>> to run our jars, with just the stripped set of dependent jars we package ?
>>
>>>> Many of the issues about distribution would automatically be solved if
>> Maven were used.
>>
>> We use maven. All the jars in "lib_managed" are downloaded from Maven. The
>> question is not whether or not to use Maven. The question is whether you
>> have the user download dependencies build the jars themselves or not.
>>
>> Once that is clear, we can reduce the set of dependent jars we include.
>>
>> I would encourage everyone to give your inputs now, since this is important
>> to iron out for further releases.
>>
>> Thanks,
>> Neha
>>
>> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>> It would...
>>>
>>> Many of the issues about distribution would automatically be solved if
>> Maven were used.
>>>
>>> <disclaimer>I'm a Maven zealot</disclaimer>
>>>
>>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>>
>>>> In regards to the size of the distribution, wouldn't a mavenized build
>> help with this?
>>>>
>>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>>>
>>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>>>> Zowie. Look at all these jars that I have to make sure are kosher to
>> distribute:
>>>>>>>
>>>>>>>
>>>>>>> Can someone help me?
>>>>>>>
>>>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>>>> of "jar-name,licence", correct?
>>>>> As far as the number of jars I am only concerned with regard to the
>> size of the distribution, 50M. That seems excessive to me and provides no
>> real value given that the consumers of the distribution can easily build
>> the product themselves.
>>>>>
>>>>> With that said, yes, it would be helpful of there was a list:
>>>>>
>>>>> jar name, license, URL that indicates the license for the jar
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>
>>>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Neha Narkhede <ne...@gmail.com>.
> Therefore a binary distribution must include the dependent libraries
> to make it run out of the box.
I agree with Taylor here. That means our binary distribution will not
have the jars in boot/test.
>> > If someone wants to run tests they are a developer and should get a
> source distribution.
This is also a good suggestion. That means we can upload a source
distribution along with the binary distribution.
I would encourage everyone to speak up here, to avoid delaying this
release any further.
Thanks,
Neha
On Fri, Nov 4, 2011 at 9:16 AM, Taylor Gautier <tg...@tagged.com> wrote:
> My $.02
>
> There are different audiences for different target distributions
> - binary distribution : end user (developer) or sysadmin
> - source distribution : a developer
>
> Therefore a binary distribution must include the dependent libraries
> to make it run out of the box.
>
> That doesn't include tests because the audience for a binary
> distribution doesn't run tests.
>
> If someone wants to run tests they are a developer and should get a
> source distribution.
>
> The source distribution should NOT contain binary dependencies. In
> this case Maven or another suitable build tool should resolve any
> dependencies during the build stage.
>
>
>
> On Nov 4, 2011, at 8:51 AM, Neha Narkhede <ne...@gmail.com> wrote:
>
>> Let me state why we included *all* the dependencies in the package
>> distribution. Initially I thought this distribution should just work
>> out-of-the-box after the download. That includes all unit tests, all
>> scripts in core as well as contrib. Note that the assumption was to not
>> have the user run ./sbt udpate to download dependencies or ./sbt package to
>> build the sub projects.
>>
>> Now, assuming we have the user do both, here is the set of jars we can
>> include -
>>
>> ./core/lib/zkclient-20110412.jar
>> ./lib/apache-rat-0.8-SNAPSHOT.jar
>> ./lib/sbt-launch.jar
>> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
>> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
>> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
>> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
>> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
>> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
>> ./contrib/hadoop-consumer/lib/piggybank.jar
>> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
>> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
>> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
>> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
>> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
>> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
>> ./contrib/hadoop-producer/lib/piggybank.jar
>> .*
>> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
>> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
>> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
>> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>>
>> The jars in bold are Kafka jars. The question is how will the user be able
>> to run our jars, with just the stripped set of dependent jars we package ?
>>
>>>> Many of the issues about distribution would automatically be solved if
>> Maven were used.
>>
>> We use maven. All the jars in "lib_managed" are downloaded from Maven. The
>> question is not whether or not to use Maven. The question is whether you
>> have the user download dependencies build the jars themselves or not.
>>
>> Once that is clear, we can reduce the set of dependent jars we include.
>>
>> I would encourage everyone to give your inputs now, since this is important
>> to iron out for further releases.
>>
>> Thanks,
>> Neha
>>
>> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
>> wrote:
>>> It would...
>>>
>>> Many of the issues about distribution would automatically be solved if
>> Maven were used.
>>>
>>> <disclaimer>I'm a Maven zealot</disclaimer>
>>>
>>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>>
>>>> In regards to the size of the distribution, wouldn't a mavenized build
>> help with this?
>>>>
>>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>>>
>>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>>>> Zowie. Look at all these jars that I have to make sure are kosher to
>> distribute:
>>>>>>>
>>>>>>>
>>>>>>> Can someone help me?
>>>>>>>
>>>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>>>> of "jar-name,licence", correct?
>>>>> As far as the number of jars I am only concerned with regard to the
>> size of the distribution, 50M. That seems excessive to me and provides no
>> real value given that the consumers of the distribution can easily build
>> the product themselves.
>>>>>
>>>>> With that said, yes, it would be helpful of there was a list:
>>>>>
>>>>> jar name, license, URL that indicates the license for the jar
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>
>>>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Taylor Gautier <tg...@tagged.com>.
My $.02
There are different audiences for different target distributions
- binary distribution : end user (developer) or sysadmin
- source distribution : a developer
Therefore a binary distribution must include the dependent libraries
to make it run out of the box.
That doesn't include tests because the audience for a binary
distribution doesn't run tests.
If someone wants to run tests they are a developer and should get a
source distribution.
The source distribution should NOT contain binary dependencies. In
this case Maven or another suitable build tool should resolve any
dependencies during the build stage.
On Nov 4, 2011, at 8:51 AM, Neha Narkhede <ne...@gmail.com> wrote:
> Let me state why we included *all* the dependencies in the package
> distribution. Initially I thought this distribution should just work
> out-of-the-box after the download. That includes all unit tests, all
> scripts in core as well as contrib. Note that the assumption was to not
> have the user run ./sbt udpate to download dependencies or ./sbt package to
> build the sub projects.
>
> Now, assuming we have the user do both, here is the set of jars we can
> include -
>
> ./core/lib/zkclient-20110412.jar
> ./lib/apache-rat-0.8-SNAPSHOT.jar
> ./lib/sbt-launch.jar
> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-consumer/lib/piggybank.jar
> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-producer/lib/piggybank.jar
> .*
> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>
> The jars in bold are Kafka jars. The question is how will the user be able
> to run our jars, with just the stripped set of dependent jars we package ?
>
>>> Many of the issues about distribution would automatically be solved if
> Maven were used.
>
> We use maven. All the jars in "lib_managed" are downloaded from Maven. The
> question is not whether or not to use Maven. The question is whether you
> have the user download dependencies build the jars themselves or not.
>
> Once that is clear, we can reduce the set of dependent jars we include.
>
> I would encourage everyone to give your inputs now, since this is important
> to iron out for further releases.
>
> Thanks,
> Neha
>
> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
>> It would...
>>
>> Many of the issues about distribution would automatically be solved if
> Maven were used.
>>
>> <disclaimer>I'm a Maven zealot</disclaimer>
>>
>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>
>>> In regards to the size of the distribution, wouldn't a mavenized build
> help with this?
>>>
>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>>
>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>>> Zowie. Look at all these jars that I have to make sure are kosher to
> distribute:
>>>>>>
>>>>>>
>>>>>> Can someone help me?
>>>>>>
>>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>>> of "jar-name,licence", correct?
>>>> As far as the number of jars I am only concerned with regard to the
> size of the distribution, 50M. That seems excessive to me and provides no
> real value given that the consumers of the distribution can easily build
> the product themselves.
>>>>
>>>> With that said, yes, it would be helpful of there was a list:
>>>>
>>>> jar name, license, URL that indicates the license for the jar
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>
>>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Taylor Gautier <tg...@tagged.com>.
My $.02
There are different audiences for different target distributions
- binary distribution : end user (developer) or sysadmin
- source distribution : a developer
Therefore a binary distribution must include the dependent libraries
to make it run out of the box.
That doesn't include tests because the audience for a binary
distribution doesn't run tests.
If someone wants to run tests they are a developer and should get a
source distribution.
The source distribution should NOT contain binary dependencies. In
this case Maven or another suitable build tool should resolve any
dependencies during the build stage.
On Nov 4, 2011, at 8:51 AM, Neha Narkhede <ne...@gmail.com> wrote:
> Let me state why we included *all* the dependencies in the package
> distribution. Initially I thought this distribution should just work
> out-of-the-box after the download. That includes all unit tests, all
> scripts in core as well as contrib. Note that the assumption was to not
> have the user run ./sbt udpate to download dependencies or ./sbt package to
> build the sub projects.
>
> Now, assuming we have the user do both, here is the set of jars we can
> include -
>
> ./core/lib/zkclient-20110412.jar
> ./lib/apache-rat-0.8-SNAPSHOT.jar
> ./lib/sbt-launch.jar
> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-consumer/lib/piggybank.jar
> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-producer/lib/piggybank.jar
> .*
> /contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
> ./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
> ./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
> ./core/target/scala_2.8.0/kafka-0.7.0.jar*
>
> The jars in bold are Kafka jars. The question is how will the user be able
> to run our jars, with just the stripped set of dependent jars we package ?
>
>>> Many of the issues about distribution would automatically be solved if
> Maven were used.
>
> We use maven. All the jars in "lib_managed" are downloaded from Maven. The
> question is not whether or not to use Maven. The question is whether you
> have the user download dependencies build the jars themselves or not.
>
> Once that is clear, we can reduce the set of dependent jars we include.
>
> I would encourage everyone to give your inputs now, since this is important
> to iron out for further releases.
>
> Thanks,
> Neha
>
> On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
> wrote:
>> It would...
>>
>> Many of the issues about distribution would automatically be solved if
> Maven were used.
>>
>> <disclaimer>I'm a Maven zealot</disclaimer>
>>
>> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>>
>>> In regards to the size of the distribution, wouldn't a mavenized build
> help with this?
>>>
>>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>>
>>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>>> Zowie. Look at all these jars that I have to make sure are kosher to
> distribute:
>>>>>>
>>>>>>
>>>>>> Can someone help me?
>>>>>>
>>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>>> of "jar-name,licence", correct?
>>>> As far as the number of jars I am only concerned with regard to the
> size of the distribution, 50M. That seems excessive to me and provides no
> real value given that the consumers of the distribution can easily build
> the product themselves.
>>>>
>>>> With that said, yes, it would be helpful of there was a list:
>>>>
>>>> jar name, license, URL that indicates the license for the jar
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>
>>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Neha Narkhede <ne...@gmail.com>.
Let me state why we included *all* the dependencies in the package
distribution. Initially I thought this distribution should just work
out-of-the-box after the download. That includes all unit tests, all
scripts in core as well as contrib. Note that the assumption was to not
have the user run ./sbt udpate to download dependencies or ./sbt package to
build the sub projects.
Now, assuming we have the user do both, here is the set of jars we can
include -
./core/lib/zkclient-20110412.jar
./lib/apache-rat-0.8-SNAPSHOT.jar
./lib/sbt-launch.jar
./contrib/hadoop-consumer/lib/avro-1.4.0.jar
./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
./contrib/hadoop-consumer/lib/piggybank.jar
./contrib/hadoop-producer/lib/avro-1.4.0.jar
./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
./contrib/hadoop-producer/lib/piggybank.jar
.*
/contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
./core/target/scala_2.8.0/kafka-0.7.0.jar*
The jars in bold are Kafka jars. The question is how will the user be able
to run our jars, with just the stripped set of dependent jars we package ?
>> Many of the issues about distribution would automatically be solved if
Maven were used.
We use maven. All the jars in "lib_managed" are downloaded from Maven. The
question is not whether or not to use Maven. The question is whether you
have the user download dependencies build the jars themselves or not.
Once that is clear, we can reduce the set of dependent jars we include.
I would encourage everyone to give your inputs now, since this is important
to iron out for further releases.
Thanks,
Neha
On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
wrote:
> It would...
>
> Many of the issues about distribution would automatically be solved if
Maven were used.
>
> <disclaimer>I'm a Maven zealot</disclaimer>
>
> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>
>> In regards to the size of the distribution, wouldn't a mavenized build
help with this?
>>
>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>
>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>> Zowie. Look at all these jars that I have to make sure are kosher to
distribute:
>>>>>
>>>>>
>>>>> Can someone help me?
>>>>>
>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>> of "jar-name,licence", correct?
>>> As far as the number of jars I am only concerned with regard to the
size of the distribution, 50M. That seems excessive to me and provides no
real value given that the consumers of the distribution can easily build
the product themselves.
>>>
>>> With that said, yes, it would be helpful of there was a list:
>>>
>>> jar name, license, URL that indicates the license for the jar
>>>
>>>
>>> Regards,
>>> Alan
>>>
>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Neha Narkhede <ne...@gmail.com>.
Let me state why we included *all* the dependencies in the package
distribution. Initially I thought this distribution should just work
out-of-the-box after the download. That includes all unit tests, all
scripts in core as well as contrib. Note that the assumption was to not
have the user run ./sbt udpate to download dependencies or ./sbt package to
build the sub projects.
Now, assuming we have the user do both, here is the set of jars we can
include -
./core/lib/zkclient-20110412.jar
./lib/apache-rat-0.8-SNAPSHOT.jar
./lib/sbt-launch.jar
./contrib/hadoop-consumer/lib/avro-1.4.0.jar
./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
./contrib/hadoop-consumer/lib/piggybank.jar
./contrib/hadoop-producer/lib/avro-1.4.0.jar
./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
./contrib/hadoop-producer/lib/piggybank.jar
.*
/contrib/hadoop-consumer/target/scala_2.8.0/hadoop-consumer_2.8.0-0.7.0.jar
./contrib/hadoop-producer/target/scala_2.8.0/hadoop-producer_2.8.0-0.7.0.jar
./examples/target/scala_2.8.0/kafka-java-examples-0.7.0.jar
./core/target/scala_2.8.0/kafka-0.7.0.jar*
The jars in bold are Kafka jars. The question is how will the user be able
to run our jars, with just the stripped set of dependent jars we package ?
>> Many of the issues about distribution would automatically be solved if
Maven were used.
We use maven. All the jars in "lib_managed" are downloaded from Maven. The
question is not whether or not to use Maven. The question is whether you
have the user download dependencies build the jars themselves or not.
Once that is clear, we can reduce the set of dependent jars we include.
I would encourage everyone to give your inputs now, since this is important
to iron out for further releases.
Thanks,
Neha
On Fri, Nov 4, 2011 at 8:26 AM, Alan D. Cabrera <li...@toolazydogs.com>
wrote:
> It would...
>
> Many of the issues about distribution would automatically be solved if
Maven were used.
>
> <disclaimer>I'm a Maven zealot</disclaimer>
>
> On Nov 4, 2011, at 8:17 AM, Mark wrote:
>
>> In regards to the size of the distribution, wouldn't a mavenized build
help with this?
>>
>> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>>
>>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>>> Zowie. Look at all these jars that I have to make sure are kosher to
distribute:
>>>>>
>>>>>
>>>>> Can someone help me?
>>>>>
>>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>>> of "jar-name,licence", correct?
>>> As far as the number of jars I am only concerned with regard to the
size of the distribution, 50M. That seems excessive to me and provides no
real value given that the consumers of the distribution can easily build
the product themselves.
>>>
>>> With that said, yes, it would be helpful of there was a list:
>>>
>>> jar name, license, URL that indicates the license for the jar
>>>
>>>
>>> Regards,
>>> Alan
>>>
>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
It would...
Many of the issues about distribution would automatically be solved if Maven were used.
<disclaimer>I'm a Maven zealot</disclaimer>
On Nov 4, 2011, at 8:17 AM, Mark wrote:
> In regards to the size of the distribution, wouldn't a mavenized build help with this?
>
> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>
>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>>>>
>>>>
>>>> Can someone help me?
>>>>
>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>> of "jar-name,licence", correct?
>> As far as the number of jars I am only concerned with regard to the size of the distribution, 50M. That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
>>
>> With that said, yes, it would be helpful of there was a list:
>>
>> jar name, license, URL that indicates the license for the jar
>>
>>
>> Regards,
>> Alan
>>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
It would...
Many of the issues about distribution would automatically be solved if Maven were used.
<disclaimer>I'm a Maven zealot</disclaimer>
On Nov 4, 2011, at 8:17 AM, Mark wrote:
> In regards to the size of the distribution, wouldn't a mavenized build help with this?
>
> On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
>> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>>
>>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>>> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>>>>
>>>>
>>>> Can someone help me?
>>>>
>>> Assuming we can cut down on the boot/test jars. All we need is a table
>>> of "jar-name,licence", correct?
>> As far as the number of jars I am only concerned with regard to the size of the distribution, 50M. That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
>>
>> With that said, yes, it would be helpful of there was a list:
>>
>> jar name, license, URL that indicates the license for the jar
>>
>>
>> Regards,
>> Alan
>>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Mark <st...@gmail.com>.
In regards to the size of the distribution, wouldn't a mavenized build
help with this?
On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>
>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>>>
>>>
>>> Can someone help me?
>>>
>> Assuming we can cut down on the boot/test jars. All we need is a table
>> of "jar-name,licence", correct?
> As far as the number of jars I am only concerned with regard to the size of the distribution, 50M. That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
>
> With that said, yes, it would be helpful of there was a list:
>
> jar name, license, URL that indicates the license for the jar
>
>
> Regards,
> Alan
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Mark <st...@gmail.com>.
In regards to the size of the distribution, wouldn't a mavenized build
help with this?
On 11/4/11 7:42 AM, Alan D. Cabrera wrote:
> On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
>
>> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>>> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>>>
>>>
>>> Can someone help me?
>>>
>> Assuming we can cut down on the boot/test jars. All we need is a table
>> of "jar-name,licence", correct?
> As far as the number of jars I am only concerned with regard to the size of the distribution, 50M. That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
>
> With that said, yes, it would be helpful of there was a list:
>
> jar name, license, URL that indicates the license for the jar
>
>
> Regards,
> Alan
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>>
>>
>> Can someone help me?
>>
>
> Assuming we can cut down on the boot/test jars. All we need is a table
> of "jar-name,licence", correct?
As far as the number of jars I am only concerned with regard to the size of the distribution, 50M. That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
With that said, yes, it would be helpful of there was a list:
jar name, license, URL that indicates the license for the jar
Regards,
Alan
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Nov 4, 2011, at 7:29 AM, Chris Burroughs wrote:
> On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
>> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>>
>>
>> Can someone help me?
>>
>
> Assuming we can cut down on the boot/test jars. All we need is a table
> of "jar-name,licence", correct?
As far as the number of jars I am only concerned with regard to the size of the distribution, 50M. That seems excessive to me and provides no real value given that the consumers of the distribution can easily build the product themselves.
With that said, yes, it would be helpful of there was a list:
jar name, license, URL that indicates the license for the jar
Regards,
Alan
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Chris Burroughs <ch...@gmail.com>.
On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>
>
> Can someone help me?
>
Assuming we can cut down on the boot/test jars. All we need is a table
of "jar-name,licence", correct?
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Chris Burroughs <ch...@gmail.com>.
On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>
>
> Can someone help me?
>
Assuming we can cut down on the boot/test jars. All we need is a table
of "jar-name,licence", correct?
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Chris Burroughs <ch...@gmail.com>.
On 11/03/2011 04:11 PM, Chris Burroughs wrote:
> To Alan and Jay's point, I don't think there is a need to distribut the
> ./boot jars.
>
And I think the same applies to test dependencies.
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Chris Burroughs <ch...@gmail.com>.
On 11/03/2011 04:11 PM, Chris Burroughs wrote:
> To Alan and Jay's point, I don't think there is a need to distribut the
> ./boot jars.
>
And I think the same applies to test dependencies.
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Chris Burroughs <ch...@gmail.com>.
To Alan and Jay's point, I don't think there is a need to distribut the
./boot jars.
I thought we went over the rest in KAFKA-142, but looking back it
doesn't sound as definitive.
On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>
> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-consumer/lib/piggybank.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.2.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-producer/lib/piggybank.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.7.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-launcher-1.7.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-collections-3.2.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-6.1.22.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.22.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-20081211.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/velocity-1.6.4.jar
> ./core/lib/zkclient-20110412.jar
> ./core/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./core/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./core/lib_managed/scala_2.8.0/compile/zookeeper-3.3.3.jar
> ./core/lib_managed/scala_2.8.0/test/cglib-nodep-2.2.jar
> ./core/lib_managed/scala_2.8.0/test/easymock-3.0.jar
> ./core/lib_managed/scala_2.8.0/test/junit-4.1.jar
> ./core/lib_managed/scala_2.8.0/test/objenesis-1.2.jar
> ./core/lib_managed/scala_2.8.0/test/scalatest-1.2.jar
> ./examples/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./examples/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./kafka-0.7.0.jar
> ./lib/apache-rat-0.8-SNAPSHOT.jar
> ./lib/sbt-launch.jar
> ./project/boot/scala-2.7.7/lib/scala-compiler.jar
> ./project/boot/scala-2.7.7/lib/scala-library.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/classpath_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compile_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.7.7.final/compiler-interface-bin-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.0.final/compiler-interface-bin-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.1.final/compiler-interface-bin-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/compiler-interface-src-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/jline-0.9.94.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/control_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/io_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy-2.2.0.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/jsch-0.1.31.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/launcher-interface-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/sbt_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/test-interface-0.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/xsbti/interface-0.7.5.jar
> ./project/boot/scala-2.8.0/lib/scala-compiler.jar
> ./project/boot/scala-2.8.0/lib/scala-library.jar
> ./project/plugins/lib_managed/scala_2.7.7/sbt-idea-core_2.7.7-0.1-SNAPSHOT.jar
> ./project/plugins/lib_managed/scala_2.7.7/sbt-idea-plugin-0.1-SNAPSHOT.jar
>
>
> Can someone help me?
>
>
> Regards,
> Alan
>
>
> On Nov 3, 2011, at 11:55 AM, Jun Rao wrote:
>
>> Hi, everyone,
>>
>> This will be our very first Apache release. I encourage everyone to try the
>> RC out and vote on it. This will greatly help the Kafka community.
>>
>> Thanks,
>>
>> Jun
>>
>> ---------- Forwarded message ----------
>> From: Neha Narkhede <ne...@gmail.com>
>> Date: Mon, Oct 31, 2011 at 5:44 PM
>> Subject: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
>> To: kafka-users@incubator.apache.org
>> Cc: kafka-dev@incubator.apache.org
>>
>>
>> Hi,
>>
>> This is the fifth candidate for the first incubator release for Apache
>> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
>> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
>> those.
>>
>> It also fixes the following issues:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Nov 3rd, 6 pm
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before any release can be made official.
>>
>> Thanks,
>> Neha
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Chris Burroughs <ch...@gmail.com>.
To Alan and Jay's point, I don't think there is a need to distribut the
./boot jars.
I thought we went over the rest in KAFKA-142, but looking back it
doesn't sound as definitive.
On 11/03/2011 03:41 PM, Alan D. Cabrera wrote:
> Zowie. Look at all these jars that I have to make sure are kosher to distribute:
>
> ./contrib/hadoop-consumer/lib/avro-1.4.0.jar
> ./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-consumer/lib/piggybank.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.2.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.0.4.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./contrib/hadoop-producer/lib/avro-1.4.0.jar
> ./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
> ./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
> ./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
> ./contrib/hadoop-producer/lib/piggybank.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.7.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-launcher-1.7.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-collections-3.2.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.5.5.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-6.1.22.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.22.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-20081211.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar
> ./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/velocity-1.6.4.jar
> ./core/lib/zkclient-20110412.jar
> ./core/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./core/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./core/lib_managed/scala_2.8.0/compile/zookeeper-3.3.3.jar
> ./core/lib_managed/scala_2.8.0/test/cglib-nodep-2.2.jar
> ./core/lib_managed/scala_2.8.0/test/easymock-3.0.jar
> ./core/lib_managed/scala_2.8.0/test/junit-4.1.jar
> ./core/lib_managed/scala_2.8.0/test/objenesis-1.2.jar
> ./core/lib_managed/scala_2.8.0/test/scalatest-1.2.jar
> ./examples/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
> ./examples/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
> ./kafka-0.7.0.jar
> ./lib/apache-rat-0.8-SNAPSHOT.jar
> ./lib/sbt-launch.jar
> ./project/boot/scala-2.7.7/lib/scala-compiler.jar
> ./project/boot/scala-2.7.7/lib/scala-library.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/classpath_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compile_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.7.7.final/compiler-interface-bin-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.0.final/compiler-interface-bin-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.1.final/compiler-interface-bin-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/compiler-interface-src-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/jline-0.9.94.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/control_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/io_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy-2.2.0.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/jsch-0.1.31.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/launcher-interface-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/sbt_2.7.7-0.7.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/test-interface-0.5.jar
> ./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/xsbti/interface-0.7.5.jar
> ./project/boot/scala-2.8.0/lib/scala-compiler.jar
> ./project/boot/scala-2.8.0/lib/scala-library.jar
> ./project/plugins/lib_managed/scala_2.7.7/sbt-idea-core_2.7.7-0.1-SNAPSHOT.jar
> ./project/plugins/lib_managed/scala_2.7.7/sbt-idea-plugin-0.1-SNAPSHOT.jar
>
>
> Can someone help me?
>
>
> Regards,
> Alan
>
>
> On Nov 3, 2011, at 11:55 AM, Jun Rao wrote:
>
>> Hi, everyone,
>>
>> This will be our very first Apache release. I encourage everyone to try the
>> RC out and vote on it. This will greatly help the Kafka community.
>>
>> Thanks,
>>
>> Jun
>>
>> ---------- Forwarded message ----------
>> From: Neha Narkhede <ne...@gmail.com>
>> Date: Mon, Oct 31, 2011 at 5:44 PM
>> Subject: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
>> To: kafka-users@incubator.apache.org
>> Cc: kafka-dev@incubator.apache.org
>>
>>
>> Hi,
>>
>> This is the fifth candidate for the first incubator release for Apache
>> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
>> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
>> those.
>>
>> It also fixes the following issues:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Nov 3rd, 6 pm
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before any release can be made official.
>>
>> Thanks,
>> Neha
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Zowie. Look at all these jars that I have to make sure are kosher to distribute:
./contrib/hadoop-consumer/lib/avro-1.4.0.jar
./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
./contrib/hadoop-consumer/lib/piggybank.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.2.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./contrib/hadoop-producer/lib/avro-1.4.0.jar
./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
./contrib/hadoop-producer/lib/piggybank.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.7.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-launcher-1.7.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-collections-3.2.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-6.1.22.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.22.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-20081211.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/velocity-1.6.4.jar
./core/lib/zkclient-20110412.jar
./core/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./core/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./core/lib_managed/scala_2.8.0/compile/zookeeper-3.3.3.jar
./core/lib_managed/scala_2.8.0/test/cglib-nodep-2.2.jar
./core/lib_managed/scala_2.8.0/test/easymock-3.0.jar
./core/lib_managed/scala_2.8.0/test/junit-4.1.jar
./core/lib_managed/scala_2.8.0/test/objenesis-1.2.jar
./core/lib_managed/scala_2.8.0/test/scalatest-1.2.jar
./examples/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./examples/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./kafka-0.7.0.jar
./lib/apache-rat-0.8-SNAPSHOT.jar
./lib/sbt-launch.jar
./project/boot/scala-2.7.7/lib/scala-compiler.jar
./project/boot/scala-2.7.7/lib/scala-library.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/classpath_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compile_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.7.7.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.0.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.1.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/compiler-interface-src-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/jline-0.9.94.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/control_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/io_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy-2.2.0.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/jsch-0.1.31.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/launcher-interface-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/sbt_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/test-interface-0.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/xsbti/interface-0.7.5.jar
./project/boot/scala-2.8.0/lib/scala-compiler.jar
./project/boot/scala-2.8.0/lib/scala-library.jar
./project/plugins/lib_managed/scala_2.7.7/sbt-idea-core_2.7.7-0.1-SNAPSHOT.jar
./project/plugins/lib_managed/scala_2.7.7/sbt-idea-plugin-0.1-SNAPSHOT.jar
Can someone help me?
Regards,
Alan
On Nov 3, 2011, at 11:55 AM, Jun Rao wrote:
> Hi, everyone,
>
> This will be our very first Apache release. I encourage everyone to try the
> RC out and vote on it. This will greatly help the Kafka community.
>
> Thanks,
>
> Jun
>
> ---------- Forwarded message ----------
> From: Neha Narkhede <ne...@gmail.com>
> Date: Mon, Oct 31, 2011 at 5:44 PM
> Subject: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
> To: kafka-users@incubator.apache.org
> Cc: kafka-dev@incubator.apache.org
>
>
> Hi,
>
> This is the fifth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
> those.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 3rd, 6 pm
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Zowie. Look at all these jars that I have to make sure are kosher to distribute:
./contrib/hadoop-consumer/lib/avro-1.4.0.jar
./contrib/hadoop-consumer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-consumer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-consumer/lib/pig-0.8.0-core.jar
./contrib/hadoop-consumer/lib/piggybank.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-codec-1.2.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-httpclient-3.1.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/commons-logging-1.0.4.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/joda-time-1.6.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./contrib/hadoop-consumer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./contrib/hadoop-producer/lib/avro-1.4.0.jar
./contrib/hadoop-producer/lib/commons-logging-1.0.4.jar
./contrib/hadoop-producer/lib/hadoop-0.20.2-core.jar
./contrib/hadoop-producer/lib/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib/pig-0.8.0-core.jar
./contrib/hadoop-producer/lib/piggybank.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-1.7.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/ant-launcher-1.7.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/asm-3.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/avro-1.4.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-collections-3.2.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/commons-lang-2.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-core-asl-1.5.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jackson-mapper-asl-1.5.5.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-6.1.22.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jetty-util-6.1.22.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/oro-2.0.8.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-ant-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/paranamer-generator-2.2.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/qdox-1.10.1.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/servlet-api-2.5-20081211.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/slf4j-api-1.5.11.jar
./contrib/hadoop-producer/lib_managed/scala_2.8.0/compile/velocity-1.6.4.jar
./core/lib/zkclient-20110412.jar
./core/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./core/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./core/lib_managed/scala_2.8.0/compile/zookeeper-3.3.3.jar
./core/lib_managed/scala_2.8.0/test/cglib-nodep-2.2.jar
./core/lib_managed/scala_2.8.0/test/easymock-3.0.jar
./core/lib_managed/scala_2.8.0/test/junit-4.1.jar
./core/lib_managed/scala_2.8.0/test/objenesis-1.2.jar
./core/lib_managed/scala_2.8.0/test/scalatest-1.2.jar
./examples/lib_managed/scala_2.8.0/compile/jopt-simple-3.2.jar
./examples/lib_managed/scala_2.8.0/compile/log4j-1.2.15.jar
./kafka-0.7.0.jar
./lib/apache-rat-0.8-SNAPSHOT.jar
./lib/sbt-launch.jar
./project/boot/scala-2.7.7/lib/scala-compiler.jar
./project/boot/scala-2.7.7/lib/scala-library.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/classpath_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compile_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.7.7.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.0.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-bin_2.8.1.final/compiler-interface-bin-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/compiler-interface-src-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/compiler-interface-src/jline-0.9.94.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/control_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/io_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy-2.2.0.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/ivy_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/jsch-0.1.31.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/launcher-interface-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/sbt_2.7.7-0.7.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/test-interface-0.5.jar
./project/boot/scala-2.7.7/org.scala-tools.sbt/sbt/0.7.5/xsbti/interface-0.7.5.jar
./project/boot/scala-2.8.0/lib/scala-compiler.jar
./project/boot/scala-2.8.0/lib/scala-library.jar
./project/plugins/lib_managed/scala_2.7.7/sbt-idea-core_2.7.7-0.1-SNAPSHOT.jar
./project/plugins/lib_managed/scala_2.7.7/sbt-idea-plugin-0.1-SNAPSHOT.jar
Can someone help me?
Regards,
Alan
On Nov 3, 2011, at 11:55 AM, Jun Rao wrote:
> Hi, everyone,
>
> This will be our very first Apache release. I encourage everyone to try the
> RC out and vote on it. This will greatly help the Kafka community.
>
> Thanks,
>
> Jun
>
> ---------- Forwarded message ----------
> From: Neha Narkhede <ne...@gmail.com>
> Date: Mon, Oct 31, 2011 at 5:44 PM
> Subject: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
> To: kafka-users@incubator.apache.org
> Cc: kafka-dev@incubator.apache.org
>
>
> Hi,
>
> This is the fifth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
> those.
>
> It also fixes the following issues:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 3rd, 6 pm
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
Fwd: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Jun Rao <ju...@gmail.com>.
Hi, everyone,
This will be our very first Apache release. I encourage everyone to try the
RC out and vote on it. This will greatly help the Kafka community.
Thanks,
Jun
---------- Forwarded message ----------
From: Neha Narkhede <ne...@gmail.com>
Date: Mon, Oct 31, 2011 at 5:44 PM
Subject: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
To: kafka-users@incubator.apache.org
Cc: kafka-dev@incubator.apache.org
Hi,
This is the fifth candidate for the first incubator release for Apache
Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
those.
It also fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
*** Please download, test and vote by Nov 3rd, 6 pm
Note that we are voting upon the source (revision), binaries are
provided for convenience.
Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
The SVN revision to be voted upon:
https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS
Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before any release can be made official.
Thanks,
Neha
Fwd: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Jun Rao <ju...@gmail.com>.
Hi, everyone,
This will be our very first Apache release. I encourage everyone to try the
RC out and vote on it. This will greatly help the Kafka community.
Thanks,
Jun
---------- Forwarded message ----------
From: Neha Narkhede <ne...@gmail.com>
Date: Mon, Oct 31, 2011 at 5:44 PM
Subject: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
To: kafka-users@incubator.apache.org
Cc: kafka-dev@incubator.apache.org
Hi,
This is the fifth candidate for the first incubator release for Apache
Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
those.
It also fixes the following issues:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
*** Please download, test and vote by Nov 3rd, 6 pm
Note that we are voting upon the source (revision), binaries are
provided for convenience.
Source and binary files:
http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
The SVN revision to be voted upon:
https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
Kafka's KEYS file containing PGP keys we use to sign the release:
http://svn.apache.org/repos/asf/incubator/kafka/KEYS
Note that the Incubator PMC needs to vote upon the release after a
successful PPMC vote before any release can be made official.
Thanks,
Neha
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Neha Narkhede <ne...@gmail.com>.
>> I think this is due to sbt depending on scala 2.7.7. Will that go away with the sbt upgrade?
Yes.
As for the docs, we will update all docs once we pass the vote on the RC.
Thanks,
Neha
On Wed, Nov 2, 2011 at 12:52 PM, Jay Kreps <ja...@gmail.com> wrote:
> +1
>
> I don't think this is a blocker issue, but I would like to understand why
> our release tgz is so big (57M compressed, 66M uncompressed but core/source
> code is only 1M). One cause is that we seem to include both scala 2.7.7 and
> 2.8.0 which add 10M and 14M respectively. I think this is due to sbt
> depending on scala 2.7.7. Will that go away with the sbt upgrade?
>
> -Jay
>
> On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <ne...@gmail.com>wrote:
>
>> Hi,
>>
>> This is the fifth candidate for the first incubator release for Apache
>> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
>> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
>> those.
>>
>> It also fixes the following issues:
>>
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>>
>> *** Please download, test and vote by Nov 3rd, 6 pm
>>
>> Note that we are voting upon the source (revision), binaries are
>> provided for convenience.
>>
>> Source and binary files:
>> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>>
>> The SVN revision to be voted upon:
>> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>>
>> Note that the Incubator PMC needs to vote upon the release after a
>> successful PPMC vote before any release can be made official.
>>
>> Thanks,
>> Neha
>>
>
Re: [VOTE] Release Kafka 0.7.0-incubating (candidate 5)
Posted by Jay Kreps <ja...@gmail.com>.
+1
I don't think this is a blocker issue, but I would like to understand why
our release tgz is so big (57M compressed, 66M uncompressed but core/source
code is only 1M). One cause is that we seem to include both scala 2.7.7 and
2.8.0 which add 10M and 14M respectively. I think this is due to sbt
depending on scala 2.7.7. Will that go away with the sbt upgrade?
-Jay
On Mon, Oct 31, 2011 at 5:44 PM, Neha Narkhede <ne...@gmail.com>wrote:
> Hi,
>
> This is the fifth candidate for the first incubator release for Apache
> Kafka, version 0.7.0-incubating. There were 2 critical bugs found in
> RC4 - KAFKA-160 and KAFKA-161. This candidate is published to fix
> those.
>
> It also fixes the following issues:
>
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/RELEASE-NOTES.html
>
> *** Please download, test and vote by Nov 3rd, 6 pm
>
> Note that we are voting upon the source (revision), binaries are
> provided for convenience.
>
> Source and binary files:
> http://people.apache.org/~nehanarkhede/kafka-0.7.0-incubating-candidate-5/
>
> The SVN revision to be voted upon:
> https://svn.apache.org/repos/asf/incubator/kafka/branches/0.7@1195721
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> http://svn.apache.org/repos/asf/incubator/kafka/KEYS
>
> Note that the Incubator PMC needs to vote upon the release after a
> successful PPMC vote before any release can be made official.
>
> Thanks,
> Neha
>