Apache Ant is a Java-based build tool.

The initial aim was to avoid NPE when retrieving jasper and automate retrieval of ant-antunit (with exclusion of ant/ant-launcher).

Then I started wondering whether it could be possible to forgo JUnit 3 altogether and update JUnit 4 to 4.12; if there's a good reason for keeping things the way they were, I'd be happy to add automated downloads of both versions and removal of JUnit 3 classes in JUnit 4.

Finally, jakarta regex is updated to the final version 1.4; AFACS, both versions have the same version of bytecode.

This is the initial working version of a new junitlauncher task that support using JUnit 5 framework for testing, within Ant build files. The commit in this PR is the initial set of goals that I had in mind for the first release of this task.

The manual for this task can be (temporarily) found at https://home.apache.org/~jaikiran/temp_workspace/manual/Tasks/junitlauncher.html

The dev list discussion about this PR can be found at https://www.mail-archive.com/[email protected]/msg46656.html

Some SMTP servers block messages when HELO command contains a simple hostname instead of a fully qualified domain name.

This path fixes this by using getCanonicalHostName instead of getHostName

Previously the XSLT(s) used in junitreport were only compatible with Xalan 2. Whilst you could specify a different TransformerFactory, and that could be Saxon, it would fail as the XSL(s) use Xalan specific extensions.

This PR adds compatibility with Saxon, so that if you specify Saxon as the TransformerFactory, then pure XSLT2 stylesheets are used without any vendor extensions.

This resolves a rare race condition when running with the Parallel-Ant executor.

This seems to be triggered concurrently when a reference was being added to the project at the same time the references were being copied through Project.getCopyOfReferences(). The stack trace observed in this case was:

java.util.ConcurrentModificationException
        at java.util.Hashtable$Enumerator.next(Hashtable.java:1387)
        at java.util.HashMap.putMapEntries(HashMap.java:512)
        at java.util.HashMap.<init>(HashMap.java:490)
        at org.apache.tools.ant.Project.getCopyOfReferences(Project.java:2038)
        at org.apache.tools.ant.util.ScriptRunnerBase.bindToComponent(ScriptRunnerBase.java:307)
        at org.apache.tools.ant.util.ScriptRunnerHelper.getScriptRunner(ScriptRunnerHelper.java:66)
        at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:53)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
        at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:435)
        at org.apache.tools.ant.Target.performTasks(Target.java:456)
        at org.codeaholics.tools.build.pant.AntWrapperImpl.executeTarget(Unknown Source)
        at org.codeaholics.tools.build.pant.DependencyGraphEntry.run(Unknown Source)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

Support for the jmod and jlink tools present in the JDK since Java 9. Now that Java 11 has no standalone JRE, officially, these tools are the only way to distribute client-side Java applications.

The commit here fixes the issues reported in:

https://bz.apache.org/bugzilla/show_bug.cgi?id=58833 https://bz.apache.org/bugzilla/show_bug.cgi?id=58451

The PumpStreamHandler and the StreamPumper work together for redirecting the streams (reading from inputstream and writing to a outputstream). When the StreamPumper is asked to stop, it stops reading from the input stream and goes on to finish any (non-blocking) reads and finally a (potentially blocking) flush of whatever it has read so far. The PumpStreamHandler, which initiates that stop is a bit too impatient (mainly because of its inability to know what's going on in StreamPumper after the stop was invoked on it) and starts interrupting the StreamPumper's thread very soon (as early as 200 milli seconds after stop). This triggers a bunch of issues in StreamPumper, which either is in the middle of finishing the non-blocking reads or in the middle of actually flushing out whatever it's held on to and ultimately leads to a non-clean stop and thus corrupting/truncating the output stream as noted in those issues.

The commit here introduces a way, through the PostStopHandle, for PumpStreamHandler to be aware that upon stop the StreamPumper has respected the call to stop and is doing certain post-stop finishing acts before actually being considered finished. The PumpStreamHandler then allows a bit of time for the post-stop tasks to finish before actually trying to kill off the StreamPumper using thread interrupts, if the StreamPumper didn't finish after that grace period.

The commit here intentionally does not introduce a configurable "grace period" for the post-stop activities and instead using a hard coded (maximum) 2 seconds for the following reasons:

• The 2 seconds is the maxium amount of time to let the post-stop to complete, so it's not always going to wait that long

• The cleaning up gracefully is an internal implementation detail and doesn't have to end up being configured by the user.

• Finally, the PumpStreamHandler anyway falls back to the thread interrupts if the post-stop (flush() etc...) doesn't complete in those 2 seconds. So from a end user point of view, there isn't really any behaviour change, except that we now give the StreamPumper a chance to gracefully stop.

This PR is against master branch. If this is approved I'll backport it to 1.9.x branch too.

As suggested in https://bz.apache.org/bugzilla/show_bug.cgi?id=19516, the change in this PR uses java.io.BufferedInputStream which can take an underlying InputStream and provide mark support on the input stream. This should prevent loading a large amount of data into memory, in certain cases, in the Zip task.

If this PR is approved, I'll then backport this pretty straightforward change to 1.9.x branch too.

The fix here is to honor the local variables in propertyset within the local scope. Below is the bug related to the fix.

Bug 50179 - Properties declared as "local" are not accessible via propertyset.

Currently only java files are passed using commandline argument file for javac. There are times when classpath is longer than 8000 characters. on unix that works, but on windows it doesn't, see https://support.microsoft.com/en-us/help/830473/command-prompt-cmd-exe-command-line-string-limitation. That leads to exception like

at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:601)
        at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute(JavacExternal.java:62)
        at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:1395)
        at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:1121)
        ...
Caused by: java.io.IOException: Cannot run program "c:\...\javac.exe" (in directory "..."): CreateProcess error=206, The filename or extension is too long
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:1048)
        at java.lang.Runtime.exec(Runtime.java:620)
        at org.apache.tools.ant.taskdefs.launcher.Java13CommandLauncher.exec(Java13CommandLauncher.java:58)
        at org.apache.tools.ant.taskdefs.Execute.launch(Execute.java:426)
        at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:440)
        at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter.executeExternalCompile(DefaultCompilerAdapter.java:598)
        ... 33 more
Caused by: java.io.IOException: CreateProcess error=206, The filename or extension is too long
        at java.lang.ProcessImpl.create(Native Method)
        at java.lang.ProcessImpl.<init>(ProcessImpl.java:386)
        at java.lang.ProcessImpl.start(ProcessImpl.java:137)
        at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029)
        ... 38 more

This pull requests puts all but -J options into commandline argument file. -J options can't be specified in commandline argument file as per documentation: https://docs.oracle.com/en/java/javase/11/tools/javac.html

Changes:

1. Added modulepath and upgrademodulepath elements.
2. When modulepath or upgrademodulepath is given VM fork is required.
3. JUnit library required by Ant is searched both on classpath and modulepath.

As seen in JUnitTask + JDK9 question thread there are many ways how to write and execute unit test in the JDK9 involving several java options (-addmods, -Xpatch, -XaddExports, -XaddReads).

The JunitTask can

1. Keep the responsibility on user to correctly specify these options. The disadvantage of these solution is the complexity of VM options.
2. Automatically add the VM options. The disadvantage of these solution is that it’s impossible to cover all scenarios and there needs to be a way how to disable it. Also the options may change in time, for example if junit becomes a named module.

Currently the patch contains the 1st. solution. Thanks for comments!

Bumps commons-net from 3.8.0 to 3.9.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This PR adds a Log4j2 build listener as a modern alternative to the obsolete Log4j 1.x listener.

The Log4j2 listener differs in some choices from the Log4j counterpart. Most notably:

• the name of the loggers follows the pattern project_name.target_name.task_name,
• the class name of the Java object that performs the logging is recorded in the className property of the location info (%C in the pattern layout of Log4j2 Core),
• the name of the build file and the current line number are recorded in the corresponding properties of the location info (%F and %L),
• VERBOSE is not mapped to DEBUG, but a custom level is used.

The Log4j2 listener can be used as BuildLogger, but the level change feature works only if the underlying Log4j2 API implementation is Log4j2 Core.

Bumps xercesImpl from 2.12.0 to 2.12.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps xercesImpl from 2.12.0 to 2.12.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Context

I'm working on migration of Cassandra to JUnit5 (https://issues.apache.org/jira/browse/CASSANDRA-16630). Our test running code is heavily customized and relies onto forkMode property. Unfortunately, junitlauncher task does not have any equivalent. The purpose of this change is to introduce a way to run tests independently (in separate JVMs).

Behavior

This PR does not change any existing behavior. By default, the tests will be run in the same forked JVM (aka mode="once").

Summary of the changes

1. Added node attribute to fork element
2. Added logic to spin a JVM per test suite class into JUnitLauncherTask
3. Updated tests and documentation

I'm not sure JUnitLauncherTaskTest is run during ./build clean test, hence the test might be broken.