Currently I have a simple maven project that is building a jar file and putting it inside target/some-1.0.jar when i run mvn install.
I want to copy this file to another location when I run mvn deploy.
Currently the location is on the same machine, but it would also be great if the solution could be applied for multiple targets, some of them being on other machines (scp deployment).
What is the easiest solution to do this? I would be nice, if you could include an example too.
Details: I have few jira plugins that are compiled as jar files and I just want to be able to run a single maven command that would copy the files to the server and eventually restart the server.
mvn deploy is intended for deployment to a remote Maven repository. mvn install is used for copying to the local Maven repo (so actually, the jar is also ending up in $HOME/.m2/repository, as well as target).
I'm not sure what you're intending to do, but I suggest you look at deploying something like http://www.sonatype.org/nexus/ if you want Maven artifacts to be available to multiple machines. This will integrate nicely with the rest of Maven.
Edit: based on your updated question, it's probably best to investigate the Wagon ssh plugin, or see if there's an Ant plugin. A suitable phase would be pre-integration-test: install and deploy should be run after you've run your integration tests to check the artefact works as expected. Use profiles to distinguish the local vs. remote cases.
Related
I just figured out, how to release to CB hosted maven "release" repository. I am trying to figure out, how to deploy tagged version to CB application.
I understand, I can manually upload WAR file but is there any script. As far as I know maven plugin for CB doesn't support it.
I have one appserver is running snapshot builds from jenkins.
I have other appserver, which I want to deploy only tagged/released artifact.
There are four ways to deploy applications to the CloudBees RUN#cloud service:
Using the bees command provided by the SDK
Using the bees-maven-plugin
Using the manual upload via the web GUI
Using the CloudBees Deployer plugin for Jenkins
Which option you choose depends on where the deployment will take place from... And the from I am talking about is which machine is doing the deployment not where the file is sourced.
If running from a Jenkins job, the best bet is the Jenkins plugin.
If running from your own laptop, the web ui or the bees command is simplest.
If running as part of a maven build, the maven plugin is simplest... (Though I should warn that the maven plugin (temporarily removing my cloudbees hat and putting on my maven PMC hat) is shite and does it all arsewise ;-) )
Your best bet is to set up a Jenkins job that uses dependency:get to pull the artifact from the repo and then add a cloudbees deployer build step to push to RUN#cloud
The good news is that bashing the maven plugin into something more maven like is on our roadmap... Hopefully that will enable actions like you can achieve with the ship-maven-plugin#mojo where you can specify a specific released version for "shipping" to production.
I suppose, that what you want to do is to deploy a release artifact to your repository.
have a look at maven-release-plugin.
Briefly, what you need to do is:
$ mvn release:prepare
$ mvn release:perform
it's not so trivial, since you need to configure appropriately your pom.xml to get it working. Have a look at the maven-release-plugin examples and usage pages.
Are you creating the tag/release from a Jenkins build? If so you could probably use the Deploy to CloudBees post-build step with target/checkout/something.war.
More generally I guess you would want to write a script to use mvn dependency:get followed by the Bees SDK to obtain the latest released artifact and deploy it.
how would i get maven to deploy my app for me.
i want to be able to type
mvn deply:devserver (or something like that) and have it do the following things
SCP all dependency jars to the remote devserver/var/lib/tomcat6/shared/company folder
SCP the war file to the remote devserver/var/lib/tomcat6/webapps folder
and since i can already hear the statements/questions "why are you doing it like this, you can just build the war with dependencies in it" bla bla bla i will answer. this server is going to be running about 35 different war files (be gentle i inherited this project) all using the same dependencies so i don't see the point of having the tomcat classloader loading the same 50 or so libraries 35 times. id rather have tomcat load them on startup and share them with the webapps.
and NO, manager is not installed on this instance of tomcat so please don't go there. security guys wont let us install the management console on a publicly visible server so all the deployments must be via SCP file copies.
i could do this in about 5 minutes with ant and i havn't eliminated the possibility of simply writing a shell script to do it but i would like to give maven a chance first.
You should script the 'deploy' of the code to the server. If you choose to use Ant, do it, but Maven is not the right tool for this job.
The Maven 'deploy' goal is used to deploy built artifacts to a repository server for other projects to be able to download as dependencies. It is not the 'deploy' you are thinking of.
If you really need this done by Maven though, there is a maven ant plugin which lets you run Ant tasks in Maven and you could bind this to your deploy step. I would advise against this though because it very much goes against the conventions of using Maven as a build tool.
I would like to know weather there is a way/plugin to build a project with maven using a remote pom.xml(http://host:port/pom.xml) with out a pom.xml file in the directory where I run "mvn install".
I need this as I want to effect maven dependencies of multiple clients by making changes to one remote file hosted at (http://host:port/pom.xml).
I am not aware of a way to do this. Generally, if you are doing development with multiple developers, you should be using source control. For example, if you are using subversion, you would just make changes to the pom, commit, and the other developers can update.
Of course using a version control is absolutely necessary...It would quite helpfull to use a Maven Repository Manager to interchange the artifacts with each other simply by deploying the artifacts to a central Repository Manager in your company and furthermore it will increase the build time.
If you are on Windows, you can try mapping the remote location (possibly a network share or an FTP location) to a local drive, and then executing the maven command in your console for the mapped location. It should work.
Else, you can distribute the pom.xml file via an email and ask the users to use it as their project file.
The other option is to use a Version Control System (VCS) such as Mercurial and keeping your pom.xml stored in the repository and make it accessible for the users to checkout. So far, this is the best way to make sure everyone is using the same file.
I have done an mvn install for a custom plugin and it gave me a bunch of directories in my target directory along with a jar. I'm stuck with the next step.
How do I bundle it?
Where do I place this?
What about the pom of this plugin?
What configuration changes do I have to make and where?
You can always test it on your local machine. Just run mvn clean install and it will be installed in your local repository. Then in the project you'd like to use it from, just add the plugin to the plugins section and set it up like any other plugin. This should be enough.
If you'll be using it in your company, you'll need to be able to deploy it to a Maven repository such as Nexus or Artifactory in order for other people to be able to download it.
Deploying it is the same as for regular artifacts:
mvn clean deploy
I have a project that's using the Play framework, and the corporate standard is that all projects should be built by Hudson. However, I cannot find out how to do this, as Hudson does not follow any Java standards, and requires the framework installed at the computer it runs on. I have tried to build the project with Maven (if I had managed this, adding it to Hudson should be quite simple), but I have failed to make it work. I tried the Play Maven module, but Maven claims it does not find the external repo that is listed (http://nexus.infin-it.fr/content/groups/public). This might be because I am behind a firewall. I also tried the recipe listed here, but the local maven build fails because it is unable to find org.playframework:play:1.1:jar.
Has anyone done this and can provide a howto?
It can be done without installing the Play framework on the Hudson server, but it is quite complicated:
Put the play libraries (play.jar and its dependencies) in a Maven repository
Create a pom.xml for your project, configured with:
theses libraries as dependencies
your project specific dependencies (project lib directory)
the java sources folder of your project (in the maven-compiler-plugin): "app"
If your project is simple (no module dependencies), this pom allows you to build the play project java sources using Maven.
If your project has module dependencies, you will have to add the dependencies jar in your pom dependencies.
To do that, you will have to create jar files from the modules if they don't have packaged jars (to get the "CRUD" class of the CRUD module for example).
You can find some help on this page I wrote :
http://blog.infin-it.fr/2010/12/15/play-framework-integration-continue-retour-dexperience/
Even if it's in French, I put my Ant stuff and the Play's pom I wrote.
At work we managed to integrate our Play applications with Bamboo.
It should not be difficult with my files.
Just looked at the repository, that you linked (http://nexus.infin-it.fr/content/groups/public). And guess what, I found the play-1.1.jar. However, the artifact ID is: org.play:play:1.1:jar and not org.playframework
In theory, you could put the full Play zip on your build or in in your repository, and then use Hudson to kick off an Ant script to download Play to the Hudson agent, unzip it, and then run commands on it. It's a little clunky, but it should work.