On 19 December 2011 14:16, Antonio Petrelli <antonio.petre...@gmail.com> wrote: > 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
I thought I had, but could not find it so created http://jira.codehaus.org/browse/MRELEASE-721 > 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°. Not necessarily, some CIs build on each change. If there is a network glitch after the first commit, there would be a potentially large time window for problems to occur. AFAIK the temporary change to the version is not the only change that is made to trunk. > Antonio --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
