I have a bundle:
<groupId>com.helloworld</groupId>
<artifactId>Helloworld</artifactId>
<version>1.0.0-SNAPSHOT</version>
Previously, the bundle and OSGi container(FUSE ESB Enterprise) are at the same machine. I use the following command to install it from local maven repository:
FuseESB:karaf#root> install file:/home/li/.m2/repository/com/helloworld/Helloworld/1.0.0-SNAPSHOT/Helloworld-1.0.0-SNAPSHOT.jar
Now the bundle and OSGi container are at different machine:
bundle in a machine where IP is 192.168.122.22
How can I install this bundle remotely?
Notice that the argument to the install command is a URL. So you can install from any URL for which you have a URL handler available. For example:
install http://www.example.com/helloworld-1.0.jar
For Fuse ESB or more general for Apache Karaf based servers you have the pax url mvn uri prefix. This allows to install bundles from mvn repositories. I propose to always use this uri instead of the file one.
In your case the command would be:
install mvn:com.helloworld/Helloworld/1.0.0-SNAPSHOT
This uri is even a little smaller than the file based one. The big adavantage though is that you have the full mvn resolution available. So this above url will work for bundles from your local maven repo but also from maven central.
Of course you typically will not deploy your own artifacts to maven central. So if you want to use this inside your company you should set up a maven repository like Nexus or Archiva. Then you deploy your own bundle using mvn clean deploy into your company repo. Of course this will require that you set up your pom correctly but you will need that anyway for any larger project.
The last step needed is then to set up your Fuse ESB / Karaf to also use your company repo. This is done by adding the repo uri to the file etc/org.ops4j.pax.url.mvn.cfg.
Of course this is a little more work than the http url that Neil proposed. THe advantage is that this will integrate very well with your maven build process and it will make your bundle mvn uris independent of the location of your maven repo. It will also allow you to mix your own bundles and open source bundles when you start to combine them using features.
Related
I am setting up a maven repository for my workplace. The main reason for setting up a new private repository is that, our original nexus repo is hidden behind a VPN network. So anyone who wished to pull the dependencies. He needs to have a VPN connection in the working machine. Goal is to make the VPN secured artefacts under the newly created repo to make it available for CI pipeline.
Right now I am doing it as below, listing all the dependencies using following command:
mvn -Dmdep.copyPom=true dependency:copy-dependencies
Which send all the jars under target/dependency.
And then I using the following maven command:
mvn deploy:deploy-file
Which pushes all the dependencies in my newly created nexus, issue is that during setting deploy-file command I am passing a group id which is a generic one. And all the jars are pushed under that groupid. Which is different than my local name namespace/groupid, as different packages are under different group id and pushing all of them under a same group id makes them unusable as it messes with the namespace.
I am new to maven, and the approach I took feels like a hack. Can I use maven native functionality to solve the problem? What would be the standard way to solve the issue?
Nexus has a concept of proxy repositories , for the open source dependencies, you can create proxy repository to mirror the maven central repo and provide in the proxy information is maven settings and run a mvn install, during the resource generation phase of maven the nexus will automatically pull artifacts from the central repo and cache them in your proxy repository for future use.
I have a maven project which I build and deploy on a private remote repository. The code is built through continuous integration pipeline.
This repository is accessible from my remote machine. What I want is to pull the artifact and execute it on this remote machine without pulling the source code for the project.
From what I can understand, one needs a pom file which contains this repo, as a dependency, but is their any other way of doing the same without having to download the sources
If it is possible for you to have just one file to download pushed to Artifactory (I assume you are using artifactory from the tag) it is possible to download the file with a simple http get request (via Artifactory REST API), like curl, or even use the JFrog cli.
I recommend using the CLI: https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory
To use Artifactory REST API directly go to:
https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API
Retrieve Artefact api or Retrieve Latest Artefact can be helpful.
you can simply download the file using CLI provided that you have maven installed. Below is an example command.
call mvn org.apache.maven.plugins:maven-dependency-plugin:2.4:get -DrepoUrl=<your nexus url> -Dartifact=<groupid>:<artifactid>:<version>:jar:jar-with-dependencies -Ddest=<destination>
Have you tried the exec-maven-plugin ? http://www.mojohaus.org/exec-maven-plugin/examples/example-exec-for-java-programs.html
That is if you want to do the job with Maven (it is not very clear to me if you do or do not want to use Maven on your remote machine).
Note : repacking the dependencies in your executable jar would not be a good practice. You can still build a distribution archive along with your jar (look at the maven-assembly-plugin https://maven.apache.org/plugins/maven-assembly-plugin/) and use that archive instead.
I have an Android app which uses a library of my own. I am developing them at the same time so when I have a change in my library I want to test it in my app as well.
They are setup as different projects since my library will also be used by other developers. The way we work is we build the library using a CI platform adn deploy it to an artifactory server.
Then from the app I reference this library directly through artifactory. This way when my CI platform builds the app, the build process takes the lib from artifactory and CI works smoothly.
This is a good way to work but is a pain in the ass when developing them in parallel, because I have to commit the changes, create a pull request, merge it with the development branch and wait for CI to build it and deploy it on the artifactory server, just so I can test it on the app.
Coming from java EE development, I used maven install, which deploys the artifact in the local maven repo, then I could already use it from my web application.
I want to do soemthing similar, i.e. have gradle deploy my artifact on my local repo, so the artifact on the local repo is updated but not on the remote one. This way I can debug more easily while still keeping the CI setup in place.
But I have no idea how to do this on gradle. The artifactory plugin seems like it only allows deployment on an artifactory server.
any ideas?
If you're using the maven plugin, you can run the install task to deploy the artifacts to your local Maven repo [1]. After you have the Artifacts deployed to your local maven repo, you need to add mavenLocal() [2] as one of the repositories to be able to resolve the dependency. One strategy I use is to always set a custom version for my local copy so that I can be certain that the local version is getting picked up - but if you choose not to do that the dependencies get resolved in the order the repositories are listed (so you'll need to ensure mavenLocal is before your Artifactory server).
[1] https://docs.gradle.org/current/userguide/maven_plugin.html, https://github.com/dcendents/android-maven-gradle-plugin
[2] https://discuss.gradle.org/t/how-to-use-maven-local-repository-for-gradle-build/2244
How can I automatically deploy a war from Nexus to Tomcat?
I have a maven web project which gets built and deployed (both SNAPSHOT and release versions) on Nexus successfully. I would like to know if there is feature/plugin in Nexus where it picks the released war and deploys on remote Tomcat automatically?
I know that you can deploy the war to remote Tomcat using maven-tomcat-plugin but would like to know if there is an alternative solution.
Please guide.
Typically you'd use a CI tool like Jenkins to run the Maven build that publishes your War file into Nexus. Nexus would then be used by whatever tool you're using to push the War onto the target tomcat environment:
There are lots and lots of options.
Jenkins post build SSH script
Run a post-build SSH task from Jenkins that does something like this on the target tomcat server:
curl "http://myrepo/nexus/service/local/artifact/maven/redirect?r=releases&g=myorg&a=myapp&v=1.1&e=war" \
-o /usr/local/share/tomcat7/webapps/myapp.war
service tomcat7 restart
Rundeck
My preference is to use Rundeck for deployments, because it has a Nexus plugin, providing convenient drop-down menus of available releases.
There is also a Rundeck plugin for Jenkins that can be used to orchestrate a CI process with Jenkins performing the build, hand-over to Rundeck for deployment, followed by a Jenkins call-back to run the integration tests.
Chef
I also use chef which can be used to automatically deploy software in a pull fashion.
The artifact cookbook has direct support for Nexus, whereas the application_java cookbook uses a more generic "pull from a URL" approach that also works well.
..
..
The list goes on, so I hope this helps.
We used UrbanCode for the deployment automation, retrieves war from Artifactory/Nexus and deploy to the target server.
I used the Nexus Rest-API, these endpoints downloads the artifact to Jenkins workspace.
In order to deploy Snapshot & Release to Tomcat we can create a Jenkins parameterized job and pass the parameters to the REST endpoint, also to deploy to a server like Tomact "Deploy WAR/EAR" Jenkins plugin will help.
We can parameterize the endpoint and use as part of "Build" step along with "Execute Shell script" option for the build.
wget --user=${UserName} --password=${Password} "http://192.168.49.131:8080/nexus/service/local/artifact/maven/redirect?r=releases&g=${GroupId}&a=${ArtifactId}&v=${Version}&e=${TypeOfArtifact}" --content-disposition
Actual endpoints to Nexus looks something like below.
wget --user=admin --password=admin123 "http://localhost:8080/nexus/service/local/artifact/maven/redirect?r=snapshots&g=org.codezarvis.artifactory&a=hushly&v=0.0.1-SNAPSHOT&e=jar" --content-disposition
wget --user=admin --password=admin123 "http://localhost:8080/nexus/service/local/artifact/maven/redirect?r=releases&g=org.codezarvis.artifactory&a=hushly&v=0.0.5&e=jar" --content-disposition
Thanks
-Sudarshan
I am trying to setup a Maven Nexus Server for my firm to share common JARs that we build inhouse. I use my workstation (call it workstation 1) to build the common JAR and I then do a mvn deploy to deploy it to the Nexus Maven Server. Then I add it in the dependencies in the pom.xml of the project that needs it and I do my mvn package and everything is great.
Now if I change the common code and I run mvn deploy with the same version number and then rerun the mvn package on the second project, it will see the changes and everything is great.
Now lets move to workstation2. If I do a mvn package on the project that needs the common code everything is fine. But if the common code changes and I rerun the mvn package command it looks like it's going to my local repository on the workstation and using that version, not the new version in Nexus!
So my questions are the following...
Does mvn deploy save a copy in the local repository before the nexus repository?
How do I make the project check the nexus repository for the most up-to-date file before the local repository on the workstation?
The code is a accept SNAPSHOT so I would like it to be updated each time the user try to access it.
1) maven consult the local repository and only for a miss it aks the online repository (nexus)
2) I do not know
Anyway: (Except for SNAPSHOTS) you should not modifiy a released artefact without updating its version too!
You can run mvn -U package. With -U Maven will always check the repositories (in your case Nexus) for newer SNAPSHOT versions of your dependencies.
You can also add a configuration to your settings.xml to look always for new versions of dependencies. See the Settings reference, the configuration is named <updatePolicy>always</updatePolicy>
I got it.. I had to add always to the snapshot settings in my settings.xml