I want to change the name of the generated executables in Spring Native with Maven.
Default is the <artifactId> from the pom.xml.
If we want to specify the name of the resulting .jar file, we have an option to configure this with <finalName> inside the spring-boot-maven-plugin plugin configuration.
Is there a similar configuration property to allow the same behavior for the native-image-plugin?
I just found a solution using <imageName> inside the native-image-plugin configuration like:
pom.xml (only part of file shown)
...
<plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<imageName>app</imageName>
</configuration>
...
Related
I wanted to do a very simple thing which I had already done, which is using a spring boot packaged jar with some custom properties (private.properties containing a token) provided in a "config" directory. Currently I'm using a recent version of Spring Boot ("2.2.5.RELEASE").
My "config" directory was never taken into account and I had to do 2 very unintuitive things :
Complete spring boot maven plugin conf like this :
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<mainClass>${start-class}</mainClass>
<layout>ZIP</layout>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
and add these properties :
java -Dloader.home=. -Dloader.path=config -Dloader.config.name=private -jar my.jar
Could someone please tell me where is it officially documented (both actions) ? Is there a more simple way of doing this with less explicit parameters ?
Here is the answer :
"ZIP (alias to DIR): similar to the JAR layout using PropertiesLauncher."
source : https://docs.spring.io/spring-boot/docs/current/maven-plugin/reference/html/#repackage
and :
"PropertiesLauncher is a launcher for archives with user-configured classpath and main class via a properties file. This model is often more flexible and more amenable to creating well-behaved OS-level services than a model based on executable jars.
Looks in various places for a properties file to extract loader settings, defaulting to loader.properties either on the current classpath or in the current working directory. The name of the properties file can be changed by setting a System property loader.config.name (e.g. -Dloader.config.name=foo will look for foo.properties. If that file doesn't exist then tries loader.config.location (with allowed prefixes classpath: and file: or any valid URL). Once that file is located turns it into Properties and extracts optional values (which can also be provided overridden as System properties in case the file doesn't exist):
loader.path: a comma-separated list of directories (containing file resources and/or nested archives in *.jar or *.zip or archives) or archives to append to the classpath. BOOT-INF/classes,BOOT-INF/lib in the application archive are always used
loader.main: the main method to delegate execution to once the class loader is set up. No default, but will fall back to looking for a Start-Class in a MANIFEST.MF, if there is one in ${loader.home}/META-INF.
"
source : https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/loader/PropertiesLauncher.html
I have a JHipster generated application with an YAML property file that looks like this:
storage:
location: ${user.home}/my/folder
My problem is that the variable ${user.home} is resolved at build time, when I run mvn package (on Jenkins). So the property is already resolved in the resulting artifact, hence when I deploy on on my server, that path contains the resolved home of the user Jenkins.
Anybody know who is doing this and why? I was expecting that the variable would be resolved at runtime.
Thanks.
Valentin
I'm not totally sure of how JHipster builds on top of Spring Boot, but my guess would be that it's Maven's resource filtering that's expanding ${user.home} at build time. It's enabled by default by spring-boot-starter-parent for application.properties and application.yaml in src/main/resources.
This Spring Boot issue contains some more information, along with details of a configuration change that you may like to make so that ${…} entries are no longer filtered:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<version>2.6</version>
<configuration>
<encoding>UTF-8</encoding>
<delimiters>
<delimiter>#</delimiter>
</delimiters>
<useDefaultDelimiters>false</useDefaultDelimiters>
</configuration>
</plugin>
I have to build java projects for different java versions. I'm using maven. I would like to specify all JDK locations in one configuration file (probably settings.xml) and then maven should choose correct one based on maven-compiler-plugin configuration specified in the pom and use compiler and standard library from this JDK to build project. Is it possible? I understand that I can use something like
JAVA_HOME=jdk6path mvn package
but it's not convenient.
Yes its possible. In settings.xml define properties like this:
<properties>
<java.home.1.4>C:\Program Files\Java\jdk1.4</java.home.1.4>
<java.home.5>C:\Program Files\Java\jdk1.5</java.home.5>
<java.home.6>C:\Program Files\Java\jdk1.6</java.home.6>
</properties>
Then in your POM file specify the properties
<compiler.source>1.6</compiler.source>
<compiler.target>1.6</compiler.target>
<compiler.compilerVersion>1.6</compiler.compilerVersion>
<compiler.jdk>${java.home.6}</compiler.jdk>
Then int he Maven compiler plugin pass in the executable:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${compilerPluginVersion}</version>
<configuration>
<source>${compiler.source}</source>
<target>${compiler.target}</target>
<compilerVersion>${compiler.compilerVersion}</compilerVersion>
<executable>${compiler.executable}</executable>
</configuration>
</plugin>
You then control which is used by the properties. You can also set up different profiles in the POM with different property values to allow you to run the build with different versions without any change required to the pom.
I want to read a maven variable for configure a build plugin from a properties file. It's not needed in and further project files e.g. context files.
1) made a profile (it works, can use mvn ... -P private)
<profile>
<id>private</id>
<properties>
<env>private</env>
</properties>
</profile>
2) created the filter file with this content (it works)
foo.path=/home/foo/path
3) try to configure the plugin (does not work)
<build>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>foo-plugin</artifactId>
<version>${foo-plugin.version}</version>
<configuration>
<!--<fooPath>home/foo/path></fooPath> that works -->
<fooPath>${foo.path}</fooPath> <!--works not -->
</configuration>
...
</build>
Thx a lot
The name of your property is 'env' but you don't use env anywhere in your configuration.
When Maven docs mention "filter files" they usually mean a file used when processing resources (i.e. copying resources from /src/main/resources to target/classes). As far as I know the properties in those files aren't used for plugin configuration out-of-the-box. I have used the Codehaus properties-maven-plugin:read-project-properties goal do do what you are attempting. Make sure you bind the goal to the lifecycle before any plugins that need the properties for config.
Also, see this answer; you may load properties used to configure other plugins, but not to configure core Maven project elements.
Applications built on top of the NetBeans platform have a <myappdir>/etc/<myapp>.conf file determining, among other things, application JVM parameters. Historically, this file was a part of the NetBeans IDE installation (as far as I could tell), but starting with NB 6.9, custom files are now supported.
I am having trouble packaging a custom configuration file using Maven to build the application.
I imagine the app.conf property should have been set in the project's pom under project/build/pluginManagement/plugins like so:
<plugin>
...
<configuration>
<brandingToken>${brandingToken}</brandingToken>
<cluster>${brandingToken}</cluster>
<appConf>myapp.conf</appConf>
</configuration>
The maven module representing my application contained no prior source, so I created the src/main/nbm folder and placed myapp.conf in src/main/nbm. This isn't picked up by nbm-maven-plugin. and putting the conf file into src/main/resources doesn't make a difference.
So, can anyone explain how a NetBeans Platform application with a custom configuration file can be built using maven?
UPDATE:
With Tim's prod in the right direction, I found the answer documented on Geertjan's blog. The solution is to configure the nbm-maven-plugin like so in the application module pom:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>nbm-maven-plugin</artifactId>
<configuration>
<etcConfFile>src/main/resources/my.conf</etcConfFile>
</configuration>
</plugin>
</plugins>
</build>
BTW, if you need a second name with Geertjan, you're not really a NetBeans platform developer. ;)
Have a look at the documentation of the nbm:cluster-app plugin, specifically the part on the conf file.
As per my understanding that should allow you to replace the default one with a custom one that you create.