ZooKeeper Roadmap - 3.1.0 and beyond.

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

ZooKeeper Roadmap - 3.1.0 and beyond.

Patrick Hunt
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
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Hiram Chirino
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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Hiram Chirino
Anyone out there?

On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Jake Thompson-2
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 <[hidden email]>wrote:

> Anyone out there?
>
> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Patrick Hunt
In reply to this post by Hiram Chirino
Hi Hiram, afaik there is currently no interest (esp. among the
contributors I've talked with) to switch from ant to maven. For the time
being we are sticking with whatever Hadoop Core uses wrt
build/release/etc... I know I've personally (in my role as release
manager) gained a lot of benefit by "cloning" the Core process, scripts,
documentation,  etc...

Regards,

Patrick

Hiram Chirino wrote:

> Anyone out there?
>
> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]> 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 <[hidden email]> 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
>>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Adam Rosien
If someone could deploy a build to a public maven repository it would
really help zk client development and adoption when integrating with
external maven-ized projects, since adding such a dependency is
trivial in maven.

.. Adam

On Wed, Nov 5, 2008 at 12:28 PM, Patrick Hunt <[hidden email]> wrote:

> Hi Hiram, afaik there is currently no interest (esp. among the contributors
> I've talked with) to switch from ant to maven. For the time being we are
> sticking with whatever Hadoop Core uses wrt build/release/etc... I know I've
> personally (in my role as release manager) gained a lot of benefit by
> "cloning" the Core process, scripts, documentation,  etc...
>
> Regards,
>
> Patrick
>
> Hiram Chirino wrote:
>>
>> Anyone out there?
>>
>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>> 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 <[hidden email]> 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
>>>
>>
>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Patrick Hunt
Apache Ivy has also been looked at, I believe Hadoop Core is considering
Ivy for dependency management:

https://issues.apache.org/jira/browse/HADOOP-3305
http://ant.apache.org/ivy/

Patrick

Adam Rosien wrote:

> If someone could deploy a build to a public maven repository it would
> really help zk client development and adoption when integrating with
> external maven-ized projects, since adding such a dependency is
> trivial in maven.
>
> .. Adam
>
> On Wed, Nov 5, 2008 at 12:28 PM, Patrick Hunt <[hidden email]> wrote:
>> Hi Hiram, afaik there is currently no interest (esp. among the contributors
>> I've talked with) to switch from ant to maven. For the time being we are
>> sticking with whatever Hadoop Core uses wrt build/release/etc... I know I've
>> personally (in my role as release manager) gained a lot of benefit by
>> "cloning" the Core process, scripts, documentation,  etc...
>>
>> Regards,
>>
>> Patrick
>>
>> Hiram Chirino wrote:
>>> Anyone out there?
>>>
>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>> 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 <[hidden email]> 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
>>>>
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Hiram Chirino
In reply to this post by Jake Thompson-2
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 <[hidden email]> 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 <[hidden email]>wrote:
>
>> Anyone out there?
>>
>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Jake Thompson-2
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 <[hidden email]>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 <[hidden email]>
> 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 <[hidden email]
> >wrote:
> >
> >> Anyone out there?
> >>
> >> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
> >> 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 <[hidden email]>
> 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
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Robert Newson
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 <[hidden email]> 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 <[hidden email]>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 <[hidden email]>
>> 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 <[hidden email]
>> >wrote:
>> >
>> >> Anyone out there?
>> >>
>> >> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>> >> 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 <[hidden email]>
>> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Hiram Chirino
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>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 <[hidden email]>
>>> 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 <[hidden email]
>>> >wrote:
>>> >
>>> >> Anyone out there?
>>> >>
>>> >> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>> >> 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 <[hidden email]>
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Fernando Padilla-4
In reply to this post by Jake Thompson-2
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 <[hidden email]>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 <[hidden email]>
>> 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 <[hidden email]
>>> wrote:
>>>
>>>> Anyone out there?
>>>>
>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>>> 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 <[hidden email]>
>> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Patrick Hunt
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.

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
>> <[hidden email]>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 <[hidden email]>
>>> 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 <[hidden email]
>>>> wrote:
>>>>
>>>>> Anyone out there?
>>>>>
>>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>>>> 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 <[hidden email]>
>>> 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
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Patrick Hunt
In reply to this post by Robert Newson
Robert Newson wrote:
> 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.

Any idea what it takes to do this? I noticed that Ivy just pushed a new
v2 release candidate to apache-announce, is that necessary (ivy) or will
straight ant work? From the ZK release management perspective how much
additional work is required?
http://ant.apache.org/ivy/download.cgi

Patrick

>
> On Wed, Nov 5, 2008 at 10:00 PM, Jake Thompson <[hidden email]> 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 <[hidden email]>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 <[hidden email]>
>>> 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 <[hidden email]
>>>> wrote:
>>>>
>>>>> Anyone out there?
>>>>>
>>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>>>> 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 <[hidden email]>
>>> 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
>>>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Robert Newson
Lucene's top-level build.xml has this;

 <target name="generate-maven-artifacts"
depends="maven.ant.tasks-check, package, jar-src, jar-demo-src,
javadocs">
    <sequential>
      <m2-deploy pom.xml="lucene-parent-pom.xml.template"/>
      <m2-deploy pom.xml="lucene-core-pom.xml.template">
        <artifact-attachments>
          <attach file="${build.dir}/${final.name}-src.jar"
                  classifier="sources"/>
          <attach file="${build.dir}/${final.name}-javadoc.jar"
                  classifier="javadoc"/>
        </artifact-attachments>
      </m2-deploy>

     <more follows>
   </target>

lucene-core-pom.xml.template is this;

<project>
  <parent>
    <groupId>org.apache.lucene</groupId>
    <artifactId>lucene-parent</artifactId>
    <version>@version@</version>
  </parent>
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.apache.lucene</groupId>
  <artifactId>lucene-core</artifactId>
  <name>Lucene Core</name>
  <version>@version@</version>
  <description>Apache Lucene Java Core</description>
  <packaging>jar</packaging>
</project>

The maven extension to Ant is pulled in with;

<project xmlns:artifact="antlib:org.apache.maven.artifact.ant">

availability is tested with;

 <available
    property="maven.ant.tasks.present"
    classname="org.apache.maven.artifact.ant.Pom"
  />

and the entire m2-deploy macro is;

  <macrodef name="m2-deploy" description="Builds a Maven artifact">
        <element name="artifact-attachments" optional="yes"/>
    <attribute name="pom.xml" default="${pom.xml}"/>
    <sequential>
      <copy file="@{pom.xml}" tofile="${build.dir}/@{pom.xml}">
        <filterset begintoken="@" endtoken="@">
          <filter token="version" value="${version}"/>
        </filterset>
      </copy>
          <artifact:install-provider artifactId="wagon-ssh"
version="1.0-beta-2"/>

      <artifact:pom id="maven.project" file="${build.dir}/@{pom.xml}" />
      <artifact:deploy file="${build.dir}/${maven.project.build.finalName}.jar">
        <artifact-attachments/>
        <remoteRepository url="${m2.repository.url}">
          <authentication username="${m2.repository.username}"
privateKey="${m2.repository.private.key}"/>
                </remoteRepository>
        <pom refid="maven.project"/>
      </artifact:deploy>
    </sequential>
  </macrodef>

So, you can put Maven shaped artifacts side by side with build.xml and
generate the appropriate artifacts. After that, it's just a question
of getting upload permission to the main repository.

B.

On Thu, Nov 6, 2008 at 2:47 AM, Patrick Hunt <[hidden email]> wrote:

> Robert Newson wrote:
>>
>> 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.
>
> Any idea what it takes to do this? I noticed that Ivy just pushed a new v2
> release candidate to apache-announce, is that necessary (ivy) or will
> straight ant work? From the ZK release management perspective how much
> additional work is required?
> http://ant.apache.org/ivy/download.cgi
>
> Patrick
>
>>
>> On Wed, Nov 5, 2008 at 10:00 PM, Jake Thompson <[hidden email]>
>> 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
>>> <[hidden email]>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 <[hidden email]>
>>>> 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 <[hidden email]
>>>>> wrote:
>>>>>
>>>>>> Anyone out there?
>>>>>>
>>>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>>>>> 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 <[hidden email]>
>>>>
>>>> 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
>>>>
>
Reply | Threaded
Open this post in threaded view
|

RE: Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Benjamin Reed-2
In reply to this post by Patrick Hunt
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:[hidden email]]
Sent: Wednesday, November 05, 2008 09:37 PM Pacific Standard Time
To: [hidden email]
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 <[hidden email]>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 <[hidden email]>
>> 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 <[hidden email]
>>> wrote:
>>>
>>>> Anyone out there?
>>>>
>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>>> 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 <[hidden email]>
>> 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Patrick Hunt
Last I checked with Hadoop core team they had reservations about pushing
the artifacts to the maven repo. (FYI for new members of this list - we
had an extensive discussion of Maven/Ivy/etc... on the ZK lists a couple
of months ago, you can see background in both JIRA and the nabble
archive. In the end the decision was made to stay with Ant.)

Here is the Hadoop JIRA I was pointed to last time I looked into this.
It looks like Hiram has addressed some issues, but no progress yet in
the core team (not sure why, perhaps Owen or Doug could comment):

https://issues.apache.org/jira/browse/HADOOP-3302?focusedCommentId=12591953#action_12591953

Patrick

Benjamin Reed wrote:

> 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:[hidden email]]
> Sent: Wednesday, November 05, 2008 09:37 PM Pacific Standard Time
> To: [hidden email]
> 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 <[hidden email]>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 <[hidden email]>
>>> 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 <[hidden email]
>>>> wrote:
>>>>
>>>>> Anyone out there?
>>>>>
>>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>>>> 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 <[hidden email]>
>>> 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
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: ZooKeeper Roadmap - 3.1.0 and beyond.

Hiram Chirino
In reply to this post by Patrick Hunt
On Thu, Nov 6, 2008 at 2:42 AM, Patrick Hunt <[hidden email]> 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
>>> <[hidden email]>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 <[hidden email]>
>>>> 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 <[hidden email]
>>>>> wrote:
>>>>>
>>>>>> Anyone out there?
>>>>>>
>>>>>> On Mon, Nov 3, 2008 at 9:23 AM, Hiram Chirino <[hidden email]>
>>>>>> 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 <[hidden email]>
>>>>
>>>> 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