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