Doing several invocations through exec:java?

[jkesselm]

I need to call the same Java program with several different sets of parameters.

I can't replicate the whole <plugin> block because that's a declaration and must be unique.

Maven tells me I can't have multiple <configuration/>s. I can have multiple <executions/>, but your example puts all the <arguments/> in the <configuration/> so that doesn't seem to help me.

Can't imagine that there isn't a standard way to do this, but I'm not sure what it is. Possible it's a standard Maven idiom that I just haven't learned yet... but even so it might be a good thing to explicitly document.

[jkesselm]

.... Oh. Default configuration outside the executions, then a configuration inside each execution to set local parameters? With explicit IDs so they don't collide on the default for that?

Maven accepts that without complaining... but I'm still getting output only from the first <execution>.

Copying or moving <additionalClasspathElements> and <mainClass> into the per-execution configurations doesn't seem to change this.

What's my obvious beginner error?

      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>exec-maven-plugin</artifactId>
        <version>3.1.0</version>
        <executions>
          <execution>
	    <id>Stylebook XSLTC documentation</id>
            <phase>package</phase>
            <goals>
              <goal>java</goal>
            </goals>
	    <configuration>
              <arguments>
		<argument>loaderConfig=sbk:/style/loaderdesign.xml</argument>
		<argument>targetDirectory=./target/tmp/site/xsltc/</argument>
		<argument>./stylebook/sources/xsltc.xml</argument>
		<argument>./stylebook/style</argument>
              </arguments>
	    </configuration>
          </execution>
          <execution>
	    <id>Stylebook Xalan interpretive documentation</id>
            <phase>package</phase>
            <goals>
              <goal>java</goal>
            </goals>
	    <configuration>
              <arguments>
		<argument>loaderConfig=sbk:/style/loaderdesign.xml</argument>
		<argument>targetDirectory=./target/tmp/site/xalan/</argument>
		<argument>./stylebook/sources/xalan-jsite.xml</argument>
		<argument>./stylebook/style</argument>
              </arguments>
	    </configuration>
          </execution>
          <execution>
	    <id>Stylebook design documentation</id>
            <phase>package</phase>
            <goals>
              <goal>java</goal>
            </goals>
	    <configuration>
              <arguments>
		<argument>loaderConfig=sbk:/style/loaderdesign.xml</argument>
		<argument>targetDirectory=./target/tmp/site/design/</argument>
		<argument>./stylebook/sources/xalandesign.xml</argument>
		<argument>./stylebook/style</argument>
              </arguments>
	    </configuration>
          </execution>
        </executions>
        <configuration>
	  <additionalClasspathElements>./stylebook/stylebook-1.0-b3_xalan-2.jar</additionalClasspathElements>
          <mainClass>org.apache.stylebook.StyleBook</mainClass>
        </configuration>
      </plugin>

[kriegaex]

@jkesselm: For me, this works locally. Can you please share a link to a full reproducer, so other people or I can take a closer look?

[jkesselm]

• Clone https://github.com/apache/xalan-java.
• Check out and switch to branch 'exec-maven-plugin-problem'
• Run mvn package.
• Then look in target/tmp/site.

You'll see that the xsltc subdirectory has been created, but not target/tmp/site/xalan or target/tmp/site/design. Apparently only the first is running.

Platform is Fedora running under WSL. mvn -version reports

Maven home: /mnt/c/users/keshlam/apache-maven-3.6.3
Java version: 1.8.0_382, vendor: Red Hat, Inc., runtime: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.382.b05-2.fc37.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.15.90.1-microsoft-standard-wsl2", arch: "amd64", family: "unix"

(Yes, I'm deliberately using a downlevel JDK, to ensure backward compatibility. That shouldn't affect this, right?)

Let me know if you need other details or experiments performed.

---

Context: What I'm trying to do is move the logic now in stylebook_docgen.sh into the Maven build, so it doesn't have to be done as postprocessing. As written there it does what's expected (though that's outputting directly to target/site rather than to target/site/tmp). But maven is currently giving me only that one execution of stylebook. I must be missing something obvious.

Maven reminds me of an analog synth. Lots of patch points and knobs; takes quite a while to learn how the designer intended them to be used, how they can actually be (ab)used, and how they all interact. And sometimes the results are not what I expected.

---

And something else weird is going on. Since adding this, my main compilation has stopped working; I'm no longer getting anything but the target/tmp/site/xsltc output.

Lemme try reverting (to the xalan-java-mvn-refactored branch) and adding this again from scratch...

[jkesselm]

Checked out the xalan-java-mvn-refactored branch.

Added the multi-execution I originally quoted to the POM, directly above </plugins>.

Ran the maven build, both just as package and as clean package site source:jar source:test-jar.
Either way, ./target/tmp/site/ contains only xsltc/.
Problem confirmed as still present.

Output of mvn -X package attached. You'll see that there's only one [DEBUG] Invoking. So, yes, I'm only getting one of the three executions.

jkesselm-issue-388.log

[jkesselm]

I've updated the exec-maven-plugin-problem branch if you want to run it locally.

[slawekjaranowski]

I tried ... with xalan on branch exec-maven-plugin-problem

commit 9c47e6f74de2ee834c09fbc860653bf36f38c2da (HEAD -> exec-maven-plugin-problem, origin/exec-maven-plugin-problem)

and I have

$ mvn package

INFO] --- exec:3.1.0:java (Stylebook XSLTC documentation) @ xalan-project ---
[StyleBook] Overriding loaderConfig="sbk:/style/loaderdesign.xml" (Old="sbk:/style/loader.xml")
[StyleBook] Overriding targetDirectory="./target/tmp/site/xsltc/" (Old=".")
[StyleBook] Caught java.io.IOException
java.io.IOException: Style File/Directory not found
	at org.apache.stylebook.URLHandler.<init>(Unknown Source)
	at org.apache.stylebook.StyleBook.<init>(Unknown Source)
	at org.apache.stylebook.StyleBook.main(Unknown Source)
	at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:279)
	at java.lang.Thread.run(Thread.java:750)

[jkesselm]

Sorry, forgot to check that in. (Ant build expanded it from a jarfile at build time; simpler, I think, to just check it in flat.)
Should be there now.

[jkesselm]

(FWIW, I decompiled stylebook to take a quick look at it. About 2500 lines of code, mostly straightforward. Almost tempted to comment it and re-contribute it to Apache, if real source can't be found. "In my copious spare time.")

[slawekjaranowski]

In StyleBook there is code:

    public static void main(String[] var0) throws IOException {
      .....
      exit((String)"All done successfully", 0);
    }

    private static void exit(String var0, int var1) {
        log(var0);
        System.exit(var1);
    }

as exec-maven-plugin simply execute code in the same JVM .... in this case build are finished by System.exit ....

I have:

[INFO] --- exec:3.1.0:java (Stylebook XSLTC documentation) @ xalan-project ---
[StyleBook] Overriding loaderConfig="sbk:/style/loaderdesign.xml" (Old="sbk:/style/loader.xml")
[StyleBook] Overriding targetDirectory="./target/tmp/site/xsltc/" (Old=".")

....

[StyleBook] All done successfully
$

[jkesselm]

Ah. So System.exit() is blowing up the entire Maven session before it can get to the second execution?

If so, the quick fix would be as discussed in https://www.mojohaus.org/exec-maven-plugin/examples/example-exec-for-java-programs.html to launch each StyleBook in a separate JVM. I'll try that.

(The better fix would be to have a version of StyleBook that doesn't gratuitously call System.exit(), of course.)

Thanks. I generally start by assuming I did something stupid... and arguably I did, just not what I thought I had.

[slawekjaranowski]

Ah. So System.exit() is blowing up the entire Maven session before it can get to the second execution?

exactly

[jkesselm]

Seems to have done it. Thanks!

[kriegaex]

@slawekjaranowski, would you be interested in a PR to address this? I thought about an option for the exec:java goal to block System.exit by means of a security manager (SM). That is deprecated for removal since JDK 17, but still possible, if the Maven JVM is called with -Djava.security.manager=allow. The SM would intercept calls to System.exit and throw a SecurityException, as required by the SM API. The caller (Maven Exec) would handle the exception gracefully and in case of exit code 0 just print an info or debug message to the console or fail the build. That way, users would not be forced to use exec:exec in order to fork and could stay within the comfortable bounds of exec:java even for tools behaving badly, trying to exit the VM instead of just throwing uncaught exceptions.

Right after finishing exec:java execution, the original SM would be reactivated, i.e. all other plugins and subsequent executions of the same goal without the option to block System.exit would be unaffected. In multi-threaded Maven, maybe we would have to limit the SM's interference to certain threads or classloaders, I have not thought that through yet. I am open for suggestions there.

Before you refuse, because I suggest a deprecated API, please consider that JEP 411 links to JDK-8199704, which is blocking removal of the SM API until a suitable replacement has been introduced to the JVM, i.e. even in the future there will be a means to block System.exit, and Maven Exec can be updated to use that new API, when available and running on a JDK containing such API.

WDYT? Feel free to also mention other MojoHaus developers to discuss this.