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