|Antonio Petrelli||Dec 17, 2011 12:24 pm|
|Mark Thomas||Dec 17, 2011 12:47 pm|
|David Jencks||Dec 17, 2011 1:11 pm|
|Mark Thomas||Dec 17, 2011 1:58 pm|
|Mark Thomas||Dec 17, 2011 2:52 pm|
|David Jencks||Dec 17, 2011 4:05 pm|
|Mladen Turk||Dec 18, 2011 12:37 am|
|Antonio Petrelli||Dec 19, 2011 12:27 am|
|Antonio Petrelli||Dec 19, 2011 12:36 am|
|Henri Gomez||Dec 19, 2011 1:41 am|
|sebb||Dec 19, 2011 5:57 am|
|Antonio Petrelli||Dec 19, 2011 6:16 am|
|Caldarale, Charles R||Dec 19, 2011 6:40 am|
|sebb||Dec 19, 2011 6:45 am|
|Olivier Lamy||Dec 19, 2011 6:56 am|
|Antonio Petrelli||Dec 19, 2011 6:57 am|
|ia...@darwinsys.com||Dec 19, 2011 8:15 am|
|Pid||Dec 19, 2011 9:11 am|
|Mladen Turk||Dec 19, 2011 9:25 am|
|Henri Gomez||Dec 19, 2011 10:04 am|
|Mladen Turk||Dec 19, 2011 10:20 am|
|David Jencks||Dec 19, 2011 10:47 am|
|Mark Thomas||Dec 19, 2011 11:23 am|
|Mark Thomas||Dec 19, 2011 11:44 am|
|Romain Manni-Bucau||Dec 19, 2011 11:51 am|
|Mladen Turk||Dec 19, 2011 11:53 am|
|Henri Gomez||Dec 19, 2011 11:56 am|
|Romain Manni-Bucau||Dec 19, 2011 11:58 am|
|Mark Thomas||Dec 19, 2011 11:59 am|
|Mladen Turk||Dec 19, 2011 12:08 pm|
|Romain Manni-Bucau||Dec 19, 2011 12:12 pm|
|Mladen Turk||Dec 19, 2011 12:25 pm|
|jean-frederic clere||Dec 19, 2011 1:06 pm|
|Romain Manni-Bucau||Dec 19, 2011 2:07 pm|
|David Jencks||Dec 19, 2011 7:20 pm|
|Mladen Turk||Dec 19, 2011 10:56 pm|
|mar...@apache.org||Dec 19, 2011 11:31 pm|
|David Jencks||Dec 19, 2011 11:58 pm|
|Romain Manni-Bucau||Dec 20, 2011 12:00 am|
|Antonio Petrelli||Dec 20, 2011 12:17 am|
|Antonio Petrelli||Dec 20, 2011 12:18 am|
|jean-frederic clere||Dec 20, 2011 12:21 am|
|jean-frederic clere||Dec 20, 2011 12:22 am|
|Antonio Petrelli||Dec 20, 2011 12:26 am|
|Antonio Petrelli||Dec 20, 2011 12:38 am|
|Olivier Lamy||Dec 20, 2011 1:04 am|
|Konstantin Kolinko||Dec 20, 2011 1:44 am|
|Antonio Petrelli||Dec 20, 2011 1:54 am|
|Mark Thomas||Dec 20, 2011 2:10 am|
|Antonio Petrelli||Dec 20, 2011 2:13 am|
|Mark Thomas||Dec 20, 2011 3:22 am|
|Mark Thomas||Dec 20, 2011 3:32 am|
|Mark Thomas||Dec 20, 2011 3:34 am|
|Antonio Petrelli||Dec 20, 2011 3:40 am|
|Antonio Petrelli||Dec 20, 2011 3:52 am|
|Pid||Dec 20, 2011 4:39 am|
|Romain Manni-Bucau||Dec 20, 2011 4:52 am|
|Sylvain Laurent||Dec 20, 2011 2:20 pm|
|Sylvain Laurent||Dec 20, 2011 2:21 pm|
|Leon Rosenberg||Dec 21, 2011 12:52 am|
|Olivier Lamy||Dec 21, 2011 12:34 pm|
|Jean-Baptiste Onofré||Dec 21, 2011 12:37 pm|
|Mladen Turk||Dec 21, 2011 1:21 pm|
|Mark Thomas||Dec 21, 2011 1:23 pm|
|Mladen Turk||Dec 21, 2011 1:56 pm|
|Mark Thomas||Dec 21, 2011 2:00 pm|
|Mladen Turk||Dec 21, 2011 2:18 pm|
|Mark Thomas||Dec 21, 2011 2:34 pm|
|Olivier Lamy||Dec 22, 2011 5:24 am|
|Olivier Lamy||Dec 22, 2011 5:48 am|
|Christopher Schultz||Dec 22, 2011 7:14 am|
|Olivier Lamy||Dec 23, 2011 12:51 am|
|Mark Thomas||Dec 23, 2011 3:41 am|
|Olivier Lamy||Dec 23, 2011 4:58 am|
|Mark Thomas||Dec 23, 2011 5:19 am|
|Olivier Lamy||Dec 23, 2011 7:13 am|
|Mark Thomas||Dec 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:||Olivier Lamy (ola...@apache.org)|
|Date:||Dec 19, 2011 6:56:06 am|
2011/12/19 sebb <seb...@gmail.com>:
On 19 December 2011 14:16, Antonio Petrelli <anto...@gmail.com> wrote:
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?
5. Plug-ins do generically what pieces of Ant's script do
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
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°.
you are still free to use a rc branch release mode. When you want to release just create branch from where you want to release and people can continue to hack in trunk or in the branch you wanted to cut a release.
btw not sure this discussion is related to this thread.
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.