On Thu, Nov 6, 2008 at 2:42 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote: > Fernando Padilla wrote: >> >> 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? > > As I stated earlier in this thread we're planning to stay with ant for many > reasons, but in particular; 1) current build process works, 2) current build > is based on how hadoop projects in general (core for example) is currently > doing builds. By using the same process/toolset we have many benefits - in > particular being able to essentially "clone" the core release process, > saving us much time/effort.
There are ate least 4 Apache Top Level Projects that use maven for releases. So you could copy any their release processes if that's is holding you back. > > Patrick > >> >> 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 >>> <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> >>>> 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 <[EMAIL PROTECTED] >>>>> wrote: >>>>> >>>>>> Anyone out there? >>>>>> >>>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[EMAIL PROTECTED]> >>>>>> 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 <[EMAIL PROTECTED]> >>>> >>>> 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 >>>> >>> > -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
