Like I said, ant works fine. And yes you can hack up your ant build to push bits to maven repos. But like I said before, there is lots more to maven than just that.
On Wed, Nov 5, 2008 at 10:10 PM, Robert Newson <[EMAIL PROTECTED]> wrote: > The Zookeeper development team should use whatever build system works > for them, Ant is a good option (Ant+Ivy looks quite compelling, > though). > > However, for those of us, myself included, that do use Maven, could > Maven artifacts be deployed to the main repository as part of the > release cycle? That is the binary jar, source jar and javadoc jar? > It's not necessary to use Maven to do so (though it is easier); the > Lucene team push releases and they 'still' use Ant. > > B. > > On Wed, Nov 5, 2008 at 10:00 PM, Jake Thompson <[EMAIL PROTECTED]> 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
