How do I exclude a properties file when deploy - deployment

I want to include this file when running locally, but exclude it when deploy. I tried the following the doesn't seem to work.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
<configuration>
<excludes>
<exclude>filename.properties</exclude>
</excludes>
</configuration>
</execution>
</executions>
</plugin>

You should put that property file into src/test/resources than it will be available for Unit testing etc. but it will not being deployed.

I want to use this property file in development, but in production, I want to be able to use a different file.
There are several ways to achieve this but this is a perfect use case for profiles (and optionally filtering).
The Building For Different Environments with Maven 2 page explains how you could manage different property files and use the Maven Antrun plugin to pick up the "right" one depending on the profile used.
Instead of using the Antrun plugin, you could declare environment specific values as properties in different profiles in your POM and use Maven filtering. See Using Maven profiles and resource filtering for a full example. This is especially nice if you need to protect some informations (that you can "hide" in a profile inside ~/.m2/settings.xml). See also Tips and Tricks for an illustration of this.
Or, instead of putting properties inside profiles, you could put them in "filter files" and apply the right filter depending on the profile. This is a little variation of the above solution. See A Maven2 multi-environment filter setup for an example.

Related

Overwriting application.conf using Maven and generating jar file

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 :)

Karaf - generating feature file and creating custom distribution

I have an application which I want to deploy in karaf. I have created a feature file and I am able to add features through this file using karaf console. What I want to achieve now is that create this feature file through maven commands instead of creating it manually and then create a custom karaf distribution using this feature file. How can I achieve it ?
My approach so far is to create a maven module for generating feature file using karaf-maven-plugin and then create another module to generate karaf custom distribution so that we dont need to access maven in production environment.
Is this approach correct ? Do I really need to make two different modules for achieving it. How can I get access to feature file from second module.
These are my poms -
all dependecies
<build>
<finalName>${project.artifactId}-${project.version}</finalName>
<plugins>
<plugin>
<groupId>org.apache.karaf.tooling</groupId>
<artifactId>karaf-maven-plugin</artifactId>
<version>4.0.5</version>
<extensions>true</extensions>
<executions>
<execution>
<id>generate</id>
<phase>generate-resources</phase>
<goals>
<goal>features-generate-descriptor</goal>
</goals>
<configuration>
<startLevel>80</startLevel>
<aggregateFeatures>true</aggregateFeatures>
<includeTransitiveDependency>true</includeTransitiveDependency>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
I am not able to figure out the second part yet. Any help with that is really appreciated.
To generate a custom Karaf you just need to use the karaf-maven-plugin.
For example the following will generate a fully working custom Karaf:
<plugin>
<groupId>org.apache.karaf.tooling</groupId>
<artifactId>karaf-maven-plugin</artifactId>
<version>4.0.0</version>
<extensions>true</extensions>
<configuration>
<!-- no startupFeatures -->
<bootFeatures>
<feature>minimal</feature>
</bootFeatures>
<installedFeatures>
<feature>wrapper</feature>
<feature>spring/4.0.7.RELEASE_1</feature>
</installedFeatures>
</configuration>
</plugin>
This will generate a custom karaf based on the minimal sets of features which are needed to create the minimal distro. If you want to depend on the standard distro just exchange that with standard.
Btw. all this is also documented in the Karaf documentation

Check war file before deploy / conditional deploy

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.

What is the correct way to specify a main class when packaging a jar using m2eclipse?

Problem:
I'd like to specify the main class in a jar file that I am packaging using m2eclipse: [right-click] -> Run As -> Maven package. I'm still learning Maven and from what I've read, the straight-up way of accomplishing this task is to add a stanza to the pom.xml.
Here are examples I found when I was researched this issue:
Cannot make executable jar using m2eclipse
http://docs.codehaus.org/pages/viewpage.action?pageId=72602
My question is this: is it okay to manually edit the pom.xml file outside of Eclipse/m2eclipse using a text editor, or should I be doing this configuration using the m2ecplise GUI? There are several tabbed dialog boxes that seem like they might be likely candidates for this task, like "Plugins" and "Build". I looked through Sonatype's documentation and couldn't find any detailed instructions on how to accomplish what I need to do.
I'm a little hesitant to edit the pom.xml manually because I notice the "Effective POM" already has a lot of extra stuff in it, including the plugin definition that needs to have added to it:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>default-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
If I understand correctly, the Effective POM needs to be changed so that the plugin is configured like this:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.3.1</version>
<executions>
<execution>
<id>default-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
<configuration>
<archive>
<manifest>
<mainClass>[name of main class]</mainClass>
<packageName>[package name]</packageName>
</manifest>
<manifestEntries>
<mode>development</mode>
<url>${pom.url}</url>
</manifestEntries>
</archive>
</configuration>
</plugin>
Is this right? And if so, do I do this through m2eclipse or should I just copy all the extra Effective POM stuff and paste it into the actual pom.xml using a text editor?
Thanks to anyone who can shed some light.
UPDATE: I went ahead and manually edited the pom.xml file in a text editor. When I viewed Effective POM in m2eclipse it displayed everything that I put in (I assume). I built the jar and the main class was correctly set.
This seems like a hack to me though. Does anyone know if there's a way to do this configuration using m2eclipse itself? I checked the m2eclipse tabs and nothing seemed to have been updated as a result of my manual edits of pom.xml (other than the Effective POM tab).
m2eclipse doesn't do everything for you, i.e. there isn't a pretty UI tab for handling everything.
My team is most comfortable with editing the POM manually, and using the other tabs for verification (like Effective POM view).

Replace Maven Site Plugin with GWT Compile Plugin

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>