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 >>>>>> >>>>> >>>>> >>>>> >>> >>> >>
