I am somewhat new to Maven but we are successfully using Bamboo to deploy to Tomcat using Maven and Tomcat7 plugin. However I want a separate Bamboo build plan that only deploys a war package from Nexus, does not re-build it first. Looks like I could make the war a dependency but this same POM builds the package, so I don't want it downloaded in the case that a build goal is called.
Look at the maven-dependency-plugin. It should be easy to have a project grab an existing war artifact and push it to tomcat.
Nexus has a very rich REST API that you could easily use to script the deployment with a simple http get and a copy. However if you really feel like you want to use Maven ptyx approach should work ... although it seems like overkill. If you invest into effort for deployment I would look into using Chef or Puppet instead and use them to pull from Nexus and push into your production (or QA or whatever servers).
Related
I will need to load 200+ external jars( form my local harddisc) into Springboot REST project. Tried many approaches but none of them are working, Much appreciated if someone has solution.
Note: Please do not suggest mvn install or system scope as i need to construct artifacts for 200+ jar's which i dont like to do manually
Tried google add jar's plugin too its just copying the ${basedir}/lib/*.jars into my Maven target folder but not found in runtime.
If your company works with Maven, it should run a Maven repository server like Nexus or Artifactory. When someone builds artifacts, they should be deployed to the Nexus/Artifactory and can then easily be read from there.
If this is not the case and you do not have a Nexus/Artifactory, you need to either install the JARs in your local repository (mvn install:install-file) or you need structure them in the standard repository layout (like log4j/log4j/1.2.17/log4j-1.2.17.jar) and import this directory as repository.
In any case, this will be a lot of manual work (as you already said).
I want to publish my maven artifacts to standard maven repositories. For that the first example I chose is bintray Jfrog. Unfortunately this didn’t go well.
I had to add two hacks.
Remove existing artifacts if pushing same version again
Delete some corrupted versions after maven publish
The entire code can be found at https://github.com/pPanda-beta/cassandra-java-driver-reactive-mapper/blob/4b1395db443facb188ed4aee120c6db7864908b7/cassandra-java-driver-reactive-mapper-reactor-core/build.gradle#L93-L122
The uploaded artifacts are at https://bintray.com/ppanda-beta/maven/cassandra-java-driver-reactive-mapper-reactor-core
Why maven-publish?
The main objective here is to keep maven artifactories as a standard specification not specific to any provider. I want to represent an repo as { url, username, password } . The way of publishing should not change based on the repo provider.
PLEASE DO NOT SUGGEST ANY OTHER PLUGIN THAN 'maven-publish', I DONT WANT TO USE com.jfrog.bintray or com.jfrog.artifactory PLUGINS WHICH ARE VERY SPECIFIC TO BINTRAY JFROG.
What is wrong with current solution?
It is hacky. It is no better than jfrog gradle plugins. The solution is already using custom hacks which are not valid for other maven repos.
Why not switch to Jfrog altogether ?
The future of those artifacts is to reside in a more popular and standard maven repo like : maven central, github maven repo, ...etc. So anyway I'm gonna leave jFrog in near future. Till that time comes, I want to standardise the gradle script to work with any maven repo. This is very similar to docker container registry. Whether it is global docker hub or redhat cr or google cr, we use the same docker clients.
We are currently migrating from Nexus to Artifactory and one thing we are missing is an API call to resolve maven dependencies in artifactory. Nexus has this endpoint /service/local/dependency?r=snapshots,releases&c=&e=pom&s=compile&f=list&g=<my.group>&a=<my-artifact>&v=<my-version> which gives a compiled list of all, including transitive, depdendencies.
We need this because we (mis)use maven as a generic deployment/versioning system to create artifacts (zip files of shell scripts actually) and to manage depenedencies. These dependencies are also necessary for production deployments.
Since we migrate from Nexus we don't have builds accessible and I am not yet sure if we want to use them. Is there a way to get a rest endpoint like the nexus one in Artifactory? Maybe a user plugin? Any hints on how this could be done?
How can maven be configured to support this type of workflow:
One Time Setup Invoke maven to do one time setup of a developers machine such as
Create a custom version of tomcat configured for this application
Create a local postgres database on the developers machine
load sample data into the database
run a junit test to configure other resources needed to run the application
Integration Tests Invoke maven to do run integration tests which should do the following
Create an integration test db
setup the db
Run command line integration tests against the db
Run a test version of tomcat with the application in it
Run command line junit tests that test the restful services exposed by the application
Release Build Invoke maven to do a release build of the system
do all the steps for an integration test
generate resources and configurations that are used on the server rather than production
deposit the end result in a git repo, commit, and push the changes to production
Test Build Invoke maven to do a test build of the system
do all the steps of a release build but configure the test release package with test server configuration
The main thing I am struggling with is that maven has a single build life-cycle with a well defined sequence of phases not sure if the workflow I want to build is a good fit for maven.
Can maven be configured for this type of workflow? If yes what are the key features of maven that allow for the different configurations of the four main ways that I want to use maven?
Update What I mean by this workflow, is that I want to be able to do something like
mvn setup
mvn integration
mvn prod-release
mvn test-release
I know the above example look like ant, I am long time ant user and total noob with maven.
You could setup Maven to do all that...
You probably would use (shock horror) profiles to achieve some of this...
BUT you don't want to do that
You are following ANT style thinking... if you like that style of thinking then use ANT or Gradle and be happy.
If you want to follow the Maven way, then you will solve the problem differently.
Coming from the Maven way, here are my thoughts:
Why do you need one-time setup? I usually have a run profile that dynamically provisions the correct application server and starts it with the App deployed, tearing down everything afterwards when I hit ^C. Typically this involves starting up a database server or two... hence things I have developed like the cassandra-maven-plugin. That way when I am working on a different project (which could be in 10 minutes time) I don't have to worry about background database servers eating up all my laptop's ram.
Integration tests are actually trivial when you have the above working... in fact I created the Maven Failsafe Plugin to make it easy to have plugin execution tied to the appropriate phases for integration testing. The Maven convention is to have a profile called run-its for running integration tests.
Release builds being different from test builds... ugh! You should be building environment agnostic artifacts. Have them pick up their configuration from the environment they are deployed in. That removes the worry that something has changed between the "test" build and the "production" build. If you really need to bundle the config, then I usually would resort to a separate module for taking the agnostic artifact and rebundling with the required configuration. That way it is easy to prove that you have a reproducible transformation and that nothing has changed inbetween what went to QA vs what is going to Ops.
I always make the release builds include the integration testing.
So typically I have my projects such that
$ mvn -Prun
will fire up the application starting from zero. Hitting ^C will tear everything back down again, and mvn clean or in extreme situations if I have a more complex setup process and need some caching mvn post-clean (think really clean) will remove anything that the run profile put into play
To run the integration tests I typically do
$ mvn -Prun-its verify
To make a release I typically do
$ mvn release:prepare release:perform -B
That is (in my view) the ideal way of handling the above steps you need.
HTH.
BTW I have not had to use PostgreSQL specifically (typically my integration tests and run profile can get away with a pure java database such as derby or hsqldb and because the artifacts are environment agnostic it is easy to have the integration test/dev flyweight app server inject the correct JDBC url) so you may hit some issues with regard to PostgreSQL
I'm confused about how Archiva fully works. I understand that if we had a core set of dependencies, we could use Archiva as our local maven repo.
The thing I don't understand, is how Archiva manages build artifacts from your own projects.
Say I have a multi-module maven project - we can even use the one from the Sonaytpe for example. http://www.sonatype.com/books/mvnex-book/reference/multimodule-sect-building-multimodule.html
What if I wanted to have one team working on the Simple Model app, while I wanted another to work on the Simple webapp. But I didn't want either to have the projects they AREN'T assigned to, in their local workspace. Webapp needs Model to build, but I don't want the Wepapp team having direct access to Model.
Is there any way Maven can detect that the build artifact for Model wasn't in a Webapp dev's workspace, and pull it from our local Archiva repo, so they can still build the Webapp despite not having the model (maven module project) code in their workspace?
The Model project will be like any other third-party dependency and be downloaded by Archiva automatically, provided
the Webapp project specifies Model project as a dependency
the Model project is deployed to Archiva periodically (by a Continuous Integration system or other means).