On 19/12/2011 08:36, Antonio Petrelli wrote: > 2011/12/17 Mark Thomas <ma...@apache.org> > >> 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. >> > > So standardization is no benefit? Do you mean that an external developer, > that sees a common project structure that can start working on it easily, > is not a benefit?
I agree that being able to start working on something easily is a benefit. Where we disagree is how important standardisation and Maven helps. Maven may add standardisation but it also adds complexity. Too much happens under the hood for my liking. You need a much better understanding of the tool to figure out what is going on. I think that makes it harder to get started than the current Ant script. I suspect we just aren't going to agree on this since one's view will change depending on how well one understands Mavem. You understand it very well. I understand it hardly at all. >>> 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. > > > Sincerely, this is the worst thing that you have made. Do you think that > having a single source tree and letting Ant script reconstruct in some > non-obvious way the jars, is a benefit? A single source tree has been a huge benefit. The code is much easier to work with. I'm happy to pay the price of the way the JARs are created to be able to work with a single source tree. >> The dependencies are known and >> we have checks in place (via Checkstyle) to ensure that unwanted >> dependencies are not added. > > Checkstyle checks unwanted *imports* not dependencies. Agreed, but they are equivalent as makes no difference when talking about dependencies between the JARs (as I was). >> 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. >> > > Real modularity means: one source directory -> one jar. In other cases, it > is not obvious. Again, what is the benefit? >>> 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? >> > > The benefit is that the pom.xml is similar to other projects. After you see > a kind of project, you see almost them all. As above, similar but in my view more complex. I suspect how comfortable you are with Maven determines which you think is best and not everyone has your level of skill with Maven. >>> 4. POMs are (almost) universal. Projects of the same kind have almost the >>> same content.. >> >> How does this benefit the Tomcat community? >> > > See above. Ditto. >>> 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? >> > > You don't need to maintain a build script, but only use a plugin. Most of > the time, it's just the matter of including it. My view of the Commons experience is that it often is not that simple, particularly when plug-ins are updated. >>> 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). >> > > Does "ant release" tag automatically and prepare for the next snapshot? No. But it could easily if we wanted to. Personally, again based on what I have seen in Commons, I'd rather keep the manual control. A lot of my views of Maven have been coloured by what I have seen Commons components go through. The Maven release process seems to be fraught with problems. When compared to the current Tomcat 7 release process (at least prior to the switch to Nexus - I have yet to experience that so I don't know what it will be like) the Ant based process we use for Tomcat seems to be far less hassle, far simpler to execute and far less prone to going wrong. >> 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.). >> > > You see features where I see benefits of the features, asking the same > question again and again shows your hate, and probably you hate me too, > because I love Maven. Hate is a very strong, emotive word. I'd urge you to tone down your language on this point. > No problem, you'll lose at some point :-D This isn't about individuals winning and losing. It is about what is best for the Tomcat community. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
