On 17/12/2011 21:12, 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.
I just did a check with JarAnalyzer and we still have circular dependency issues with catalina.jar, catalina-ha.jar and catalina-tribes.jar I haven't looked in the archives for the previous discussion and I can't remember what my views were then - probably completely opposite to now :). I wouldn't class it as a problem (I am happy to live with this) but I'm happy to take a look to see if there is an easy fix and apply the fix in that case. > 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. The dependencies we really care about are monitored via Checkstyle. If I fix the above issue, I'll add some additional checks so we don't recreate the issue. Mark > > 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
