Hi Anthony. We have a contrib in the current release, it's under src.
I'm not sure I understand, what is contrib section referring to? Or do
you mean client recipe implementations? (like ZOOKEEPER-78, which is
being worked on for 3.2)
Patrick
Anthony Urso wrote:
So does this mean no contrib
i'm ready to reevaluate it. i did the contrib for fatjar and it was
extremely painful! (and that was an extremely simple contrib!) we really
want to ramp up the contribs and get a bunch of recipe implementations
in, so we need something that makes it really easy. i'm not a fan of
maven (they
Ben, you might want to look at buildr, it recently graduated from the
apache incubator:
http://buildr.apache.org/
Buildr is a build system for Java applications. We wanted something
that’s simple and intuitive to use, so we only need to tell it what to
do, and it takes care of the rest. But
just to be clear: i'm not a maven fan, but i'm not sure anything else is
better. buildr looks better flexibility wise, but i think maven is much
more popular and mature. with ivy we are still stuck with ant build files.
ben
Patrick Hunt wrote:
Ben, you might want to look at buildr, it
Speaking of the contrib section, what is the status of ZOOKEEPER-103?
Is it ready to be reevaluated now that 3.0 is out?
Cheers,
Anthony
On Fri, Jan 9, 2009 at 11:58 AM, Mahadev Konar maha...@yahoo-inc.com wrote:
Hi Kevin,
It would be great to have such high level interfaces. It could be
So far we've stayed with the process used by core as this minimizes the
amount of work we need to do re process/build/release, etc... we just
copy the process/build/release etc... used in core, we get all that for
free. I'm hesitant to diverge as this will increase the amount of work
we need
So does this mean no contrib section?
On Thu, Feb 26, 2009 at 10:00 PM, Patrick Hunt ph...@apache.org wrote:
So far we've stayed with the process used by core as this minimizes the
amount of work we need to do re process/build/release, etc... we just copy
the process/build/release etc... used
OK so it sounds from the group that there are still reasons to provide
rope in ZK to enable algorithms like leader election.
Couldn't ZK ship higher level interfaces for leader election, mutexes,
semapores, queues, barriers, etc instead of pushing this on developers?
Then the remaining APIs,
Well if that were the direction, goal, I'd feel more comfortable about
recommending ZK..
If a company were to implement some of these algorithms then I suspect
they'd run into a race condition, etc with all that rope.
For my part I'd be willing to contribute the NodeWatcher/NodeListener I
