On 19 December 2011 08:36, Antonio Petrelli <antonio.petre...@gmail.com> 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? > > >> > 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? > > >> 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. > > >> 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. > > >> >> > 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. > > >> >> > 4. POMs are (almost) universal. Projects of the same kind have almost the >> > same content.. >> >> How does this benefit the Tomcat community? >> > > See above. > > >> > 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. > > >> > 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?
AIUI, the Maven release plugin temporarily changes the trunk SVN to drop the -SNAPSHOT suffix, merely in order to create the new tag. This means that concurrent builds (e.g. in a CI) may pick up what appears to be a release version, when in fact it is not. For me, that is broken (and unsafe) behaviour, as it requires additional measures to perform it safely. > >> 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. > No problem, you'll lose at some point :-D > > Antonio > >> >> 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
