Re: [Zookeeper-user] Moving to maven

[Alan D. C. <li...@to...>]

On Dec 9, 2007, at 11:03 PM, Andrew Kornev wrote:

> Alan,
>
> I=92m sure your points are all valid. But I=92m also sure there will =
be =20
> other folks who believe their XYZ project management system is the =20
> way to go and yet other folks who would just love to be able to use =20=

> good ol=92 Ant or Ant+Ivy or whatever.
>
> For example, for our in-house applications using zookeeper, we have =20=

> to use an exotic combination of Ant, Makefile, shell scripts and =20
> internal package management tools to build and deploy zookeeper =20
> distributions. And since the company also relies on its internal =20
> =93convention over configuration=94, a few extra building/staging/=20
> packaging steps are involved to accommodate the requirements. (By =20
> the way, lest you suspect us of being parochial or lazy, moving to =20
> Maven wouldn=92t make any difference to us in that respect J ).

Ha!  Yet another build system in Ant.  I see the above two paragraphs =20=

as more bullets to my arguments about how many different ways people =20
who use Ant can construct a build system.  Not one will be similar to =20=

another.  As I mentioned before, Ant is fine if you're delivering =20
standalone shrink wrapped applications.  Maven is great if your =20
sharing components and services to be incorporated into other open =20
source projects.  (I'm aware of Ant+Ivy and they do a great job trying =20=

to emulate Maven)

As I've mentioned before, I'm happy to drop this and simply agree to =20
disagree.

I'm certain that your decision to not move to Maven is not =20
capricious.  I'm sure you want your development team focusing on =20
solidifying ZooKeeper, not learning a new build system that doesn't =20
mesh with your home-made internal build system; I've sensed that this =20=

was the motivation from the beginning.  As a Maven zealot I'm almost =20
willing to bet that you have a junior staff member or college intern =20
tending to that home-made internal build system.  ;)

Again, no worries.  I'm happy hand upload the jars for other maven =20
users.  I think that we should put the maven repository in the =20
ZooKeeper web site.  WDYT?

>  Also, please correct me if I=92m wrong, Maven would be of no special =20=

> advantage over Ant with languages other than Java.

Maven can "build" other languages.  Not sure what you mean by special =20=

advantage.


Regards,
Alan

>
> Regards,
> Andrew
>
> From: zoo...@li... =
[mailto:zoo...@li...=20
> ] On Behalf Of Alan D. Cabrera
> Sent: Sunday, December 09, 2007 3:46 PM
> To: zoo...@li...
> Subject: Re: [Zookeeper-user] Moving to maven
>
>
> On Dec 9, 2007, at 1:56 AM, Flavio Junqueira wrote:
>
>
> Hi Alan, I think you have some valid points such as the one on new =20
> bindings and a separation into modules. And, I agree it would be =20
> useful to have our state-machine implementation separate in a way =20
> that other projects could re-use it.
>
> Although I like some of your points, I'm with the others. I don't =20
> see a strong reason for switching to Maven, and it seems to me that =20=

> your concerns are more with respect to the organization of the =20
> software than with the tool we are using. I'd rather stay with ant =20
> for now.
>
>
> I think I should have been more explicit as to why I listed my =20
> ideas.  I assumed, without thinking, that you already knew what =20
> their portents meant.  People will be forced to hand assemble their =20=

> servers and clients.  Before I go on to explain I want to make sure =20=

> you all know that I'm fine with Ant and will just hand upload the =20
> jars to my personal Maven repository for others to use.
>
> People will want to include Java or DotNet bindings in their =20
> services.  People can download the jars by hand and check them into =20=

> their ant build or use Maven for automatic inclusion.  Like I said =20
> above, I will hand upload the jars to my personal Maven repository =20
> for others to use.
>
> The PAXOS implementation will be another jar that others will use in =20=

> a like manner.  We will also need to use this internally as well.  =20
> Maven handles this quite cleanly.
>
> Finally, the configuration code.  The server will need to be =20
> assembled w/ different kinds of configuration mechanisms.  Sometimes =20=

> I will want to have a simple properties based server boot up for my =20=

> unit testing.  When I deploy I will want my server bundled w/ OSGi =20
> service and configuration code.  Others will want to wire in their =20
> own configuration code and will want to use specific version =20
> combinations of ZooKeeper code with their own company's code.  Maven =20=

> handles these assembly situations quite nicely.
>
> The objections that I hear seem to be from people who all work at =20
> the same company and are, probably, in the same group.  I imagine =20
> that things will be done a single way and and these assembly =20
> scenarios would not apply and so Ant seems good enough.  Others, I =20
> can guarantee, will be forced to go on, what I call, an Easter egg =20
> hunt to assemble the jar set to fulfill their needs.
>
> Sorry for the long winded post.  I'm happy to agree to disagree and =20=

> let it lie as it is.  Let's go on to some interesting bits!
>
> Regards,
> Alan
>
> =
-------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> =
http://sourceforge.net/services/buy/index.php_____________________________=
__________________
> Zookeeper-user mailing list
> Zoo...@li...
> https://lists.sourceforge.net/lists/listinfo/zookeeper-user