I'll try to keep it short because I really don't want to spend time re-beating 
this dead horse.

The last time I looked a couple years ago the jars constructed out of the 
single source tree could not be compiled separately in any order.  I was told 
this wasn't a problem, at which point I realized discussion was useless.

Maven prevents problems like this through the project structure.  If this 
situation is not a problem to the tomcat community,  then the other possible 
benefits of using maven are not likely to be interesting either. 

thanks
david jencks

On Dec 17, 2011, at 12:48 PM, Mark Thomas wrote:

> 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.
> 
>> 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. The dependencies are known and
> we have checks in place (via Checkstyle) to ensure that unwanted
> dependencies are not added. 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.
> 
>> 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?
> 
>> 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 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?
> 
>> 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).
> 
> 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.).
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
> 


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

Reply via email to