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
