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 <[email protected]> > 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 <[email protected]> > > > 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 <[email protected]> > > > > > >> 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< > > >>> [email protected]> 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 > > >>>>> <[email protected]> έγραψε: > > >>>>> > > >>>>>> 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
