A big +1.
I tried to do a maven build from thé current layout and it was a
nightmare, the pom used a this time turning more in an ant than a
maven one. Also it prevent to make a good use of m2eclipse with tc.
I second David in this, Tomcat 7 could be the first to use a maven
build chain and I could help on this.
Evolution, not revolution.
Le 11 juil. 2009 à 00:26, David Jencks <david_jen...@yahoo.com> a
écrit :
I am well aware that the tomcat developers regard ant as the one
true build system, so please note that I am not suggesting that
tomcat adopt maven. However I think it is just barely conceivable
that other projects are facing the same sort of problems as geronimo
and might find this mavenization technique useful or that the tomcat
developers might want to address some of the difficulties I
encountered.
Backgound...
More than two years ago the tomcat community accepted a proposal I
made to make annotation processing more flexible and work better
with the geronimo integration, and applied it to trunk. I naively
thought that this meant it would eventually get released in a 6.x
tomcat. Since then geronimo has been shipping with patched tomcat
jars that are based on a released tomcat 6.0.x version with the
annotation processing changes patched in. However our process for
producing these jars broke and our method for distributing the jars
creates a lot of problems with maven infrastructure. The cleanest
solution appears to be for geronimo to set up a maven build that
produces the tomcat jars we need under a geronimo groupId.
Problem...
Geronimo needs a repeatable process for getting tomcat source code
into a maven project preserving svn history so we can then apply
patches and know what we are building.
Results....
I wrote a maven archetype to set up the basic structure of a
mavenized tomcat build and a bunch of bash scripts to svn cp the
tomcat source from a tag into this maven project framework. The
contents of the maven subprojects attempts to follow the contents of
the jars shipped by tomcat, although this is not completely possible
(see below).
Archetype:
source
https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-archetype
snapshot
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/tomcat-parent-archetype/1.0-SNAPSHOT
Sample result projects, patched with what I think are the annotation
handling changes:
https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.18
https://svn.apache.org/repos/asf/geronimo/external/trunk/tomcat-parent-6.0.20
snapshot
https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/ext/tomcat/
Difficulties...
One of the great features of an ant build such as that used by
tomcat where all the classes are compiled at once and then
distributed into jars is that the contents of the resulting jars can
be completely randomized and have circular dependencies so that they
all have to be loaded in the same classloader. AFAICT Tomcat has
taken full advantage of this impressive feature with the catalina
and coyote jars; at any rate I couldn't figure out how to
disentangle them. So I combined them in the mavenized project.
:-)
well, seriously, you might want to look into fixing this in tomcat
7. I don't know of any practical way to enforce or check this other
than using a maven like project layout whether you use maven, ant,
ivy, or something else. Maybe an ant expert can come up with
something.
thanks
david jencks
---------------------------------------------------------------------
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
