We Keep Coding

How to add GRAALVM PATH in maven pom file JavaFX

I have used GRAALVM to compile native JavaFX apps. in commands ports. Here I want to do the same thing using maven.
I have GRAALVM latest version install in C and added the Environment variable as the name GRAALVM_HOME. and in PATH %GRAALVM_HOME%\bin but when I Run client:build-in IntelliJ. it says GRAAL_PATH didn't find.
I tried to do it with the client plugin.
<plugin>
<groupId>com.gluonhq</groupId>
<artifactId>client-maven-plugin</artifactId>
<version>${client.plugin.version}</version>
<configuration>
<target>${client.target}</target>
<mainClass>${main.class}</mainClass>
<bundlesList>
<list>com.example.sample.main</list>
</bundlesList>
<reflectionList>
<list>com.example.sample.MainController</list>
</reflectionList>
<graalvmHome>GRAALVM_HOME</graalvmHome>
</configuration>
</plugin>
inline graalvmhome I set to add the entire path that's didn't work. then I added a GRAALVM_HOME in it. but this didn't work either.

it's <graalvmHome>path to graal</graalvmHome> where path to graal is the path in your local machine e.g. /home/user/graal

How do I update the Maven configuration in Eclipse Luna?

I am using Java 8 for my JRE in Eclipse Luna with with the m2e Maven plugin. I see this warning as soon as I create a Maven project: Build path specifies execution environment J2SE-1.5. There are no JREs installed in the workspace that are strictly compatible with this environment. I see lots of older advice on this site on how to deal with this error, but nothing related to Java 8. I also that Oracle says J2SE was deprecated in 2008. The most promising answer I have found thus far comes from #Pascal Thivent here:
Warning - Build path specifies execution environment J2SE-1.4
But these instructions no longer seem to be relevant for Luna:
Eclipse project Properties > Maven > Update Project Configuration
I only see "Lifecycle mapping" under Maven.
Can someone please explain (1) what this error means (2) if it is still a worry, given that J2SE-1.5 seems to have been deprecated (3) how to best fix it in Luna?

This error is because the project pom file is instructing maven to compile against java 1.5.
It is best to compile and test to a current java version. In your case java 8.
I am unsure how to fix it inside the eclipse IDE, but the project pom file can be edited to include the compile version as follows:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>

How to identify maven artifact for different Java versions?

I have a maven project that is compiled for both Java 1.7 and for Java 1.6.
The 1.7 jar is the default artifact, but I don't know which how to identify the 1.6 jar.
I could add a suffix to the artifact id, to the version, or set a classifier.
Which is the preferred way? What happens when another project A depends on the 1.7 jar, project B depends on the 1.6 jar, and project C depends on A and B?

OK, so after some reading, I think classifiers are the way
From the maven docs
classifier:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that clients can choose which one to use.
Then to solve the issue of forcing one jar over an other, in project C's pom, use the <dependencyManagement> section and specify the classifier there.
Hope this helps

you have to declare in pom.xml file the java compiler version:
<build>
<finalName>skremm_mobile_web</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
</plugins>
</build>

How to resolve Maven exec plugin: classpath too long error?

I have a large Java project with a large number of jar file dependencies. When I try to run the project (using exec) from Eclipse or Netbeans, Maven throws an exception which turns out to be a too large number of entries on the classpath (only 2/3 of the needed entries are included). Does anyone know a workaround for this? (Except from building an executable jar and running it from terminal.) Is it possbile to "extend" the "classpath-buffer"-size?

This is a Maven exec plugin bug, it is documented in MEXEC-68, the reporter created a patch so I hope it will be resolved soon.
One workaround would be to add the classpath to the manifest file using this config for the maven-jar-plugin, add the dependencies to a folder and add just that folder to the CLASSPATH envvar.
For example:
<project>
...
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
...
<configuration>
<archive>
<manifest>
<addClasspath>true</addClasspath>
</manifest>
</archive>
</configuration>
...
</plugin>
</plugins>
</build>
...
</project>
This will add to the manifest something like:
Class-Path: plexus-utils-1.1.jar commons-lang-2.1.jar
If that JARs are in a CLASSPATH folder, you can run your JAR using maven exec plugin hidding the classpath with something like:
mvn exec:exec [...] -Dexec.classpathScope="test"
I used -Dexec.classpathScope="test" to make the plugin ignore the dependencies and add just the ones in scope test.

This problem is fixed in Netbeans 6.10M1. Please take a look at Bug 188864. If you have an older version, you can still fix this yourself (you just have to edit an xml file inside org-netbeans-modules-maven.jar).
Then, don't forget to check Maven Best Practices (http://wiki.netbeans.org/MavenBestPractices#Binding_Maven_goals_to_IDE_actions) where it is explained how to bind maven goals to IDE actions.
Regards,
Mach

In Java 6 (which I hope you use) you can use wildcards in classpath entries. For the exact syntax check this page Setting the classpath and search to the right section by searching for "Understanding the class path and package names".
Or you try shortening the paths by placing all required jars in a single folder with a short path. e.g. C:\jars\

Creating a self-contained source release with Maven

Up until now we used Ant in my company. Whenever we wanted to send the application to the client we run a special Ant script that packaged all our source code with all jar libraries and Ant itself along with a simple batch file.
Then the client could put the files on a computer with no network access at all (and not even Ant) and run the batch file. As long as the computer had a valid JDK the batch script would compile all the code using the jars and create a WAR/EAR that would finally be deployed by the client on the application server.
Lately we migrated to Maven 2. But I haven't found a way to do the same thing. I have seen the Maven assembly plugin but this just creates source distributions or binary ones. Our scenario is actually a mix since it contains our source code but binary jars of the libraries we use (e.g. Spring, Hibernate)
So is it possible to create with Maven a self-contained assembly/release/package that one can run in a computer with no network access at all??? That means that all libraries should be contained inside.
Extra bonus if Maven itself is contained inside as well, but this is not a strict requirement. The final package should be easily compiled by just one command (easy for a system administrator to perform).
I was thinking of writing my own Maven plugin for this but I suspect that somebody has already encountered this.

From your dev environment, if you include the following under build plugins
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
</plugin>
and invoke mvn assembly:assembly, you would get yourApp-version-with-dependencies.jar in the target folder. This is a self-sufficient jar, and with a Main-class MANIFEST.MF entry, anybody can double click and run the application.

You might try this approach:
Use mvn ant:ant to create ant build
scripts from a maven project
Make sure ant is a project dependency
Use the assembly to build an ant
system
or plan b:
Use mvn ant:ant to create ant build
scripts from a maven project
Make sure ant is a project dependency
Write a "bootstrap class" to call Ant and run the build
Use appassembler to build a
scripted build and install environment
In plan b, you'd write scripts to set up a source tree someplace from the packaged source jars, and then use the appassembler build bat or sh scripts to call the bootstrap and build via ant. Your bootstrap can do anything you need to do before or after the build.
Hope this helps.

Perhaps an answer that I submitted for a similar question could be of some assistance. See Can maven collect all the dependant jars for a project to help with application deployment? The one piece missing is how to include the source code in the assembly. I have to imagine that there is some way to manage that with the assembly plugin. This also doesn't address the inclusion of Maven in the distribution.
What was the reason for moving from Ant to Maven? It sounds like you had everything worked out well with the Ant solution, so what is Maven buying you here?
If it is just dependency management, there are techniques for leveraging Maven from Ant that give you the best of both worlds.

the source plugin will give you a jar containing the source of a probject "source:jar". you could then use the assembly plugin to combine the source jars from your internal projects (using the sources to reference these source jars) and the binary jars from the external projects into one distribution.
however, as for turning this into a compilable unit, i have no suggestions. you could certainly bundle maven, but you'd need to create a bundle containing all the plugins you need to build your project! i don't know of any existing tool to do that.

This is how I do it... on the build part of the pom add in this:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<phase>verify</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
And then on the profiles section add this bit in:
<profiles>
<profile>
<id>release</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
And when I do a maven install it builds the jar and also checks in a jar of the source.