I'd like to have a plugin configuration that will not exist inside the pom.xml file (and also in any project files).
What I want to do is to have a plugin that will be used only by me on my workstation. Specifically, I want to deploy my project onto the Tomcat 7 container and for this I want to use Apache Tomcat Maven Plugin, but since different developers may want to use different servers or entire ways of deployment I don't want to put this configuration into the pom.xml.
Is it possible in Maven to have such global/user-specific plugin configuration?
There are several workarounds that I can think of.
in the pom.xml a specific set for where you define your way of deployment.
ex: mvn goal -P{PROFILE_NAME}
you can just put the plugin normally in pom.xml and just don't push the changes on the repository, so it won't be available for other developers.
But the assumption seems kind of wrong, if you many developers want to work on the same project they should use the same container for deployment for persistence or if you really want to do it like this, I think the cleanest way would be for every developer to use maven profiles. And in your local settings.xml (USER_HOME/.m2/settings.xml)
just set the profile as default:
(...)
<activeProfiles>
<activeProfile>{YOUR_USER_PROFILE}</activeProfile>
</activeProfiles>
(...)
so you don't need to always specify at command line when running mvn your user profile.
Related
I have packed karaf container in docker image, that should be used in test and production. There are different nexus repositories used (the artifacts for production repository are first deployed after successfull test) and I want to control, which repository to use through environment variables, because it's the most flexible solution (and also recommended way of configuring images in OpenShift etc.).
Is it possible to set maven profile that will be used by aether?
There is setting org.ops4j.pax.url.mvn.settings so I could deploy 2 setting.xml files and choose the correct one, but then the test could go through with even incorrect productive maven settings. Profiles seem to be more error-resistant way.
Use Karaf-maven-plugin to build your Karaf distribution.
Define two profiles in the pom.xml of your Karaf distribution.
set the appropriate profile when building your Karaf :
mvn clean install -PprodProfile
mvn clean install -PtestProfile
Start the already builded Karaf assembly: it must point to the good repository.
I am new to maven and read bit about profiles at this and other resources
What i understood we use profile if we want to do override some default values or do some specific stuff.
In my legacy project i can see below profile where i just see overriding app.mode property. But i do not see using this property
further any where in build. I am sure what special being done here?
<profiles>
<profile>
<id>dev</id>
<properties>
<app.mode>dev</app.mode>
</properties>
</profile>
</profiles>
Maven profiles can be configured however you want them to be. Here are some use cases:
a) The project has several developers. For political and religious reasons, some of the developers are using Windows and some are using Linux. The team develops two profiles, one for Linux and one for Windows, setting project root paths, temporary folder paths, support program paths. These variables are injected into the dependency-calculation process, and subordinate processes that need this information. These profile settings are put into the settings.xml file for each programmer.
b) One of the developers is on loan to the project for a week. She doesn't want to reconfigure her computer for the project standard directory layout, etc., so she creates her own settings.xml that allows her to work in her own root directory.
c) The project uses a continuous integration server, such Hudson or Jenkins. The CI needs to have its own database for integration testing, so it would perhaps have modes like "devtest" and "prodtest" and "fulltest", depending on the requirements.
The profile would be activated if you pass -Pdev on the command line to Maven.
mvn -Pdev
See http://maven.apache.org/guides/introduction/introduction-to-profiles.html.
What this profile does is change the setting of the property app.mode from whatever it was before to dev. You will want to search your pom file (and the poms of any modules) for uses of $[app.mode} to see what's happening -- if anything.
Maven properties do not pass into Spring automatically, but it's not uncommon to find configuration in to re-export them as system properties to make them visible to Spring. This typically happens in the configuration for surefire and failsafe, but it's explicit, you'll still see ${app.mode} in a pom somewhere.
If the property being set there isn't used anywhere else in the build (did you check any sub-modules?) then the answer to your question is "In this case it does nothing."
However, in general, setting a property like that will make it available later in the build in case you needed it for something. If I had to guess, I'd say that this is the result of either an incomplete cleanup of code, or premature optimization.
I think your expectation is correct. Its used to pass on app.mode parameter to spring. See
How can I use maven profile Id value in spring bean files?
http://spring.io/blog/2011/02/11/spring-framework-3-1-m1-released/
I currently have a Jenkins instance installed on a Development box. This builds fine and deploys to our development environment without any issues.
During the build process my project makes use of a single properties file containing details such as a database connection URL (Details such as these will obviously vary depending on the environment I'm pointing to).
What I would like to know is what is the best way to configure my project so that when I want to release to Production the WAR file built by Jenkins contains the Production properties instead of Development?
(Note I am also using Maven in my project).
I know 3 options:
We have used maven.-profiles for that in the past, but they have the disadvantage, that the release-plugin of maven doesn't work with profiles, so we had to change the versions manually and were unable to deploy the artifacts in a remote repository like nexus.
Another Option is mavens assembly-plugin. That can be used together with the release-plugin, as far as I know.
We decided to write a simple tool that changes the war-files after the maven-build process. It runs in a seperate Jenkins-Job. The Idea is, that building and configuring are two seperate steps. The Artifacts comming out of maven are always in a default-configuration. And if we need the configuration for the production release we start a jenkins job that does the configuration of the war-files.
You can create different maven profiles, like dev, prod, then in the profile setting, use/filter the corresponding resource files like .../(dev|test|prod)/project.properties And in Jenkins, when you build for different platform, build with -Pdev or -Pprod to get the war for the right target.
You may want to check maven profile, maven resource filtering for detailed configuration.
something not related, connect Database via jndi if possible.
What is the 'best practice' way of separating Maven deployment configuration from the build config?
I have a war project, that is built by Jenkins. I'd like Jenkins to deploy this to Elastic Beanstalk, but alas the best solution available at the moment is to use the beanstalk-maven-plugin.
I'm not sure it makes sense for the POM.xml to include information about deployment; after all, at build time that .war could end up anywhere.
In this situation, is there some way of using Maven modules to store the beanstalk-maven-plugin config in a separate POM to that of the actual software project?
I think you have to solutions.
Just add the beanstalk-maven-plugin definition to your regular pom.xml. The configuration can be stored in separate properties file or provided via system properties in command line (-D option). Add beanstalk goal to command line of maven in Jenkins. So, each build will be deployed on beanstalk. Alternatively you can define yet another project in Jenkins that just runs the deployment without compilation. You can run this deployment project on scheduled basis or via projects dependencies in Jankins.
Create yet another maven project. It will just run beanstalk plugin. I personally do not see serious advantages to do this.
I think about three things:
a. I'm not sure (I'm admit I was a bit busy trying to come up with 0.2.7-RC7), but I think the Elastic Beanstalk Configuration Files are supported in Java.
So it perhaps could be a good idea to separate (I admit managing config in Beanstalker is Boring)
b. Another option is using war overlays in maven-war-plugin's overlay feature, and create a war which depends on your other war.
In my personal case, if you ask, I do have a separate deployment profile in Maven, and that feature often come in handy
I have a muti-module maven project, and I created a new module that depends on 3 other modules. (I already have a web app maven module that produces a .war file, now I need this)
This module's output is a .jar, and it has a few resources also which are:
spring context xml file
properties file
Now I want to produce a production ready folder so I can upload it to my server. I am hoping maven can do this for me.
I need the following layout:
myjar.jar
/libs/ (the 3 other maven modules that are dependancies)
/resources
Also, there are some generic dependancies that my parent pom.xml have like slf4j/log4j/ that I also need to package.
It would be cool if I could add a switch to mvn that will produce this like:
mvn clean install production
I plan on running this on my server via the command line.
I think what you are looking for is a Maven Assembly:
https://maven.apache.org/plugins/maven-assembly-plugin/
You can use profiles to disable the generation of the assembly by default (can speed up the development process).
#puce is right in that you may be best to use the Assembly Plugin. What you can't do easily is add another lifecycle 'production' to maven. If you have time you could write a plugin to do this, but you might be better off using a profile called 'production' or 'prod-deploy' to enable the coping into place on the server.
mvn clean install -Pprod-deploy
One thing to remember with maven is that it is very good at building projects in using it's conventions, but it is pretty bad at actually script things to happen out side of the build lifecycle.
I have on several occasions used external scripting tools such as ant/python/bash and groovy to first run the build using mvn then to script the deployment in a more natural language.
The intention of Maven is building not deployment in the sense to production. For this purpose i would recommend things like Chef or Puppet. From a technial point of view it's of course possible to handle such things via Maven. What also possible to build on CI solution like Jenkins. Furthermore it's possible to run a script from Jenkins to do the deployment on production.