I have a Scala app (v2.13) created using Maven v3. My resources path is:
src -> main -> resources -> application.conf and aplication.prod.conf
When I generate the JAR file for production, I want to take configuration resources from application.conf, but being overwriten by application.prod.conf.
I can not found a solution for that, all founded examples are for Play framework or previous maven versions.
The JAR file is generated using maven package cmd.
application.prod.conf file
include "application.conf"
# override default (DEV) settings
http {
host = "99.999.999.9"
port = 1111
}
The following example doesn't works for me, because from target path I get only the JAR file to move it on production:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<delete file="${project.build.outputDirectory}/application.conf"/>
<copy file="src/main/resources/application.prod.conf"
tofile="${project.build.outputDirectory}/application.conf"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
Few options here:
If your application.prod.cont is static and gets shipped with jar, why cant you have a logic in the code which loads appropriate app conf based on the environment app is getting executed
Is it a typesafe config, if so, while running in prod you can pass -Dconfig.resource=/application.prod.conf java command line argument
or application.prod.conf is not shipped with jar then you can pass -Dconfig.file=/path/to/application.prod.conf
Maven has a concept of phases (we're talking about the phase package here to be precise) which are logical places in the life cycle where the plugins can be invoked. Some plugins, like the one that creates the jar, for example, are associated to phases automatically (out-of-the-box), others you define explicitly and associate with the phase (like maven-antrun-plugin which is executed during the phase package as you've showed in the code snippet).
With that in mind, Is it possible that the file is attempted to get copied after the jar was packaged, so that the antrun plugin is invoked after the artifacts were packaged into the jar?
If so, the easiest solution will be moving it to one phase before, for example prepare-package:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<phase>prepare-package</phase> <!-- Note the change here -->
<goals>
<goal>run</goal>
</goals>
<configuration>
<target>
<delete file="${project.build.outputDirectory}/application.conf"/>
<copy file="src/main/resources/application.prod.conf"
tofile="${project.build.outputDirectory}/application.conf"/>
</target>
</configuration>
</execution>
</executions>
</plugin>
Assuming you have maven 3 (there is no maven version 4 yet so it might be a typo), the information about which phases are available in maven here
Having said that, probably its not a good idea to "bake" the configuration file of production into the artifact, two issues here:
Your source code contains the information about production - hosts, ports, maybe even sensitive information like passwords or keys - this shouldn't really happen
From the point of view of build, your artifact is coupled to concrete environment, which is also considered a bad practice basically.
The techniques to resolve this are beyond the scope of the question but at least you've been warned :)
Related
I was going through this tutorial https://www.youtube.com/watch?v=k5ncCJBarRI&t=1443s
Around 1:07:30 the author mentioned about "Gradle has continuous build" later on was able to detect changes in the test and automatically regenerate asciidoc. I was wondering if anyone knows how to set this up in maven?
I have looked through docs in spring and asciidoctor plugin, but was not able to find anything related to this.
I was able to get maven to re-render html when ever there is a change in index.adoc by changing <goal> from process-asciidoc to auto-refresh. However, this does not watch the change in the Test.
Question
Is there a way to tell Maven to watch our test files and re-compile when changes are made?
POM.XML
<plugin>
<groupId>org.asciidoctor</groupId>
<artifactId>asciidoctor-maven-plugin</artifactId>
<version>1.5.7.1</version>
<executions>
<execution>
<id>generate-docs</id>
<phase>prepare-package</phase>
<goals>
<goal>auto-refresh</goal>
</goals>
<configuration>
<sourceDocumentName>index.adoc</sourceDocumentName>
<backend>html</backend>
<attributes>
<snippets>${project.build.directory}/generated-snippets</snippets>
</attributes>
</configuration>
</execution>
</executions>
</plugin>
Thank you.
This is not a continuous build solution but it works similarly. However, the process does take some time because it essentially re-packages the project everytime there is a change... May not be ideal for some use cases...
I found a plugin that watches files. https://github.com/fizzed/maven-plugins
Change the watch directory to where your test files. Changed the goal from compile to package.
Watcher will execute mvnw: package when a change is detected. Then the asciidoctor maven plugin will re-package the project.
Add this to your plugin
<plugin>
<groupId>com.fizzed</groupId>
<artifactId>fizzed-watcher-maven-plugin</artifactId>
<version>1.0.6</version>
<configuration>
<touchFile>target/classes/watcher.txt</touchFile>
<watches>
<watch>
<directory><directory>src/test/[your test package]</directory></directory>
</watch>
</watches>
<goals>
<goal>package</goal>
<!-- <goal>compile</goal> -->
</goals>
<profiles>
<profile>optional-profile-to-activate</profile>
</profiles>
</configuration>
</plugin>
Maven does not have an equivalent of Gradle's continuous build. If you want changes in the tests to be detected and to trigger recompilation of the tests and execution of all of the tasks that depend (directly or indirectly) on the compiled test classes, you'll have to use Gradle.
I'm just starting with Maven 3 for an Scala project in IntelliJ.
I have generated a JAR file following this guide.
I moved archetype.jar to a directory in where I want to create a new project. But my questions are:
Is this file stand-alone? Is it enough? It does not work with the command "mvn archetype:generate"
Is it possible to use the jar file without the intervention of any repository? So I can share it with collegues.
What's the best method for this, I've been reseaching and all the guides are based on repositories only and not in working local. Even the local repositories only consists in xmls files with the id but not the contents.
This is a sort of complex question you are asking...I am going to try summarise what I know and let's see if it helps.
Answers to your questions:
1) If you have just the basic Maven Project structure after you have generated the archtype and so on, if you run maven clean install and the project produces a jar, this in theory should be immediately executable from the command line and standalone.
However, as you add dependencies to your small projects, not all dependencies are automatically built into the standalone jar, sometimes you have to tell maven to bundle them into it.
Maven Shade Plugin - adds all the needed dependencies into your jar
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>shade</goal>
</goals>
</execution>
</executions>
<configuration>
<transformers>
<transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
<mainClass>MainApp</mainClass>
</transformer>
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
</transformers>
<shadedArtifactAttached>true</shadedArtifactAttached>
<shadedClassifierName>launcher</shadedClassifierName>
</configuration>
</plugin>
</plugins>
</build>
2) You do not need to integrate to any repository, its recommended for wider projects so that you can publish artifacts to your firms Repo for eas of use between developers
3) The easiest method is to create a new project in Intellij itself specifying Maven as the project type and that will give you the default project structure. In the pom file you then specify the build block I pasted above and you are essentially good to go...If you need Dependencies also t run your own code you will need to add them in a Dependencies block.
So, I finally used the following command before generating:
mvn install:install-file -Dfile=<path-to-jar-archetype-file> -DgroupId=<groupId> -DartifactId=<artifactId> -Dversion=<version> -Dpackaging=jar
After executing the command, the jar is installed in your local repo. You can generate the project with for instance IntelliJ or go to the path where you want to generate the project and...
mvn archetype:generate
When using cargo to deploy to a remote server I would like to check with cargo or maven that the generated war have it's properties files filtered like expected.
Some phase in between should test a property file from war against some strings and so deploy or stop deployment.
there's built in on cargo to achieve this?
Not sure what are the properties files you're referring to therefore I assume that you refer to typical java *.properties files.
Anyway, I believe you should use: maven-enforcer-plugin and it's goal: enforce as that is the common way in maven to enforce some condition (the plugin uses term: rule) to be fulfilled.
I think you have more options here.
Option 1
Maybe you could check that prio to packaging to your war using:
maven-property-plugin - goal: read-project-properties (http://mojo.codehaus.org/properties-maven-plugin/usage.html)
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>properties-maven-plugin</artifactId>
<version>1.0-alpha-2</version>
<executions>
<execution>
<phase>???</phase>
<goals>
<goal>read-project-properties</goal>
</goals>
<configuration>
<files>
<file>your_file_to_check.properties</file>
</files>
</configuration>
</execution>
</executions>
</plugin>
where you should:
check the right phase to make sure the file is already filtered (http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html)
reference the file you want to check the properties of
And afterwards go for maven-enforcer-plugin goal: enforce and the rule: requireProperty (http://maven.apache.org/enforcer/enforcer-rules/requireProperty.html)
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>1.3.1</version>
<executions>
<execution>
<id>enforce-property</id>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<requireProperty>
<property>your_property_to_check</property>
<message>You must set a your_property_to_check property!</message>
<regex>regex</regex>
<regexMessage>violation txt</regexMessage>
</requireProperty>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
where:
your_property_to_check should be replaced with the real one as well as
regex should be defined
Option 2
If that is not feasible and you want to check property inside war file, you might need to write your own rule.
That should not be a big deal as java has zip reading as well as properties files loading in it's standard API. To learn how to write custom rule, see: http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html
Btw. I'd be quite curious to understand why would someone want to do check some property on each deployment? Is the case that your input (property files you filter) are dynamically generated/changed? Otherwise I doubt you need it once you check it works.
I have gwt web project, which must use application.properties (on client side) loaded as TextResource in the code. Everything works fine, but now i want to centralize all properties values in maven pom.xml. So i made application.properties with placeholders like key1=${param1} and in the pom.xml i configured property param1Value
So, what happening is that maven replaces the placeholders in application.properties in target dir, but it seems that gwt compiler uses the application.properties file from src/main/resources. I checked the compiled js files and i there i can see that the placeholder is not replaced with its value from the pom.xml (target's application.properties is correct).
UPDATE:
The problem is that, the properties file I am filtering is a gwt messages resources bundle file and from what I saw, maven creates a "generated" folder and puts a generated java file based on the properties file found in the root project sources folder and not in the target folder. After that, it incorporates it in the javascript general file.
This means I have two possibilities:
1) tell the resources plugin to overwrite the properties file located in the sources folder (I am not cool with that because I will certanly have problems on the next subversion update)
2) tell gwt-maven-plugin to seek the properties file in the target/classes folder which I think it is impossible
What do you think ?
I resolved the same problem by using resources:copy-resources execution and build-helper plugin.
In particular, configure the resources plugin:
<plugin>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>filter-sources</id>
<goals>
<goal>copy-resources</goal>
</goals>
<phase>generate-sources</phase>
<configuration>
<outputDirectory>${project.build.directory}/gwt-extra</outputDirectory>
<resources>
<resource>
<filtering>true</filtering>
<directory>src/main/filtered-sources</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
and include it using build helper:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.7</version>
<executions>
<execution>
<id>add-source-gwt</id>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/gwt-extra</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
I managed to use maven filtering on properties files used in GWT compilation.
I use the com.google.gwt.i18n.client.Constants interface.
It allows to instanciate an interface that extends Constants, with methods returning values taken from a properties file.
That properties file can be process by maven filtering.
It's really easy to do :
declare an interface extending Constants : XxConstants
create a properties file XxConstants.properties in src/main/resource in the same package as your interface
activate maven resources filtering so XxConstants.properties is filtered
when GWT is compiling (with gwt-maven-plugin), it will generate an instance of XxConstants using the filtered properties file.
in your gwt code, create an instance of XxConstants with GWT.create or with gin injection
call the methods to get the property values
One caveat : filtering is not working in gwt dev mode
Result can be check in the target.generated folder whiwh will contained the java implementation of the interface with the filtered properties used.
I have successfully set up a few projects which use Maven to automatically deploy the Maven-generated site to the gh-pages branch of their git repository. GitHub then serves these files at a public URL on a personal subdomain. I'm looking to utilize this functionality to serve a rich client-side only GWT application.
I have modified my pom.xml to compile the GWT application to the target/site/ directory. The two main goals I am still attempting to achieve are:
How do I prevent the standard Maven site plugin from running during the site phase?
What is required so gwt:compile executes during the site phase?
A goal can be bound to a phase by specifying a new execution for the plugin. I'm assuming you've got some custom stuff you need to make most of this work correctly, so I'm just going to focus on what should work to bind a plugin goal to a particular phase.
<plugin>
<artifactId>gwt-maven-plugin</artifactId>
...
<executions>
<execution>
<id>gwt-site</id>
<phase>site</phase><!-- phase to bind to -->
<goals>
<goal>compile</goal><!-- goal to run in that phase -->
</goals>
<configuration>
<!-- Your magic configuration stuff goes here -->
</configuration>
</execution>
<!-- Possible other executions might be defined here -->
</executions>
</plugin>
Preventing the default maven site from being run is more interesting, as it is a phase, with a variety of goals bound to it. The standard site:site goal can be prevented from running in the site phase by explicitly specifying an execution with no goals. This may vary slightly from maven 2 to 3, so I'm going to be a little general here. Take a look at your build logs to see what is currently specified in terms of execution id, group/artifact id to correct possible oversights in my example:
<plugin>
<artifactId>maven-site-plugin</artifactId>
...
<executions>
<execution>
<phase>site</phase>
<goals></goals><!-- This is empty to indicate that no goals should be run in this phase -->
</execution>
</executions>
</plugin>