exec-maven-plugin

[Enrico Pinzaglia]

Hello
i've a project with exeternal jar as dependencies and i can't run it using the exec-maven-plugin.
This is the POM:

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>test</groupId>
	<artifactId>logisim</artifactId>
	<version>1.0</version>
	<packaging>jar</packaging>
	<name>logisim</name>
	<!-- FIXME change it to the project's website -->
	<url>http://www.example.com</url>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<maven.compiler.source>1.8</maven.compiler.source>
		<maven.compiler.target>1.8</maven.compiler.target>
	</properties>

	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.12</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>com.connectina.swing.fontchooser</groupId>
			<artifactId>fontchooser</artifactId>
			<version>1.0</version>
			<scope>system</scope>
			<systemPath>${project.basedir}/lib/fontchooser.jar</systemPath>
		</dependency>
		<dependency>
			<groupId>colorpicker</groupId>
			<artifactId>colorpicker</artifactId>
			<version>1.0</version>
			<scope>system</scope>
			<systemPath>${project.basedir}/lib/colorpicker.jar</systemPath>
		</dependency>
		<dependency>
			<groupId>JavaHelp</groupId>
			<artifactId>JavaHelp</artifactId>
			<version>1.0</version>
			<scope>system</scope>
			<systemPath>${project.basedir}/lib/JavaHelp.jar</systemPath>
		</dependency>
		<dependency>
			<groupId>Logger-1.0.0</groupId>
			<artifactId>Logger-1.0.0</artifactId>
			<version>1.0</version>
			<scope>system</scope>
			<systemPath>${project.basedir}/lib/Logger-1.0.0.jar</systemPath>
		</dependency>
		<dependency>
			<groupId>MRJAdapter</groupId>
			<artifactId>MRJAdapter</artifactId>
			<version>1.0</version>
			<scope>system</scope>
			<systemPath>${project.basedir}/lib/MRJAdapter.jar</systemPath>
		</dependency>
	</dependencies>

	<build>
		<pluginManagement><!-- lock down plugins versions to avoid using Maven defaults (may be moved to parent pom) -->
			<plugins>        
				<plugin>
					<artifactId>maven-clean-plugin</artifactId>
					<version>3.1.0</version>
				</plugin>
				
				<plugin>
					<artifactId>maven-resources-plugin</artifactId>
					<version>3.0.2</version>
				</plugin>
				
				<plugin>
					<artifactId>maven-compiler-plugin</artifactId>
					<version>3.8.0</version>
				</plugin>
				
				<plugin>
					<artifactId>maven-surefire-plugin</artifactId>
					<version>2.22.1</version>
				</plugin>
				
				<plugin>
					<artifactId>maven-jar-plugin</artifactId>
					<version>3.0.2</version>
					<configuration>
					<archive>
						<index>true</index>
						<manifest>
							<addClasspath>true</addClasspath>
							<mainClass>com.cburch.logisim.Main</mainClass>
						</manifest>
					</archive>
					<descriptorRefs>
						<descriptorRef>jar-with-dependencies</descriptorRef>
					</descriptorRefs>
					</configuration>
				</plugin>
				
				<plugin>
					<artifactId>maven-install-plugin</artifactId>
					<version>2.5.2</version>
				</plugin>
				
				<plugin>
					<artifactId>maven-deploy-plugin</artifactId>
					<version>2.8.2</version>
				</plugin>
				
				<plugin>
					<artifactId>maven-site-plugin</artifactId>
					<version>3.7.1</version>
				</plugin>
				
				<plugin>
					<artifactId>maven-project-info-reports-plugin</artifactId>
					<version>3.0.0</version>
				</plugin>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-dependency-plugin</artifactId>
					<version>3.3.0</version>
					<configuration>
						<outputDirectory>${project.build.directory}/lib</outputDirectory>		
					</configuration>
					<executions>
						<execution>
							<id>copy-dependencies</id>
							<phase>package</phase>
							<goals>
								<goal>copy-dependencies</goal>
							</goals>	
						</execution>
					</executions>
				</plugin>
							
				<plugin>
					<groupId>org.codehaus.mojo</groupId>
					<artifactId>exec-maven-plugin</artifactId>
					<version>3.0.0</version>
					<executions>
						<execution>
							<goals>
								<goal>java</goal>
							</goals>	
						</execution>
					</executions>
					<configuration>
						<mainClass>com.cburch.logisim.Main</mainClass>
						<includeProjectDependencies>true</includeProjectDependencies>
						<addResourcesToClasspath>true</addResourcesToClasspath>
						<includePluginDependencies>true</includePluginDependencies>
					</configuration>
				</plugin>
				
			</plugins>
		</pluginManagement>
		
	</build>
</project>

The prompt from maven is:

[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for test:logisim:jar:1.0
[WARNING] 'dependencies.dependency.systemPath' for com.connectina.swing.fontchooser:fontchooser:jar should not point at files within the project directory, ${project.basedir}/lib/fontchooser.jar will be unresolvable by dependent projects @ line 33, column 16
[WARNING] 'dependencies.dependency.systemPath' for colorpicker:colorpicker:jar should not point at files within the project directory, ${project.basedir}/lib/colorpicker.jar will be unresolvable by dependent projects @ line 40, column 16
[WARNING] 'dependencies.dependency.systemPath' for JavaHelp:JavaHelp:jar should not point at files within the project directory, ${project.basedir}/lib/JavaHelp.jar will be unresolvable by dependent projects @ line 47, column 16
[WARNING] 'dependencies.dependency.systemPath' for Logger-1.0.0:Logger-1.0.0:jar should not point at files within the project directory, ${project.basedir}/lib/Logger-1.0.0.jar will be unresolvable by dependent projects @ line 54, column 16
[WARNING] 'dependencies.dependency.systemPath' for MRJAdapter:MRJAdapter:jar should not point at files within the project directory, ${project.basedir}/lib/MRJAdapter.jar will be unresolvable by dependent projects @ line 61, column 16
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ----------------------------< test:logisim >----------------------------
[INFO] Building logisim 1.0
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- exec-maven-plugin:3.0.0:java (default-cli) @ logisim ---
[WARNING]
java.lang.NoClassDefFoundError: com/connectina/swing/fontchooser/JFontChooser
    at java.lang.ClassLoader.defineClass1 (Native Method)
    at java.lang.ClassLoader.defineClass (ClassLoader.java:1013)
    at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:150)
    at java.net.URLClassLoader.defineClass (URLClassLoader.java:524)
    at java.net.URLClassLoader$1.run (URLClassLoader.java:427)
    at java.net.URLClassLoader$1.run (URLClassLoader.java:421)
    at java.security.AccessController.doPrivileged (AccessController.java:712)
    at java.net.URLClassLoader.findClass (URLClassLoader.java:420)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:588)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:521)
    at com.cburch.logisim.data.Attributes.forFont (Attributes.java:131)
    at com.cburch.logisim.std.base.Text.<clinit> (Text.java:28)
    at com.cburch.logisim.tools.TextTool.<init> (TextTool.java:36)
    at com.cburch.logisim.std.base.Base.<init> (Base.java:26)
    at com.cburch.logisim.std.Builtin.<init> (Builtin.java:24)
    at com.cburch.logisim.file.Loader.<init> (Loader.java:33)
    at com.cburch.logisim.gui.start.Startup.run (Startup.java:412)
    at com.cburch.logisim.Main.main (Main.java:39)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
    at java.lang.Thread.run (Thread.java:833)
Caused by: java.lang.ClassNotFoundException: com.connectina.swing.fontchooser.JFontChooser
    at java.net.URLClassLoader.findClass (URLClassLoader.java:445)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:588)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:521)
    at java.lang.ClassLoader.defineClass1 (Native Method)
    at java.lang.ClassLoader.defineClass (ClassLoader.java:1013)
    at java.security.SecureClassLoader.defineClass (SecureClassLoader.java:150)
    at java.net.URLClassLoader.defineClass (URLClassLoader.java:524)
    at java.net.URLClassLoader$1.run (URLClassLoader.java:427)
    at java.net.URLClassLoader$1.run (URLClassLoader.java:421)
    at java.security.AccessController.doPrivileged (AccessController.java:712)
    at java.net.URLClassLoader.findClass (URLClassLoader.java:420)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:588)
    at java.lang.ClassLoader.loadClass (ClassLoader.java:521)
    at com.cburch.logisim.data.Attributes.forFont (Attributes.java:131)
    at com.cburch.logisim.std.base.Text.<clinit> (Text.java:28)
    at com.cburch.logisim.tools.TextTool.<init> (TextTool.java:36)
    at com.cburch.logisim.std.base.Base.<init> (Base.java:26)
    at com.cburch.logisim.std.Builtin.<init> (Builtin.java:24)
    at com.cburch.logisim.file.Loader.<init> (Loader.java:33)
    at com.cburch.logisim.gui.start.Startup.run (Startup.java:412)
    at com.cburch.logisim.Main.main (Main.java:39)
    at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:254)
    at java.lang.Thread.run (Thread.java:833)

As you can see the system can't find the external library but i dunno how can solve this issue.

[Stephan van Hulst]

Welcome to CodeRanch!

Why are all your dependencies in the system scope?

[Enrico Pinzaglia]

I've read that for jar files the scope must be system. If i try to change it i will get an error.

[Stephan van Hulst]

Using the system scope tells Maven that it doesn't need to do anything to get the dependencies from anywhere, because the dependencies are already available at the path specified by <systemPath>.

It looks like most of the dependencies in your POM are libraries that aren't present in any public repository, so I guess that's the reason that the scope was set to system. This is still not the proper way to do things. Instead, such dependencies should be installed to a public, company or local repository before you build your project.

Anyway, is there a file fontchooser.jar in the lib/ directory in your project? If not, then that is the problem you are having.

[Tim Holloway]

Enrico Pinzaglia wrote:I've read that for jar files the scope must be system. If i try to change it i will get an error.

That's the problem with reading things on the Internet. The Lizard people get on there and post fake information. I read about it on the Internet.

The default scope for Maven dependencies is "compile", which says to pull the dependency jars from a Maven repository for compiling the code and for inclusion in the target. That's usually what you need. Exceptions being things like the JEE jars which are provided by webservers for webapps to use.

[Enrico Pinzaglia]

Stephan van Hulst wrote:Anyway, is there a file fontchooser.jar in the lib/ directory in your project? If not, then that is the problem you are having.

Yes

[Stephan van Hulst]

Can you show us your project's directory structure?

Regardless, even though we might find a solution that preserves your current POM, I STRONGLY recommend installing your dependencies to a local repository (might even be a repository inside your project directory so you can commit the dependencies to source control) and then using the compile scope, as one normally would.

[Tim Holloway]

Stephan van Hulst wrote:Can you show us your project's directory structure?

Regardless, even though we might find a solution that preserves your current POM, I STRONGLY recommend installing your dependencies to a local repository (might even be a repository inside your project directory so you can commit the dependencies to source control) and then using the compile scope, as one normally would.

I don't know about a "repository in your project directory". As as far as I know, Maven only allows one repository per user and if not, it would still make things messy, as it would break Maven's transportability.

As it happens, the CodeRanch JForum software has the problem that a number of critical libraries used to build the app are not in public Maven repositories and cannot be built locally (at least reliably). My solution for Mavenizing the JForum build process was to create an "external lib" directory" in the project, copy those jars there and include scripts/instructions on how to install them into one's local Maven repo before doing builds.

[Enrico Pinzaglia]

Is not my project but a open source project. The directory structure is:

root--+--lib--+---colorpicker.jar
      |       |
      |       +---fontchooser.jar
      |       |
      |       +---JavaHelp.jar
      |       |
      |       +---Logger-1.0.0.jar
      |       |
      |       +---MRJAdapter.jar
      |   
      +--src-+---main--+-java---*
             |         |          
             |         +---resource---*
             |                          
             +---test---java---*

[Stephan van Hulst]

Tim Holloway wrote:I don't know about a "repository in your project directory". As as far as I know, Maven only allows one repository per user and if not, it would still make things messy, as it would break Maven's transportability.

Why does it hurt? I'm pretty sure you can configure multiple repositories, and you can configure a repository path that's relative to the project's base directory, similar to how OP configured their systemPaths. It should not affect the build for different systems/users.

I haven't verified though.

[Stephan van Hulst]

Enrico Pinzaglia wrote:Is not my project but a open source project.

In that case, can you link to where the project is hosted?

[Tim Holloway]

Stephan van Hulst wrote:

Tim Holloway wrote:I don't know about a "repository in your project directory". As as far as I know, Maven only allows one repository per user and if not, it would still make things messy, as it would break Maven's transportability.

Why does it hurt? I'm pretty sure you can configure multiple repositories, and you can configure a repository path that's relative to the project's base directory, similar to how OP configured their systemPaths. It should not affect the build for different systems/users.

I haven't verified though.

A repository has a URL. A local copy of a project does not, unless Maven honors the "file:" protocol in URLs and even then, it would have to be relative to the project directory and not an absolute file URL. Otherwise you break the portability of the POM. Maven has very firm opinions on non-portable resources in POMs.

Maven actually references dependencies from the user's Maven cache, and the location of the cache is determined from the localRepository setting in the Maven config file. It defaults to ${user.home}/.m2/repository/ and must be given as an absolute path. There Can Be Only One. Repository URLs given in the Maven config and/or POM files provide the sources from which Maven will search for dependencies and install them into the localRepository.

Note also that you can't just dump JARs into a directory and call it a repository. Maven expects definite directory structure and metadata. The only safe way to catalog a JAR into a repository is to do a "mvn install" of the artefact in question. The actual internal repository structure is not fixed for all time, and they've changed it once already. Maven tracks this automatically. Assembling a repository manually doesn't

[Stephan van Hulst]

Tim Holloway wrote:A repository has a URL. A local copy of a project does not, unless Maven honors the "file:" protocol in URLs and even then, it would have to be relative to the project directory and not an absolute file URL.

Yes, it allows the file protocol and you can also use a predefined project property to refer to the project directory.

The actual internal repository structure is not fixed for all time, and they've changed it once already. Maven tracks this automatically. Assembling a repository manually doesn't

You can use Maven commands to build the repository, and a project should be bound to a specific Maven version anyway.

[Enrico Pinzaglia]

So if i just understand i have to install the jar files in a local repository and then use them. Is that correct?

[Stephan van Hulst]

Roughly speaking, yes.

If you have a link to the open source project, we might write down some concrete steps for you to follow.

[Tim Holloway]

Enrico Pinzaglia wrote:So if i just understand i have to install the jar files in a local repository and then use them. Is that correct?

Si. Again, I don't recommend making a local repository be part of your project, but if you don't want to do like me and catalog JARs into your Maven cache, you can always set up an independent external repository.

If you're sharing stuff like this between multiple developers, you could also consider setting up a local repository server such as Nexus. That way you can not only keep your "orphan" JARs under Maven control, you get the benefit that the local repo server will cache for the entire user group, reducing the load on the Internet for repo fetches. There are also benefits for DevOps and co-ordination between developers.

[Stephan van Hulst]

So, I just tried this out in a different project of mine:
mvn install:install-file -Dfile=path/to/dependency.jar -DlocalRepositoryPath=repository -DcreateChecksum=true
This creates a folder named repository in your project directory and installs the dependency in that folder.

Then, you can add something like this to your project POM:
 <repositories>    <repository>      <id>central</id>      <name>Central Repository</name>      <url>https://repo.maven.apache.org/maven2</url>      <snapshots>        <enabled>false</enabled>      </snapshots>    </repository>    <repository>      <id>private</id>      <name>Project-specific Private Repository</name>      <url>file:///${project.basedir}/repository</url>      <snapshots>        <enabled>false</enabled>      </snapshots>    </repository>  </repositories>
I explicitly added the central repo, because it ensures that the Maven Central Repository is searched for dependencies first. Only if the dependency can't be found will it look in the project-specific repository. You can swap these two around if you want the private repository to have higher precedence.

I don't really see any issues with this. It's portable, and you don't need separate build instructions for other contributors. If you use the maven-wrapper-plugin to generate a mvnw build script, you can fix the Maven version used for your project and building the project will be as easy as running "mvnw clean install". Contributors don't even need to have Maven installed for this to work.

[Tim Holloway]

Next, install Jenkins as part of the Maven project. (snarf)

I just don't like putting stuff into a Maven project that a basic "mvn install" can't/won't automatically deal with. Especially complex stuff. Especially generated stuff that doesn't generate into the target directory. It mocks the "mvn clean" paradigm. Also the "unzip-and-build-immediately" paradigm.

In any event, all of the above (including what I do) is moot, since for a single project, the better way is to simply put the non-managed JARS into the classpath in /src/main/resources. That also applies to loose classes, if you have any.