Here's a solution that may be helpful at least as a workaround. TL;DR: The gist of my this trick is to use the equivalent of bash -c "source foobar" instead of source foobar directly, since source is a shell builtin and not an executable file.

(Disclaimer: In my case I had to adapt a Maven project that was created by someone else, and was set up to use the exec-maven-plugin to install a Python dependency and run a Python script. I needed to run the commands within a virtual environment, and thus needed to run the typical source myenv/bin/activate command. The solution below is likely a kludge and not the ideal way to make this work)

Here's what the pom.xml had before (It assumed python3 and pip3 are already available):

</plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <id>install-python-dependencies</id> <phase>process-resources</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>pip3</executable> <arguments> <argument>install</argument> <argument>-r</argument> <argument>path/to/requirements.txt</argument> </arguments> </configuration> </execution> <execution> <id>run-python-script</id> <phase>process-resources</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>python3</executable> <arguments> <argument>path/to/custom-script.py</argument> </arguments> </configuration> </execution> </executions> </plugin> </plugins> 

and here's how I adapted it to use source to set up a virtual environment:

</plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>exec-maven-plugin</artifactId> <version>3.4.1</version> <executions> <execution> <id>create-python-virtual-environment</id> <phase>process-resources</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>python3</executable> <arguments> <argument>-m</argument> <argument>venv</argument> <argument>my_local_env</argument> </arguments> </configuration> </execution> <execution> <id>install-python-dependencies</id> <phase>process-resources</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>bash</executable> <arguments> <argument>-c</argument> <argument>source my_local_env/bin/activate &amp;&amp; pip3 install -r path/to/requirements.txt</argument> </arguments> </configuration> </execution> <execution> <id>run-python-script</id> <phase>process-resources</phase> <goals> <goal>exec</goal> </goals> <configuration> <executable>python3</executable> <arguments> <argument>path/to/custom-script.py</argument> </arguments> </configuration> </execution> </executions> </plugin> </plugins> 

The changes done are as follows:

1. A preliminary execution, named create-python-virtual-environment, was added at the start to, well, create a virtual environment
2. The install-python-dependencies execution was modified to execute pip3 install within this virtual environment, which is activated via the source shell builtin

This second step required a few tricks to work:

• The bash -c "source <some-script>" pattern was used to call source rather than have source be the value for the <executable> element directly (which fails, as you describe)
  • (If anyone's wondering, Python virtual environments must be activated via source mylocalenv/bin/activate; directly running the mylocalenv/bin/activate script does not work.)
• The sourcing of the virtual environment and the pip3 install call were combined in the install-python-dependencies execution, since each execution happens in an isolated shell, and the virtual environment that is set up would no longer be active if the next command was executed separately.
  • Note: since this is a XML document, the && operator had to be escaped as &&

Again, I am NOT recommending this as a clean or desirable solution, but I'm sharing it here in case it helps out someone else as a quick workaround.