On Sun, May 1, 2011 at 5:54 PM, Michael MacFadden <[email protected]> wrote: > All, > > Let's start a new thread focused on planning out what a possible move to > maven would look like. I know it's easy to dive in to the code and just > start playing around, but if not done right, we are going to get a lot of > push back from others on moving to maven. We need to plan this out and > identify exactly what we intend to do, who is going to do it, how were are > going to do it, and when it will be done. The discussion of this should > happen on the mailling list, and the results of the discussion should be > captured in the development wiki (which I can set up). > > > The following questionnaire should help us get going. I realize that some of > this discussion has already taken place. I would suggest simply answering > the questions for yourself in this thread. If we need to discuss a > particular question lets start a separate thread for each question. I don't > want to distract people from filling out the "survey". Thanks. > > > ~Michael > > > Questions:
My answers shouldn't be given much weight in the poll results, due to my very-specific use case (for now), but here they are, 'cause I think they'll still be helpful. > 1) > What is the objective (just provide maven jars to a repo? fully mavenize the > project? etc)? Having artifacts in a repo is what I'm looking for in the short term. If they're not going to be deployed regularly (at each CI build, or nightly, or even weekly), it's a moot point. I'd be fine with, at a minimum, having a pom.xml file for each built JAR so it's easier to deploy them on local/enterprise repositories; this has almost nothing to do with "bringing maven into wave" though. I don't have a strong opinion on mavenizing the project, even though it would have obvious benefits (incremental build of dependencies, building only the required dependencies for the one artifact you're interested in: for instance, the rich text editor only requires 5 out of the 17 JARs produced by "ant dist-libraries"). Incremental build would probably benefit CI builds too, only launching large tests if one of their dependencies have changed (coarse grain, at the module level, but still): and it's just a checkbox in Jenkins. > 2) > What are the benefits of what we are proposing? Why should we move to maven? See above: dependency-aware build (build everything that depends on X and Y modules; and/or build X and everything it depends on). I currently need/want the rich text editor for a project (nothing protocol-related, just the editor, and probably the toolbar widget). It looks like I need the client.jar, client-common.jar, client-scheduler.jar, common.jar and model.jar (and their *-src.jar for GWT). If I want to use the EditorHarness, I also need the media.jar (for the thumbnails doodad, which is only installed in the harness) and util.jar (for the "escapers"). These JARs have dependencies on third-party JARS guava and jsr305 only (actually, maybe jsr305 is a transitive dependency of guava, and not used directly by Wave). I found those dependencies "by hand" (after days of reading the code, and starting to know which classes the editor depends on, and which package they live in); and having them expressed in POMs would have saved me a few minutes (and would save a few *hours* to a newcomer!) > 3) > Who is really committed to work on this? Not me. > 4) > hat is the general approach for adding maven support (just writing poms? > moving source around? etc)? "just having poms" would be enough for me (and I could even live without it, as I'm going to deploy the current JARs in our Artifactory repo). I'm not knowledgeable enough re. Maven to write those poms (I'll only write the absolute minimum necessary so that dependency resolution for my app works) Note that I'm only talking about POMs for deploying the JARs as Maven artifacts, not about replacing Ant with Maven. I'd be OK with Nelson's proposed workflow to start by switching only the build system (without moving the source around and using similar include/exclude rules as the current Ant scripts), but that must be only temporary. There's no compelling reason IMO to switch to Maven if it's not to "embrace it" and follow the "standard project layout": people knowing Maven will find it weird, and newbies will be lost, and people not knowing Maven will have a hard time understanding how to build the project (and maintain the "build files"). > 5) > How will the development cycle of the developers who are not working on this > be impacted? GWT development doesn't fit nicely into Maven, it's lacking a new kind of packaging/project-type. Particularly, working with several "client side" modules can be a PITA. For instance, m2eclipse do not resolve source artifacts from the eclipse workspace, which makes the GWT DevMode fail at finding the source code. You have to manually add the folders to your launcher classpath, and that's "fragile" as it breaks as soon as you start open/closing your projects in your workspace. Or you can switch off workspace dependency resolution but then you have to install the artifact and restart your DevMode each time you change a file in a dependency. DevMode startup time is going to improve in the upcoming GWT releases (notably 2.4 –fyi, 2.3 should become GA for Google I/O I guess, so 2.4 should only come in a few months–) and you could argue that you should unit-test your code as much as possible before testing in DevMode, but still, it's IMO a non-negligible cost; particularly for people not used to GWT and/or Maven (I know what I'm talking about, my team didn't know GWT and Maven at all a year ago –I didn't know Maven either, to tell the truth–). > 6) > What are our deliverables? Other than the mavenized project, do we need to > provide documentation or tutorials to show others how to work with the new > system? > > 7) > What are the various modules we would propose having and what is the purpose > of each (simply stating that we stick with the current jars is not enough > info)? Given my use case, as long as the GWT code (particularly org.waveprotocol.wave.client.*) is available as an artifact (and not only compiled to JS in the WiaB WAR), it's fine by me. > 8) > What group ids / artifact ids should we use? > > > 9) > What are the timelines and milestones? > > > -- Thomas Broyer /tɔ.ma.bʁwa.je/
