You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by jean-frederic clere <jf...@gmail.com> on 2018/09/03 08:38:01 UTC

tomcat-native trunk

Hi,

I am working on a jar to laod the libraries in tomcat-native. I have
noted that the examples don't compile and that the test directory is
empty. I am planning to clean that and go for maven build for the new jar.

Comments?

-- 
Cheers

Jean-Frederic

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


Re: tomcat-native trunk

Posted by Emmanuel Bourg <eb...@apache.org>.
Le 03/09/2018 à 11:41, Mark Thomas a écrit :

> No strong views on which build system to use but I will say that Gradle
> might be worth a look.

With my Debian maintainer hat on I have to say that Gradle is a real
hindrance and I hope the Tomcat components will stay out of it. Gradle
itself is a behemoth that is very difficult to maintain, as a build
system it has little respect for backward compatibility, and its
imperative nature quickly turns build files into a non standard, project
specific, mess.

Gradle is barely an improvement over Ant IMHO, but at least Ant is
stable and really cares about backward compatibility. Beyond Ant I think
a declarative build system like Maven is a saner choice.

The tomcat-native fork maintained by netty [1] is built with Maven,
maybe we could get some inspiration from it.

Emmanuel Bourg

[1] https://github.com/netty/netty-tcnative

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


Re: tomcat-native trunk

Posted by jean-frederic clere <jf...@gmail.com>.
On 03/09/18 12:31, Rainer Jung wrote:
> Am 03.09.2018 um 11:41 schrieb Mark Thomas:
>> On 03/09/18 09:38, jean-frederic clere wrote:
>>> Hi,
>>>
>>> I am working on a jar to laod the libraries in tomcat-native. I have
>>> noted that the examples don't compile and that the test directory is
>>> empty. I am planning to clean that and go for maven build for the new
>>> jar.
>>>
>>> Comments?
>>
>> Odd. The examples compile for me - at least in the IDE anyway.
> 
> Same here. I do it via script when testing release candidates. Roughly:
> 
> ant compile
> ant javadocs
> ant jar
> ant download
> ant test
> 
> ant run-echo &
> echopid=$!
> sleep 20
> ( printf 'a\n'; sleep 3; printf '!\n'; sleep 3) | telnet localhost 8023
> kill $echopid

OK, I was just the github mirror when using svn I have:

Fetching external item into 'trunk/test/org/apache/tomcat/jni':
...
Fetching external item into 'trunk/java/org/apache/tomcat/jni':

OK that was the part missing.

> 
>> The test directory (like the main directory) looks to be an svn
>> external. There should be 4 classes in it.
>>
>> I wonder if we wouldn't be better to drop the Java code from the native
>> project entirely (probably an idea for 2.x).
> 
> There's a top-level TODO.txt file to which I added a few years ago the
> following:
> 
> Java Tests and Examples
> -----------------------
> 
> - "ant run-echo": what is the expected behaviour of this example.
>   I couldn't get it to do something understandable.
>   Document the example in the README.txt.
> 
> - "ant run-ssl-server": Couldn't we include a test certificate in the
>   distribution?
> 
> - "ant run-ssl-server": What should the test produce, if run successfully?
>   Document the example in the README.txt.
> 
> - "ant run-local-server": Creates a unix socket "\\.\PIPE\test" in the
>   examples directory, then waits. How is the test expected to work?
>   And the file name doesn't seem to be appropriate for Unix.
>   Document the example in the README.txt.
> 
> 
> Java Classes Source Distribution
> --------------------------------
> 
> Check on how to handle the test and examples classes.
> I think they have no other home.
> 
> Furthermore some of the Java files do not exist inside TC:
> - Apr.java, apr.properties, jni/Buffer.java and jni/Thread.java
> I don't know their purpose and whether we can delete them.
> 
> So I think the use and state of the java files is very questionable.
> 
>> Thinking about some of our previous discussions, if we drop APR/native
>> from 10.x onwards and we reduce the native API in a 2.x down to only
>> what we use we might end up a very thin wrapper around OpenSSL that
>> exposed the small subset of OpenSSL functionality we use.
>>
>> No strong views on which build system to use but I will say that Gradle
>> might be worth a look. I do think that a build system should either be
>> supported or completely removed. Having files lying around for old, no
>> longer used build systems just causes confusion.
> 
> Which old build system do you mean? I thought it uses ant, just like
> Tomcat. Or do you mean the native autotools/make parts?
> 
>> I suspect there is a lot of cruft that needs to be removed as well. It
>> would be good to go through and have a good clean-up. I see references
>> to Netware in some files. Having just removed those from JK I'll take a
>> look at removing them from Native as well.
> 
> +1
> 
> Regards,
> 
> Rainer
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
> 
> 


-- 
Cheers

Jean-Frederic

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


Re: tomcat-native trunk

Posted by Mark Thomas <ma...@apache.org>.
On 03/09/18 11:31, Rainer Jung wrote:
> Am 03.09.2018 um 11:41 schrieb Mark Thomas:

<snip/>

>> No strong views on which build system to use but I will say that Gradle
>> might be worth a look. I do think that a build system should either be
>> supported or completely removed. Having files lying around for old, no
>> longer used build systems just causes confusion.
> 
> Which old build system do you mean? I thought it uses ant, just like
> Tomcat. Or do you mean the native autotools/make parts?

More that if the build system is switched to !Ant then make sure that
all the Ant parts are removed.

I'm less familiar with the native build bits although I do wonder if
there is merit in keeping the VS6 files given that:
- you can't get VS6 via MSDN
- it is ~20 years old
- we don't use Visual Studio to build the Windows binaries

On the other hand, for those that prefer to develop in Visual Studio
there may be merit in providing files for a more recent version.

Mark

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


Re: tomcat-native trunk

Posted by Rainer Jung <ra...@kippdata.de>.
Am 03.09.2018 um 11:41 schrieb Mark Thomas:
> On 03/09/18 09:38, jean-frederic clere wrote:
>> Hi,
>>
>> I am working on a jar to laod the libraries in tomcat-native. I have
>> noted that the examples don't compile and that the test directory is
>> empty. I am planning to clean that and go for maven build for the new jar.
>>
>> Comments?
> 
> Odd. The examples compile for me - at least in the IDE anyway.

Same here. I do it via script when testing release candidates. Roughly:

ant compile
ant javadocs
ant jar
ant download
ant test

ant run-echo &
echopid=$!
sleep 20
( printf 'a\n'; sleep 3; printf '!\n'; sleep 3) | telnet localhost 8023
kill $echopid

> The test directory (like the main directory) looks to be an svn
> external. There should be 4 classes in it.
> 
> I wonder if we wouldn't be better to drop the Java code from the native
> project entirely (probably an idea for 2.x).

There's a top-level TODO.txt file to which I added a few years ago the 
following:

Java Tests and Examples
-----------------------

- "ant run-echo": what is the expected behaviour of this example.
   I couldn't get it to do something understandable.
   Document the example in the README.txt.

- "ant run-ssl-server": Couldn't we include a test certificate in the
   distribution?

- "ant run-ssl-server": What should the test produce, if run successfully?
   Document the example in the README.txt.

- "ant run-local-server": Creates a unix socket "\\.\PIPE\test" in the
   examples directory, then waits. How is the test expected to work?
   And the file name doesn't seem to be appropriate for Unix.
   Document the example in the README.txt.


Java Classes Source Distribution
--------------------------------

Check on how to handle the test and examples classes.
I think they have no other home.

Furthermore some of the Java files do not exist inside TC:
- Apr.java, apr.properties, jni/Buffer.java and jni/Thread.java
I don't know their purpose and whether we can delete them.

So I think the use and state of the java files is very questionable.

> Thinking about some of our previous discussions, if we drop APR/native
> from 10.x onwards and we reduce the native API in a 2.x down to only
> what we use we might end up a very thin wrapper around OpenSSL that
> exposed the small subset of OpenSSL functionality we use.
> 
> No strong views on which build system to use but I will say that Gradle
> might be worth a look. I do think that a build system should either be
> supported or completely removed. Having files lying around for old, no
> longer used build systems just causes confusion.

Which old build system do you mean? I thought it uses ant, just like 
Tomcat. Or do you mean the native autotools/make parts?

> I suspect there is a lot of cruft that needs to be removed as well. It
> would be good to go through and have a good clean-up. I see references
> to Netware in some files. Having just removed those from JK I'll take a
> look at removing them from Native as well.

+1

Regards,

Rainer

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


Re: tomcat-native trunk

Posted by Mark Thomas <ma...@apache.org>.
On 03/09/18 09:38, jean-frederic clere wrote:
> Hi,
> 
> I am working on a jar to laod the libraries in tomcat-native. I have
> noted that the examples don't compile and that the test directory is
> empty. I am planning to clean that and go for maven build for the new jar.
> 
> Comments?

Odd. The examples compile for me - at least in the IDE anyway.

The test directory (like the main directory) looks to be an svn
external. There should be 4 classes in it.

I wonder if we wouldn't be better to drop the Java code from the native
project entirely (probably an idea for 2.x).

Thinking about some of our previous discussions, if we drop APR/native
from 10.x onwards and we reduce the native API in a 2.x down to only
what we use we might end up a very thin wrapper around OpenSSL that
exposed the small subset of OpenSSL functionality we use.

No strong views on which build system to use but I will say that Gradle
might be worth a look. I do think that a build system should either be
supported or completely removed. Having files lying around for old, no
longer used build systems just causes confusion.

I suspect there is a lot of cruft that needs to be removed as well. It
would be good to go through and have a good clean-up. I see references
to Netware in some files. Having just removed those from JK I'll take a
look at removing them from Native as well.

Mark

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