On 10/17/07, Mark Thomas <[EMAIL PROTECTED]> wrote: > Paul Shemansky wrote: > > Key features that may be useful to us are : > > > > - The Standard Directory Layout - Specifically, multi-module builds. > > This might make managing individual components easier for catalina, > > coyote, naming, jsp/servlet api/implementation, connector, etc. > > "might" isn't a compelling argument.
I agree that "might" is too passive. However, by saying "will", I immediately seem aggressive, paint myself into a corner, prepare for a Maven vs. Ant flame war, and wind up with no choice but to shoot myself in the face :) It "would" make things easier if each of the components were being managed by separate, designated groups of developers. I am now aware that this is not the case for Tomcat, but I am still motivated to promote 'slight' layout modifications which may make any potential new developers feel right at home the day they sign on : _________________________________ Hello Mark, our project uses this layout : http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html _________________________________ Of course, if that is not appealing to anyone, we could just create documentation on how the current version is structured, leaving nothing to the imagination. If the Maven layout is shot down, I would still be willing to help with writing more extensive documentation of Tomcat's directory structure and build process. Before I attempt to contribute any real code, I feel it is vital to become heavily aware of the build. > > - Model-Based builds - Automatic packaging for the individual modules. > > Our build script does this. I didn't say that it didn't. The current build process is not flawed; It works very well. This was only to state that "if" we decided to modularize, packaging would be a more automated feature which is wrapped in the definition (pom.xml) of each module, rather than being intertwined into a single large sequential build file. > > > - Dependency Management - Whether it is Apache or another third-party, > > dependencies can all easily be plugged in. > > There are only a few and they are easily managed with the current > build process. Again, this is not an attack against the current build process. Ant is not my enemy. I am simply proposing that Maven can provide improvements over how dependencies are managed, now and in the future. Perhaps as Filip mentioned, Ivy will accommodate all of the dependency management via Ant. I was simply stating that dependency management is built into Maven, along with a few other features which IMHO 'may' be nice for the Tomcat build. As a new programmer to Tomcat, I feel it would have been nice to see a dependency list or report 'before' I actually built the project, without having to read too much into the build.xml. Dependencies are also currently downloaded into a project-defined directory. This is opposed to simply being declared in the build as dependencies and managed in a local Maven repository which houses dependencies in a clearly defined, unified directory layout. In a perfect world, we would not need to store more than one copy of any of the Commons JAR files on our machines. IMHO, I think that Maven 2 does in fact help to promote this. I am still exploring the current Tomcat build, and again, I apologize for not being here long enough to know every single thing about the dependencies involved. Filip cleared up my initial dependency (DBCP) issue (thanks again). But, can anyone tell me why we are downloading the tomcat-native zip file from the archive url when it seems that it is already part of the initial Tomcat check-out under the "native" directory? Is this a dependency, or part of the project already? > > > - Distribution Management - Packaging and Deployment - Although Tomcat > > has a structured distribution model with Ant, Maven could make this > > easier with its assembly plugin. This also allows outside entities to > > easily embed specific Tomcat components or customize the server to > > suit their needs, (i.e. containers like Geronimo and JBoss, IDE > > plugins for Eclipse or Tomcat.) > > Easier how? Filip, mentioned that he added the poms to the project so that the individual dependencies may be publicly distributed into the main Maven repository. This, if maintained, can allow any outside vendor to quickly download all of the latest 'required' components of Tomcat into their own Maven (or Ant w/ Maven Tasks ;) build process. They could easily wrap anything they want around the web container simply by including Tomcat as a dependency. This can be attractive, especially from a software consulting perspective, in which I may want to have a web application with an easily-accessible-via-build, "embedded" version of Tomcat. I believe Jetty actually accomplishes this, but I like Tomcat better, and this is why I am here. :) Instead of having to visit and re-download the binary distributions, a consultant may be able to just add : <dependency> <groupId>org.apache.tomcat</groupId> <artifactId>tomcat-server</artifactId> <version>6.0.14</version> </dependency> Then, essentially, the Tomcat installation process can become a part of the customer application's build process. The build process could incorporate the server, and automatically deploy with the resulting application (java myProjectWhichContainsTomcat.jar). I think this may be nice to have in some cases, but hey I am only one guy. :) > > - Project Site and Report Generation. - The Tomcat documentation site > > may benefit greatly, but the Maven reporting plugins seem to be the > > bigger win here. > > "May" isn't compelling. What reporting? What do we get that we want to > get don't currently? Again, "may" is passive, and I used it for that reason alone. The site generation phase of the build process would be centrally managed from the pom.xml, and this would automatically wrap up some of the basic (DOAP) project information currently maintained elsewhere (i.e. SVN info, javadocs, mailing lists, issue tracking info, etc.). After that you would also be able to have test results, code coverage reports, PMD code reviews, documentation-checking reports, todo lists generated from commented source code. We also open the door for the ability to build (and/or receive) any reporting plugins that we (or the user community) think Tomcat should be responsible for (i.e. site statistics, downloads, users / supporters, etc., possibly even automated benchmarking results or comparisons to other containers.). All of this reporting would be immediately available on the Tomcat project's site. Although these are not filled with as much data as I would like, these are examples of what Maven can generate : Project Info : http://maven.apache.org/plugins/maven-doap-plugin/project-info.html Project Reports http://maven.apache.org/plugins/maven-doap-plugin/project-reports.html When generated, I would immediately know that out of the 898 dev-list subscribers, the actual team-list like the one found at http://maven.apache.org/team-list.html is much shorter. This would show who is 'actively' developing Tomcat, eliminating lurkers, and providing relevant information about these members. Provided I don't aggravate too many of you with this Maven 2 "gobbledy-gook", I'd like to some day make it to that list, too. :) > > Whether you vote Yes or No, I am still happy to be working > > with you. :) > > Overall -1. I just don't see the point. The current process is nice > and simple and works. If it ain't broke... > > Mark I know it's not broke, otherwise I wouldn't be using Tomcat as much as I do. But, I proposed this merely to find out if there is room for improvement, though. Ant and Maven can co-exist using the best features of both....can we all just get along? :) More importantly... can I assimilate you into a "+1, but only if ____ happens" vote, instead? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
