hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Reed" <br...@yahoo-inc.com>
Subject RE: Re: ZooKeeper Roadmap - 3.1.0 and beyond.
Date Thu, 06 Nov 2008 13:47:41 GMT
Speaking for myself, I like the idea (alot!) of feeding into the maven repository. But I don't
see us moving to maven for builds until hadoop does. Ivy sounds great to me. I believe that
is what hadoop is planning to do.

Ben

 -----Original Message-----
From: 	Fernando Padilla [mailto:fern@alum.mit.edu]
Sent:	Wednesday, November 05, 2008 09:37 PM Pacific Standard Time
To:	zookeeper-user@hadoop.apache.org
Subject:	Re: ZooKeeper Roadmap - 3.1.0 and beyond.

I will summarize my vote by echoing what Jake said:

"So while I would say it is never a bad decision to move to maven, it 
isn't always a needed decision."

Though Maven hasn't won over everyone yet builds, the idea of a central 
Maven Repository for dependency distribution and management has proven 
itself and is a very solid and very useful system.  So in the end of 
day, use Maven or Ant+Ivy, or whatever, but I vote that you have to 
support the central Maven Repository appropriately.

So it sounds like we're in agreement ( at lease the few in this 
discussion ).  But have we heard from the actual developers?  What are 
their preferences or plans?  Or would they like patches?




Jake Thompson wrote:
> Hi Hiram,
> I actually am just a user of zookeeper, I am not a "member" as of yet.  I am
> also a user of maven and ant and have been using both for many years.
> 
> So while I would say it is never a bad decision to move to maven, it isn't
> always a needed decision.
> 
> A standard build structure makes sense if you were building zookeeper
> yourself, but I don't beleive you would be doing that.  So that leaves the
> creation and building of your own projects like an ear, war, JBI, etc.  The
> problem with zookeeper is that there is no required project structure.
> There is no zar that is to say.
> 
> I personally have a mavenized war project that I am using zookeeper in and I
> also have a hand rolled CL java program that uses it and is build with ant.
> For both of these I just needed to copy one jar into my lib.
> As far as dependency management, since zookeeper is so simple the only
> requirement is log4j, not really needing any complex dependency tools there.
> 
> As far as modularity, again I see zookeeper being part of larger modules, so
> I don't know if we can draw a common modular zookeeper application
> structure.
> 
> Maven is a great tool and can help alot, but I personally don't see it as
> synonymous with modern java development.
> 
> -Jake
> On Wed, Nov 5, 2008 at 9:28 PM, Hiram Chirino <hiram@hiramchirino.com>wrote:
> 
>> It would help new developers work with your project.  Maven provides a
>> a broad set of tools that lots of java developers have come to expect
>> out of a build system.  Incorporating those tools manually into an Ant
>> based build would be very time consuming and make the build complex to
>> maintain.
>>
>> For example, in addition the standard build and package aspects of
>> build, folks expect the build system to:
>> - support generating the IDE integration files (Idea, eclipse, etc.).
>> - Run static analysis tools like find bugs
>> - Run test coverage reports
>> - Deployment to central servers
>> - License Checking
>> - Artifact signing
>>
>> And most importantly, they want a standard way of doing all that.
>>
>> Maven also encourages modularity in the architecture by making it easy
>> build multiple modules/jar files and easily describing the
>> dependencies between then.  And once you go modular, you will see how
>> folks start contributing alternative implementations of existing
>> modules.  Copying a module and it's build setup is easy to do with
>> maven..  A bit harder with something like ant since it's kinda
>> monolithic.
>>
>> Ant was a great tool so if you guys want to stick to your guns that's
>> cool.  But in this day and age, using a ant based open source project
>> is kinda like it was when we used make several years back to build
>> java projects.  Works fine, but dated.
>>
>>
>>
>> On Wed, Nov 5, 2008 at 1:11 PM, Jake Thompson <jake@jakethompson.com>
>> wrote:
>>> It is quiet around here, I am new, could you please explain why you feel
>> a
>>> Maven build structure is needed?
>>>
>>> Thanks,
>>> Jake
>>>
>>>
>>>
>>> On Wed, Nov 5, 2008 at 1:05 PM, Hiram Chirino <hiram@hiramchirino.com
>>> wrote:
>>>
>>>> Anyone out there?
>>>>
>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <hiram@hiramchirino.com>
>>>> wrote:
>>>>> Congrats on the release.  Now that has been completed, I'd like to see
>>>>> if you guys are willing to revisit the issue of a maven based build.
>>>>> If yes, I'd be happy to assist making that happen.
>>>>>
>>>>> Regards,
>>>>> Hiram
>>>>>
>>>>> On Mon, Oct 27, 2008 at 10:35 PM, Patrick Hunt <phunt@apache.org>
>> wrote:
>>>>>> Our first official Apache release has shipped and I'm already looking
>>>>>> forward to 3.1.0. ;-)
>>>>>>
>>>>>> In particular I believe we should look at the following for 3.1.0:
>>>>>>
>>>>>> 1) there are a number of issues that we're targeted to 3.1.0 during
>> the
>>>>>> 3.0.0 cycle. We need to review and address these.
>>>>>>
>>>>>> 2) system test. During 3.0.0 we made significant improvements to
our
>>>> test
>>>>>> environment. However we still lack a large(r) scale system test
>>>> environment.
>>>>>> It would be great if we could simulate large scale use over 10s or
>> 100s
>>>> of
>>>>>> machines (ensemble + clients). We need some sort of framework for
>> this,
>>>> and
>>>>>> of course tests.
>>>>>>
>>>>>> 3) operations documentation. In general docs were greatly improved
in
>>>> 3.x
>>>>>> over 2.x. One area we are still lacking is operations docs for
>>>>>> design/management of a ZK cluster.
>>>>>> see https://issues.apache.org/jira/browse/ZOOKEEPER-160
>>>>>>
>>>>>> 4) JMX. Documentation needs to be written & the code
>> reviewed/improved.
>>>>>> Moving to Java6 should (afaik) allow us to take advantage of improved
>>>> JMX
>>>>>> spec not available in 5. We should also consider making JMX the
>> default
>>>>>> rather than optional (ie you get JMX by default when ZK server is
>>>> started).
>>>>>> We need to ensure that ops can monitor/admin ZK using JMX.
>>>>>>
>>>>>> 5) (begin) multi-tenancy support. A number of users have expressed
>>>> interest
>>>>>> in being able to deploy ZK as a service in a cloud. Multi-tenancy
>>>> support
>>>>>> would be a huge benefit (quota, qos, namespace partitioning of nodes,
>>>>>> billing, etc...)
>>>>>>
>>>>>> Of course ZooKeeper is open to submissions in that aren't on this
>> list.
>>>> If
>>>>>> you have any suggestions please feel free to enter a JIRA or submit
a
>>>> patch.
>>>>>>
>>>>>> Additionally I'd like to see us move to an 8 week release cycle.
I've
>>>>>> updated the JIRA version list to reflect this. Due to the holiday
>> season
>>>>>> approaching I've listed 3.1.0 with a ship date of Jan 19th. (see
the
>>>> roadmap
>>>>>> on the JIRA).
>>>>>>
>>>>>> If you have any questions/comments please reply to this email.
>>>>>>
>>>>>> Patrick
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Hiram
>>>>>
>>>>> Blog: http://hiramchirino.com
>>>>>
>>>>> Open Source SOA
>>>>> http://open.iona.com
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Hiram
>>>>
>>>> Blog: http://hiramchirino.com
>>>>
>>>> Open Source SOA
>>>> http://open.iona.com
>>>>
>>
>>
>> --
>>  Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>>
> 

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