atom feed78 messages in org.apache.tomcat.devRe: Move to Maven? (WAS: Re: Publishi...
FromSent OnAttachments
Antonio PetrelliDec 17, 2011 12:24 pm 
Mark ThomasDec 17, 2011 12:47 pm 
David JencksDec 17, 2011 1:11 pm 
Mark ThomasDec 17, 2011 1:58 pm 
Mark ThomasDec 17, 2011 2:52 pm 
David JencksDec 17, 2011 4:05 pm 
Mladen TurkDec 18, 2011 12:37 am 
Antonio PetrelliDec 19, 2011 12:27 am 
Antonio PetrelliDec 19, 2011 12:36 am 
Henri GomezDec 19, 2011 1:41 am 
sebbDec 19, 2011 5:57 am 
Antonio PetrelliDec 19, 2011 6:16 am 
Caldarale, Charles RDec 19, 2011 6:40 am 
sebbDec 19, 2011 6:45 am 
Olivier LamyDec 19, 2011 6:56 am 
Antonio PetrelliDec 19, 2011 6:57 am 
ia...@darwinsys.comDec 19, 2011 8:15 am 
PidDec 19, 2011 9:11 am 
Mladen TurkDec 19, 2011 9:25 am 
Henri GomezDec 19, 2011 10:04 am 
Mladen TurkDec 19, 2011 10:20 am 
David JencksDec 19, 2011 10:47 am 
Mark ThomasDec 19, 2011 11:23 am 
Mark ThomasDec 19, 2011 11:44 am 
Romain Manni-BucauDec 19, 2011 11:51 am 
Mladen TurkDec 19, 2011 11:53 am 
Henri GomezDec 19, 2011 11:56 am 
Romain Manni-BucauDec 19, 2011 11:58 am 
Mark ThomasDec 19, 2011 11:59 am 
Mladen TurkDec 19, 2011 12:08 pm 
Romain Manni-BucauDec 19, 2011 12:12 pm 
Mladen TurkDec 19, 2011 12:25 pm 
jean-frederic clereDec 19, 2011 1:06 pm 
Romain Manni-BucauDec 19, 2011 2:07 pm 
David JencksDec 19, 2011 7:20 pm 
Mladen TurkDec 19, 2011 10:56 pm 
mar...@apache.orgDec 19, 2011 11:31 pm 
David JencksDec 19, 2011 11:58 pm 
Romain Manni-BucauDec 20, 2011 12:00 am 
Antonio PetrelliDec 20, 2011 12:17 am 
Antonio PetrelliDec 20, 2011 12:18 am 
jean-frederic clereDec 20, 2011 12:21 am 
jean-frederic clereDec 20, 2011 12:22 am 
Antonio PetrelliDec 20, 2011 12:26 am 
Antonio PetrelliDec 20, 2011 12:38 am 
Olivier LamyDec 20, 2011 1:04 am 
Konstantin KolinkoDec 20, 2011 1:44 am 
Antonio PetrelliDec 20, 2011 1:54 am 
Mark ThomasDec 20, 2011 2:10 am 
Antonio PetrelliDec 20, 2011 2:13 am 
Mark ThomasDec 20, 2011 3:22 am 
Mark ThomasDec 20, 2011 3:32 am 
Mark ThomasDec 20, 2011 3:34 am 
Antonio PetrelliDec 20, 2011 3:40 am 
Antonio PetrelliDec 20, 2011 3:52 am 
PidDec 20, 2011 4:39 am 
Romain Manni-BucauDec 20, 2011 4:52 am 
Sylvain LaurentDec 20, 2011 2:20 pm 
Sylvain LaurentDec 20, 2011 2:21 pm 
Leon RosenbergDec 21, 2011 12:52 am 
Olivier LamyDec 21, 2011 12:34 pm 
Jean-Baptiste OnofréDec 21, 2011 12:37 pm 
Mladen TurkDec 21, 2011 1:21 pm 
Mark ThomasDec 21, 2011 1:23 pm 
Mladen TurkDec 21, 2011 1:56 pm 
Mark ThomasDec 21, 2011 2:00 pm 
Mladen TurkDec 21, 2011 2:18 pm 
Mark ThomasDec 21, 2011 2:34 pm 
Olivier LamyDec 22, 2011 5:24 am 
Olivier LamyDec 22, 2011 5:48 am 
Christopher SchultzDec 22, 2011 7:14 am 
Olivier LamyDec 23, 2011 12:51 am 
Mark ThomasDec 23, 2011 3:41 am 
Olivier LamyDec 23, 2011 4:58 am 
Mark ThomasDec 23, 2011 5:19 am 
Olivier LamyDec 23, 2011 7:13 am 
Mark ThomasDec 23, 2011 7:58 am 
Jean-Baptiste OnofréDec 27, 2011 8:12 am 
Subject:Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
From:Antonio Petrelli (anto@gmail.com)
Date:Dec 19, 2011 6:16:06 am
List:org.apache.tomcat.dev

2011/12/19 sebb <seb@gmail.com>

On 19 December 2011 08:36, Antonio Petrelli <anto@gmail.com> wrote:

2011/12/17 Mark Thomas <mar@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