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 14:46:04 GMT
On 19 December 2011 14:16, Antonio Petrelli <antonio.petrelli@gmail.com> wrote:
> 2011/12/19 sebb <sebbaz@gmail.com>
>
>> 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.
>>
>
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message