2011/12/19 sebb <seb...@gmail.com> > 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. >
You are right, please open a JIRA issue for this, for example a solution would be to change the version inside the tag. I believe that this operation is done this way for backwards compatibility with CVS. However you must admit that the time taken for this operation is small (commit, tag, commit again). You must be *very unlucky°. Antonio
