I forgot to mention that geronimo has been re-releasing several versions of tomcat built with maven. We have a script to set up a maven multi module project structure and distribute the tomcat source code from tomcat svn into the maven projects. This stuff is under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype with e.g an example of what you get from the script under https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-7.0.19
thanks david jencks On Dec 17, 2011, at 1:12 PM, David Jencks wrote: > I'll try to keep it short because I really don't want to spend time > re-beating this dead horse. > > The last time I looked a couple years ago the jars constructed out of the > single source tree could not be compiled separately in any order. I was told > this wasn't a problem, at which point I realized discussion was useless. > > Maven prevents problems like this through the project structure. If this > situation is not a problem to the tomcat community, then the other possible > benefits of using maven are not likely to be interesting either. > > thanks > david jencks > > On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote: > >> On 17/12/2011 20:24, Antonio Petrelli wrote: >>> Ok, let's do it again :-D >>> 1. Standardization. Maven strongly encourages to use a standardized >>> structure. The source should go into src/main/java, the resources in >>> src/main/resources etc. You can change it, but this is discouraged. With >>> Ant you always do things differently for different projects. >> >> What benefit is this to the Tomcat community? I see a change, but no >> benefit. >> >>> 2. Modularization. Separation between modules is strong, i.e. one jar-one >>> source directory. In the case of Tomcat, there is a big big trouble: one >>> single big source directory. Separating them will be one of the most >>> important step to do. >> >> Why is that an issue? Switching to a single source tree was one of the >> best changes we ever made. It has been much easier to manage than the >> multiple source trees we had in the past. The dependencies are known and >> we have checks in place (via Checkstyle) to ensure that unwanted >> dependencies are not added. Again, what is the benefit here to the >> Tomcat community? There has been some interest but very little activity >> towards greater modularity. If there was more interest in increasing >> modularity then there might be a case for this but given Tomcat's remit >> of implementing the Servlet and JSP specs there is very little that >> could be made modular / optional. Jasper and EL are already optional >> (well, they can be removed) and pretty much everything else is required >> by the Servlet spec. >> >>> 3. Metadata-driven process. The build process is driven by metadata (where >>> the source is? where should I deploy it?) and not by commands (compile the >>> source that is in that point, deploy it in that repository) >> >> Again, how does this benefit the Tomcat community? >> >>> 4. POMs are (almost) universal. Projects of the same kind have almost the >>> same content.. >> >> How does this benefit the Tomcat community? >> >>> 5. Plug-ins do generically what pieces of Ant's script do specifically. For >>> example take the Maven assembly plugin: via a descriptor you obtain a zip >>> file to distribute. >> >> That sounds like just a different way of doing things. What is the benefit? >> >>> 6. When all the metadata is in place, the release process is a matter of >>> launching: >>> mvn release:prepare >>> and >>> mvn release:perform >> >> Right now the release process is: >> ant release >> followed by scp / ftp / 'take your pick' the files to the right place >> and that could be added to the script if we really wanted to (but no-one >> has felt the need to scratch that itch). >> >> In summary, I see a lot of differences but no benefits. Changing to >> Maven would mean big changes along with some disruption. For the >> community to make those changes and accept that disruption there needs >> to be something in return. So far, I haven't seen anything that I would >> class as a benefit to the community (e.g. faster build process, simpler >> releases, fewer bugs, etc.). >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
