(Sorry I sent unfinished version in the previous email) 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 plan how to proceed. - Accountability - there should be someone responsible with some record of "merit" 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 >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>> >> >>>> >> >>> >> >>
