I am experimenting the use of Rational Asset Manager to store our binaries and/or build artifacts. I am running a mvn deploy command to deploy my build artifacts to RAM. Although it recognizes the connection its throwing me a Http status code: 500 error.
I have also checked RAM logs for more information but i don't see any specific exception. All the examples or documents out on internet says we have to configure RTC build engine to run the builds.
I just want to know if anyone have tried publishing to RAM from command line using Mvn deploy ( without using RTC client ) ? is this do-able?
If you have successfully published artifacts to RAM using maven, can you please elaborate on how you did it?
It seems to be possible, if you follow the steps described in:
"Creating and using Maven assets", and
"Deploying from Maven to assets":
Before you can use Maven assets, a repository administrator must enable the Maven model library. For more information, see Enabling the Maven library.
The mvn client can integrate with Rational Asset Manager, using Rational Asset Manager as a Maven repository.
Before you deploy from Maven to Rational Asset Manager, you must add a repository entry to the pom.xml file on the computer where you plan to run the mvn client. See Creating and using Maven assets for more information.
I was able to deploy the artifact using mvn deploy after changing the following things in RAM
Pointed to a JRE version in RAM ( originally was pointing to JDK
version) and
Changed permissions for my role for saving my artifacts
in RAM ("save Work Item") Reference
Related
I have Maven2 project. This project have 1 internal dependency which stored in internal (for our company) Sonatype Nexus. I setup the dependency version in pom.xml as parameter which I provide via Jenkins.
Sometimes I do not have proper dependency version in Nexus so my build can fail on donwload dependency step. I want to add ability to trigger special task (script) if dependency is not found to upload this dependency into Nexus and continue the build.
Can I do so?
I think about fake build for version exists always in Nexus which will check if given version is in Nexus, upload it and launch real build. But such way looks terrible.
Thanks In Advance!
You do NOT need to upload anything. You just need to access Nexus via the public group and the download from the Central repository, that is part of that group will happen automatically.
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.
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.
The spring source code examples use maven tomcat plugin and i am able to run these projects using the command mvn tomcat:run but what i dont see the application is not deployed in local tomcat server("C:\apache tomcat\webapps\")..
And how it is different from cargo plugin? (In this case when i ran the command mvn cargo:redeploy, i see the application deployed in the location "C:\apache tomcat\webapps\")
If i add cargo plugin to the POM of spring examples (like mvn-showcase,petclinic)..will it screw up the things?
The spring source code examples use maven tomcat plugin and i am able to run these projects using the command mvn tomcat:run but what i dont see the application is not deployed in local tomcat server("C:\apache tomcat\webapps\")
The command tomcat:run starts an embedded Tomcat, it doesn't deploy an application to your local Tomcat (why does it matter anyway?).
And how it is different from cargo plugin?
Cargo is a container agnostic tool so you could configure it to use a remote container, a locally installed container, an embedded container (as long as implementations are provided for a given container) and still use an unified API (or set of commands).
In this case when I ran the command mvn cargo:redeploy, I see the application deployed in the location "C:\apache tomcat\webapps\"
Cargo doesn't support running Tomcat+6.x in embedded mode. So you are very likely using it with a locally installed container and your app gets physically deployed on it.
If i add cargo plugin to the POM of spring examples (like mvn-showcase,petclinic)..will it screw up the things?
It won't screw up anything, why would it.
You can use tomcat maven plugin and deploy it to external tomcat server.
see this link for all the available goals. tomcat-run will start a embedded server but tomcat:deploy works for external tomcat.
My team uses an internal team maven repo that is shared from a development server using Apache. We also run the Continuum CI server on the same machine. Maven builds in Continuum are run with the "install" goal, which copies the final artifact directly into the shared directory.
The question is, what is the difference between adding files to the shared repo using mvn install and using the deploy goal (mvn-deploy plugin)?
It seems to me that using mvn deploy creates additional configuration hassles, but I have read somewhere that installing files into a shared repo is a bad idea for some reason related to the internal workings of maven.
update: I get the functional differences between deploy and install; I am actually more interested in the low level details in terms of what files are created in the maven repo.
Ken, good question. I should be more explicit in the The Definitive Guide about the difference. "install" and "deploy" serve two different purposes in a build. "install" refers to the process of installing an artifact in your local repository. "deploy" refers to the process of deploying an artifact to a remote repository.
Example:
When I run a large multi-module project on a my machine, I'm going to usually run "mvn install". This is going to install all of the generated binary software artifacts (usually JARs) in my local repository. Then when I build individual modules in the build, Maven is going to retrieve the dependencies from the local repository.
When it comes time to deploy snapshots or releases, I'm going to run "mvn deploy". Running this is going to attempt to deploy the files to a remote repository or server. Usually I'm going to be deploying to a repository manager such as Nexus
It is true that running "deploy" is going to require some extra configuration, you are going to have to supply a distributionManagement section in your POM.
From the Maven docs, sounds like it's just a difference in which repository you install the package into:
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.
Maybe there is some confusion in that "install" to the CI server installs it to it's local repository, which then you as a user are sharing?
"matt b" has it right, but to be specific, the "install" goal copies your built target to the local repository on your file system; useful for small changes across projects not currently meant for the full group.
The "deploy" goal uploads it to your shared repository for when your work is finished, and then can be shared by other people who require it for their project.
In your case, it seems that "install" is used to make the management of the deployment easier since CI's local repo is the shared repo. If CI was on another box, it would have to use the "deploy" goal.