tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Move to Maven? (WAS: Re: Publishing process for JARs for Maven Central)
Date Mon, 19 Dec 2011 13:57:58 GMT
On 19 December 2011 08:36, Antonio Petrelli <antonio.petrelli@gmail.com> wrote:
> 2011/12/17 Mark Thomas <markt@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message