Hi guys, I am inclined to agree with Yuri and STenyaK (forgive me I'm not sure what your first name is). Right now what this project needs most is some real momentum in terms of features and stability, and major refactorings of the code base merely to change build system seem like far too big a risk. I think any effort to port to maven would be much better spent on directly addressing the one or two most annoying pain points, such as making the build or unit tests run more incrementally, or exporting maven targets (so other projects that use maven can depend on our code). I am confident someone could get that fixed with a few hours work or less. Other benefits listed are far less concrete and don't seem worth the risk to me right now. I have no doubt that when we have a cool product, people will jump on board regardless of what build system we are using - it would be a bad sign for our project if it is the build system that is what attracts/repels contributors.
Regarding maven itself (I'll try to be brief-ish until I collect my thoughts further): From what I can tell, reading people's opinions here and on the internet at large, there are two broad reasons why people seem to like maven. (1) it automates fetching dependencies, which is an annoying task to do manually. (2) it is an improvement over "normal" ant monolithic builds, by breaking applications down into modules and forbidding circular dependencies. Regarding (1), I can see how this can improve a lot of things, but I can also see how it adds more points of failure for a build setup. So it's not quite a dead-clear win. Regarding (2), I am a big fan, and you'll notice that we've tried hard to do that in the client code with fine-grained GWT module dependencies. Internally at Google, our build system encourages/enforces this. In both these examples, the module breakdown is fine-grained (often on the package-level), and this really makes sure you don't screw up, and helps keep code highly decoupled. Also, doing this is very lightweight - all you need is a small file that declares the deps. If you have a section of your code base that is well written with good dependency injection, adding these module declarations is a snap - it requires no code change or refactorings. The problem I see with maven is that modules seem to be quite heavy weight, and harder to split/join/move around. Please correct me if I'm wrong, but it seems that each module requires its own separate source tree, with a deep set of top level directory and other "boilerplate" - or, alternatively, fighting maven to maintain some other directory structure (but the consensus on the internet is that you don't fight maven unless you're a masochist). Full disclaimer: I have only used maven a little, and done a bunch of reading. But please don't discount my opinion on those grounds. Also, I hate ant, don't get me wrong. I do not in any way intend to start a "maven is awesome" vs "maven sucks" religious war here. My opinions above regarding maven are tentative, and I would love to revisit them. I provided them partly to play the devil's advocate, and partly to justify why I feel it's not a clear win to migrate, and so probably not worth the risk to the project's momentum until we are healthily going full steam ahead. At that point it'd be great to revisit this question and learn more about maven. I think ultimately whatever pleases the majority of the active contributors is best. Dan Στις 29 Απριλίου 2011 3:10 π.μ., ο χρήστης STenyaK <sten...@gmail.com> έγραψε: > In the end, long term plans have to take into account the consequences of > trying to future-proof the project: If focusing on long-term future during > 2011 makes wave lose (or "not increase") the precious momentum it has thanks > to inertia of googlers and other interested parties, then maybe it is > actually *not* such a good long-term plan. > > Just to put things in perspective: the project has blindly migrated from git > to svn, and accepted not to dog-feed itself, but is now considering changing > a (afaik) perfectly working build system, which will disrupt development for > an unknown period of time. Also, time is being wasted in this > bike-shed-color discussion (ehm, sorry for contributing to it O:-). > > IMO continuing with ant for a few more weeks/months is probably going to be > better in the *actual* long term. > > 2011/4/28 Yuri Z <vega...@gmail.com> > >> Michael >> I hate to be the devil's advocate, but I ll take the role this time. >> First of all, you are right of course - all decisions should be wighted on >> the base of effort vs. gain and after analysis of the risks. >> Also, the analysis should build on the past relevant experiences. So let's >> try to understand what happened with the move to Apache (sorry if I kick a >> sacred cow). I think that the move to Apache is positive development, but >> much ahead of the time. >> At the time I advocated to postpone the move because: "There are no >> immediate gains for the Wave in a Box project, but the prices are >> immediate". I mentioned that we should first >> >> - To focus on attaining the goals outlined in the WIAB roadmap >> - Use of Apache mailing list instead of dog food WIAB instance is a very >> heavy price. >> - The move will take too much effort that instead can be devoted to >> development of core WIAB features. >> >> I was told then that: >> >> - The move will possibly attract an influx of commiters - didn't happen. >> - It will be probably possible communicated with Apache so allow us to >> use dog food instance instead - didn't happen >> - The move to Apache infra can be done in parallel and won't affect >> ongoing development efforts - not quite true. >> >> And it is clear that giving up on dog food instance - is a really heavy >> price. Off course, the move could take only a few hours or days, but in >> reality it taken 4 months and counting. >> So I think the lessons that we should learn: >> >> - Focus on the main product, do things only when necessary and not ahead >> of time to gain possible value. >> - Don't assume that problems can be solved later, either have a clean >> >> >> 2011/4/28 Michael MacFadden <michael.macfad...@gmail.com> >> >> > Yuri, >> > >> > I don't think we can view it as to high a price right now vs later. The >> > fact of the matter is that if we push it off to some later date when we >> will >> > have "free time" to take on something like this, it will honestly never >> get >> > done. Plus we haven't quantified how much effort it would take. What if >> it >> > could get done in a few hours? Would it be worth it then? What about a >> few >> > days? I think the benefits are pretty clear, but we need to quantify how >> > much work it would take to get it done. >> > >> > Only then can we decide if it's worth it. One plug for doing it now >> rather >> > than after a "1.0" would be I imaging that a 1.0 release would be ready >> for >> > a lot more wide spread use. If you imagine that you could see a lot more >> > people downloading and using WiaB after 1.0. At that point we will be >> > getting a lot more attention and enhancement and bug requests. We might >> > even get an influx of committers. At that point it would be almost >> > impossible to justify a code freeze for a few days to switch to maven. >> > >> > In my view we are almost in a now or never type of scenario. >> > >> > ~Michael >> > >> > >> > On Apr 28, 2011, at 12:09 AM, Yuri Z wrote: >> > >> > > IMHO code freeze price is too high for now. Maybe after we release ver >> > 1.0 >> > > then ver 1.1 can be about moving to maven. >> > > >> > > 2011/4/28 Eric Charles <eric.char...@u-mangate.com> >> > > >> > >> Hi, >> > >> >> > >> I've been paid for 6 months by one of my client to migrate numerous >> > project >> > >> from ant to maven. Some were trivial, other were really complicated >> due >> > to >> > >> legacy technologies,... and needed code refactoring. >> > >> >> > >> At the end, the result we got much more manageable/testable/deployable >> > >> components based applications. >> > >> >> > >> I don't know wave code, but I bet maven compared to ivy will drive to >> a >> > >> better code base, even if the prices may be high (work, freeze,...). >> > >> >> > >> Tks, >> > >> - Eric >> > >> >> > >> >> > >> On 28/04/2011 06:34, Rohit Rai wrote: >> > >> >> > >>> +1 for migrating to maven >> > >>> >> > >>> Though I share the concern raised by Michael, "it is not going to be >> > easy" >> > >>> (have experience in earlier changing from monolithic ant builds to >> > modular >> > >>> maven builds...) and it will disrupt the development temporarily. >> > >>> >> > >>> But as mentioned in the mails above, we should think on these line - >> > >>> >> > >>> 1. Maven being the accepted build standard on date, will make it easy >> > for >> > >>> new developers to start with WIAB. >> > >>> 2. Developers can pick a module and focus on working with it rather >> > than >> > >>> spending time trying to understand the current project format and >> > >>> figuring >> > >>> out what goes where. >> > >>> 3. It will make it easy for developers to integrate WIAB components >> > >>> individually and also to embed WIAB in there applications. >> > >>> 4. IDE integration is very helpful to start of quickly >> > >>> >> > >>> At this point when Google is removing people from this project, I >> think >> > it >> > >>> makes sense for us to make it easy for any newbie coming to get >> started >> > on >> > >>> it, the more the merrier! >> > >>> >> > >>> And if we don't do it now, >> > >>> 1. that we are transferring it from Google Code to Apache (when we >> can >> > >>> have >> > >>> a scheduled downtime for a couple of days) >> > >>> 2. the code base is manageable size >> > >>> 3. the contributors are limited in number >> > >>> >> > >>> We may never have an better opportunity and it is going to be "much >> > more >> > >>> difficult" once the codebase and number of committers grow! >> > >>> >> > >>> Just my 2 cents from past experiences . . . >> > >>> >> > >>> And to back up my words, I will be all willing to spare couple of >> days, >> > >>> taking leave from my day job and weekend along if required to assist >> > with >> > >>> the migration to maven. >> > >>> >> > >>> Note: If we have to move to maven, we should first list out what will >> > be >> > >>> the >> > >>> modules and then what part of code goes into which module. This will >> > speed >> > >>> up the actual transition process. >> > >>> >> > >>> Regards, >> > >>> Rohit >> > >>> >> > >>> The diamond cannot be polished without friction, nor man perfected >> > without >> > >>> trials >> > >>> http://mytechrantings.blogspot.com >> > >>> >> > >>> >> > >>> On Thu, Apr 28, 2011 at 8:52 AM, Michael MacFadden< >> > >>> michael.macfad...@gmail.com> wrote: >> > >>> >> > >>> All, >> > >>>> >> > >>>> I am not sold on maven at this point. Don't get me wrong I am a >> > strong >> > >>>> advocate of Maven, and although it has its issues, I think it can be >> a >> > >>>> big >> > >>>> benefit to a project. I am just not sold that it is worth the >> effort >> > at >> > >>>> the >> > >>>> moment. That being said here are a couple ways which maven could >> help >> > >>>> the >> > >>>> wave in a box project: >> > >>>> >> > >>>> Modularization >> > >>>> >> > >>>> Maven encourages the construction of distinct modules for a project. >> > As >> > >>>> the wave project grows, we will likely want to build a set of >> reusable >> > >>>> components that other projects could use. For example we may have >> > >>>> concurrency control stacks, protocol stacks, interface components, >> etc >> > >>>> that >> > >>>> other projects might want to take advantage of. We have already >> > gotten >> > >>>> request to use the editor, and we know people are interested in >> > building >> > >>>> new >> > >>>> UI's leveraging the client server protocol. With maven, the project >> > can >> > >>>> easily be organized such that these modules are reference-able and >> > usable >> > >>>> by >> > >>>> others. Things like the Robot and Gadget API are obvious examples. >> > >>>> >> > >>>> This could be done without maven, but maven makes this the norm >> rather >> > >>>> than >> > >>>> the exception. >> > >>>> >> > >>>> >> > >>>> Build Time >> > >>>> >> > >>>> Right now we have a pretty monolithic build. When I change >> anything, >> > I >> > >>>> have to rebuild the whole project. With maven it's fairly easy to >> go >> > in >> > >>>> to >> > >>>> the sub module you are working on and make "local" changes there. >> You >> > >>>> can >> > >>>> rebuild and deploy easily without having to do a whole build. Of >> > course >> > >>>> you >> > >>>> can run a full build if you like. >> > >>>> >> > >>>> >> > >>>> Testing >> > >>>> >> > >>>> Right now we have an issue with testing. The unit tests are also >> > >>>> monolithic. Originally, they all run or they all didn't. >> > Unfortunately, >> > >>>> it >> > >>>> took too long to run all of them, so we now have a somewhat >> arbitrary >> > >>>> distinction between long running and short running tests. Only the >> > short >> > >>>> ones run by default. >> > >>>> >> > >>>> With maven, unit tests are scoped to the module which they test. If >> > we >> > >>>> had >> > >>>> a Robot API module, we would have tests in that module that just >> unit >> > >>>> test >> > >>>> the Robot API. If you are working on the Robot API, you can make >> > changes >> > >>>> and easily just run the Robot API unit tests. You can actually work >> > on >> > >>>> the >> > >>>> sub module, make changes, test and check in code, without having to >> > run >> > >>>> ALL >> > >>>> the unit tests for the whole project, assuming the tests are >> > >>>> comprehensive >> > >>>> for the module. The job of running all the tests can be the job of >> > the >> > >>>> integration build. >> > >>>> >> > >>>> >> > >>>> Standardization >> > >>>> >> > >>>> When I was ramping up on wave, it took me over a month to become >> fully >> > >>>> comfortable with the nested ant scripts and how the project >> ultimately >> > >>>> built >> > >>>> itself. As ant projects try to become more modular, the complexity >> of >> > >>>> their >> > >>>> build scripts goes exponentially up. Furthermore, each project does >> > it >> > >>>> differently. You have to study the build to figure it out. With >> > maven, >> > >>>> its >> > >>>> all pretty standard. Any developer experienced in maven can check >> out >> > >>>> your >> > >>>> project, rigure out the module layout and how to build any specific >> > >>>> module >> > >>>> they need within minutes. >> > >>>> >> > >>>> >> > >>>> Other Random Things >> > >>>> >> > >>>> Great IDE integration. >> > >>>> Dependency management. >> > >>>> A standard mechanism to deploy our artifacts for other projects to >> > use. >> > >>>> Lot's of reports that can be generated about dependancies, tests, >> etc. >> > >>>> Integration with SVN and standard mechanism to perform releases, >> > tagging >> > >>>> and branches. >> > >>>> >> > >>>> >> > >>>> In my opinion maven would help us: >> > >>>> >> > >>>> Organize the project better. >> > >>>> Make our codebase more testable. >> > >>>> Shorten our development and test cycles. >> > >>>> Make our project more accessible to new developers. >> > >>>> Make our project more reusable for others. >> > >>>> >> > >>>> >> > >>>> All of that said... it's not going to be easy to switch over, so I >> > don't >> > >>>> take the decision lightly. >> > >>>> >> > >>>> ~Michael >> > >>>> >> > >>>> >> > >>>> On Apr 27, 2011, at 7:31 PM, Daniel Danilatos wrote: >> > >>>> >> > >>>> It seems the real problem here is the large amount of jars checked >> > >>>>> into the repository. What about something that just does dependency >> > >>>>> management, for example apache ivy? >> > >>>>> >> > >>>>> Does maven solve any other problems we have that make it worth >> going >> > >>>>> all the way with it? I'm worried it could cause as much trouble as >> it >> > >>>>> solves. I'm not fundamentally against it but I'd like to be >> confident >> > >>>>> there are solid reasons/benefits to the waveprotocol project for >> > >>>>> migrating to maven. >> > >>>>> >> > >>>>> My 2c. >> > >>>>> >> > >>>>> Dan >> > >>>>> >> > >>>>> Στις 27 Απριλίου 2011 7:51 π.μ., ο χρήστης Michael MacFadden >> > >>>>> <michael.macfad...@gmail.com> έγραψε: >> > >>>>> >> > >>>>>> Nelson, >> > >>>>>> >> > >>>>>> I am all for this. I am very experienced with Maven and the >> proper >> > >>>>>> ways >> > >>>>>> >> > >>>>> to set up multi module projects including dependency management, >> etc. >> > I >> > >>>> think your assessment of the situation is correct. We would >> > ultimately >> > >>>> need >> > >>>> a code free to get this done. >> > >>>> >> > >>>>> >> > >>>>>> However, before you go to far, I would try to get a real >> discussion >> > >>>>>> >> > >>>>> going on if this is something the team wants to do. If so we need >> to >> > >>>> discuss what the right modules are, what artifact and group ids we >> > would >> > >>>> want, etc. I would hate to see you set up a lot of poms.xml that >> > don't >> > >>>> line >> > >>>> up with how we would ultimately do things. >> > >>>> >> > >>>>> >> > >>>>>> As a side note, if we did want to go to maven, now would be the >> > right >> > >>>>>> >> > >>>>> time. Everything else has to be migrated anyway, might as well >> take >> > the >> > >>>> hit >> > >>>> now. However, I would recommend that we get the current source >> > migrated >> > >>>> over first. >> > >>>> >> > >>>>> >> > >>>>>> ~Michael >> > >>>>>> >> > >>>>>> >> > >>>>>> On Apr 26, 2011, at 10:12 AM, Nelson Silva wrote: >> > >>>>>> >> > >>>>>> Hi all, >> > >>>>>>> >> > >>>>>>> There have been several discussions on adding maven as a build >> > tool. >> > >>>>>>> >> > >>>>>>> I've decided to start working on this by adding a tools/maven >> > >>>>>>> >> > >>>>>> subdirectory with a multimodule project layout. >> > >>>> >> > >>>>> I pushed my ongoing work to a branch in my GitHub clone : >> > >>>>>>> >> > >>>>>>> >> > https://github.com/nelsonsilva/wave-protocol/tree/maven/tools/maven >> > >>>>>>> >> > >>>>>>> While a complete port to maven as the main build tool would >> > required a >> > >>>>>>> >> > >>>>>> code freeze and a healthy discussion of code reorganization into >> > proper >> > >>>> modules we should be able to use a simple includes/excludes approach >> > for >> > >>>> now >> > >>>> and in the end, if everyone is ok with it, we could easily make the >> > port >> > >>>> happen. >> > >>>> >> > >>>>> >> > >>>>>>> I would like to get some help with this from everyone who's >> > >>>>>>> interested. >> > >>>>>>> >> > >>>>>> There are lots of plugins and lots of ways to acomplish things in >> > maven >> > >>>> so >> > >>>> this should get the discussion started. >> > >>>> >> > >>>>> >> > >>>>>>> I chose to go with GitHub so everyone can fork it and send me >> pull >> > >>>>>>> >> > >>>>>> requests. If you'd rather go with the issue/patchset approach I'll >> > open >> > >>>> the >> > >>>> issue but the idea here was to have several people contribute and >> not >> > a >> > >>>> single patch + review process. >> > >>>> >> > >>>>> >> > >>>>>>> Quickstart: >> > >>>>>>> >> > >>>>>>> cd tools/maven >> > >>>>>>> ./install_deps.sh # This will install a couple of dependencies >> that >> > >>>>>>> >> > >>>>>> were either patched or were not found in existing maven repos >> > >>>> >> > >>>>> mvn install >> > >>>>>>> cd server >> > >>>>>>> ln -s ../../../war >> > >>>>>>> mvn exec:java # This should start the server, although you'll >> have >> > to >> > >>>>>>> >> > >>>>>> symlink the war directory for now >> > >>>> >> > >>>>> >> > >>>>>>> TO DO: >> > >>>>>>> >> > >>>>>>> - Use profiles for dev/prod >> > >>>>>>> - Remove as many ant tasks as possible and use pure maven plugins >> > >>>>>>> - Use the assembly plugin to package the server with the >> webclient >> > >>>>>>> - Setup the surefire tests for each module >> > >>>>>>> - Rethink the modules, we should have pure api modules and the >> > several >> > >>>>>>> >> > >>>>>> impl modules for persistence, websockets, auth, etc ... >> > >>>> >> > >>>>> - etc.... >> > >>>>>>> >> > >>>>>>> Looking forward to getting this going... >> > >>>>>>> >> > >>>>>>> Regards, >> > >>>>>>> >> > >>>>>>> Nelson Silva >> > >>>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>> >> > >>>> >> > >>> >> > >> > >> > > > > -- > Saludos, > Bruno González > > _______________________________________________ > Jabber: stenyak AT gmail.com > http://www.stenyak.com >
