On 3/18/10 3:55 PM, Ron Wheeler wrote: > Wayne Fay wrote: >>> - unambiguous - no "you might do this or mayby that" just "if your >>> situation >>> is this and you want the best development environment do exactly this". >>> >> >> But notice some recent questions on the list... >> - how to compile from multiple source directories >> - migrating a large ant build to maven without any power to reorg the >> files/projects >> - etc >> >> It seems pretty rare that someone is looking for what you are >> proposing to create... >> >> > My suspicion is that these are caused by not following the "Best > Practice" for Maven. > Under what circumstance would you recommend to a user that they set up a > project that required 2 source directories? > In the end, I suspect that they really have 2 (or more) projects with 1 > source directory each with dependencies between them. > Once they "Mavenize" their project structure, they will find that they > do not need these gymnastics. But in neither of these cases was the question "should I be doing this?" It was "I need to do this. Tell me how do I do it."
> Migration is always tough and may be one of the last "Best Practices" to > emerge. > Your suggestion, if I recall correctly was to not try to Mavenize in the > face of an entrenched Ant lobby until you had established a high level > buy-in. That in itself could be the root of a "Best Practice" that is > less about Maven technical issues and more about how to plan and > organize a large scale methodology upgrade and how to justify the > investment to management and the rest of the team. Except that Wayne's wrong about this :) Management buy-in doesn't mean shit. > The fact that a number of people are not looking for the right things is > due to a certain extent to the power and flexibility of Maven and the > lack of a set of "Best Practices". I don't agree that this is what's going on here. > Maven is one of those tools that really needs a warning note "Just > because Maven can do it, does not mean that you should do it." Seriously? > How many Maven project structures and development methodologies are > radically different but equally recommended can you come up with for a > small team of less than 5 developers that are developing a webapp in > Java with Spring on Eclipse or Netbeans for deployment on Tomcat, > Glassfish or Websphere? > > How difficult would it be to get a consensus on which one of your > suggestions is the "best". > > How hard would it be to get agreement on what is the criteria for "best". > > Just for a starting point, in my opinion, the best practice for the > above situation would suggest that the project needs a subversion > repository, a Nexus community version repository, the Spring STS version > of Eclipse, a master POM for the project, a set of library POMs for the > shared code and utilities, and a single project POM to build the WAR > file. Lots of details to flesh out but they would fit on 1 page with a > few pages of POMs, settings and misc. xml samples attached. But IMHO you should be using Git instead of Subversion and STS doesn't have enough management tools to support a large-scale rollout. Are we actually going to be able to reach consensus on those things? In all seriousness, you should publish this as "Ron's Best Practices". If you put something up on Lulu or whatever, I would read it and I would probably recommend it to others. There isn't enough documentation about Maven; I just don't think the community can produce the type of documentation you're describing. Justin > How many variants would that "Best Practice" need to satisfy 90% of the > target use cases. > > > Ron > > >>>> PS- Who is producing and assuming ongoing responsibility for this BPG? >>>> >>> The community. >>> >> >> Sounds like the Maven User Wiki is a fine place to start. I started >> the document [1] for "the community" to add/edit as it deems useful. >> >> [1] http://docs.codehaus.org/display/MAVENUSER/Maven+Best+Practice+Guide >> >> Wayne >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
