Re: Tomcat source layout (was: JDK 11 EA 18)

[Emmanuel Bourg <eb...@apache.org>]

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 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.

Emmanuel Bourg

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

Re: Tomcat source layout (was: JDK 11 EA 18)

["William L. Thomson Jr." <wl...@o-sinc.com>]

On Tue, 26 Jun 2018 09:07:32 +0200
Emmanuel Bourg <eb...@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.