On Tue, 26 Jun 2018 09:07:32 +0200 Emmanuel Bourg <ebo...@apache.org> wrote:
> Le 26/06/2018 à 05:21, William L. Thomson Jr. a écrit : > > > Because I am crazy :) > > I personally would support a move to a Maven directory layout even if > we stick to Ant as the main build system for now. I think it's good > to use a standard project layout, it looks immediately familiar to > newcomers. That is the idea, just to standardize stuff. Not switch build systems. > That said, I don't really understand why you can't use Ant to build > Tomcat in Gentoo. Ant is rather reasonably easy to bootstrap and we > have no problem using it to build Tomcat from sources in > Debian/Ubuntu. The problem with Ant and Gentoo has nothing to do with Tomcat really. Tomcat has built fine for years via Ant on Gentoo and still does. But it is the Gentoo specific Ant eclass, bash functions library. Plus packaging and dealing with Ant Tasks. That is a bit cumbersome to maintain. All around dealing with Ant is more work. I rather avoid. Presently Gentoo is stuck on <= 1.8 till ant eclass and others are updated, and other things. The ant eclass also requires complicated XML re-writers in python to modify classpath, source/target and now release in build.xml. Which adds more overhead, complexity, and things to maintain. For some things like Netbeans and other projects it failed to re-write all source/targets. I tossed these rather than maintain, to complex, there are better ways. https://github.com/gentoo/gentoo/blob/master/eclass/java-ant-2.eclass https://github.com/gentoo/gentoo/blob/master/eclass/ant-tasks.eclass I am using a more simplistic method of straight javac using a Gentoo bash eclass. That looks for stuff in standard locations. Reason for my request to change Tomcat directory layout. Most the logic is here https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-pkg-simple.eclass Plus legacy eclass till I re-write, it is already heavily modified. https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/java-utils-2.eclass My way does not require build.xml modifications, or anything there. I can ensure always source/target/release, as I am doing the compile directly. No worries on classpath pollution, accidentally using shipped jars, or other. Which for ant at times required symlinks to system jars in build system and other cumbersome stuff. Dealing with Ant is a lot of work and things to maintain. For example for tomcat-serlvet-api, always used a stand alone build.xml, separate from one tomcat ships with. Since there is no means to build only those jars easily. Without heavy modifications to default build.xml. Thus creating a standalone build.xml, more to maintain. https://github.com/gentoo/gentoo/tree/master/dev-java/tomcat-servlet-api/files Then to prevent downloads, and other things not needed in the default build.xml. You need to modify build.xml and usually create a patch. Which is also cumbersome to deal with, more to maintain. https://github.com/gentoo/gentoo/tree/master/www-servers/tomcat/files My way requires no patches, guaranteed source/target/release, classpath, etc. All in a more reliable and simple way that requires less effort to maintain over a long term. Across hundreds of packages, maintained by a single person :) -- William L. Thomson Jr.
pgpmBIIIwsIWp.pgp
Description: OpenPGP digital signature
