I need to use the oracle database driver (oracle.jdbc.driver.OracleDriver) for a project but Oracle does not have a Maven repository for it, so the only way that I have found is to download it onto my machine and then "install" the .jar to Maven as seen in this article.
However, now it is time to add the project to my work's Bamboo build server, but of course the build fails because it can't find the oracle driver.
My question is: how is this sort of thing generally handled? There doesn't seem to be a way to "add" a .jar to a Bamboo build and then point Maven on Bamboo to that .jar. Another alternative that I'm trying is putting the oracle .jar on an internal git repository but I don't know how to point Maven to pull a .jar from a git repository (my current understanding is that maven repos and git repos are different thing entirely).
Any tips or suggestions appreciated, thank you.
The usual way is to set up a Nexus/Artifactory on a server. This server is used for the built artifacts (your Bamboo deploys the EARs/WARs/JARs to it), to proxy external repositories (not necessary, but will speed up things) and to manage third party jars that are not available elsewhere.
In your settings.xml you just point to this Nexus/Artifactory and do the same for the Bamboo.
Related
We are using our git server for project management. How do I download maven project dependency from my git server?
For project checkout/pull and push we are using tortoise git
Clarification:
We are using another project as a submodule in our project. That project available on our local git server. So, when the new update is available I have to download and copy in m2 repository manual. Instead of a manual process, I want to download from my local git server.
Storing jar artifacts in git is a bad idea. Git is not meant for binary files. Use a maven repository server like Nexus or Artifactory instead.
EDIT: I admit that this answer lacks background and explanation. So I added a little.
Most sources I know do not recommend to put (large) binaries into git repositories because checking out the git repository means checking out all old versions of the binaries and that might be a lot of stuff.
There are specialised solutions (Maven repositories like Nexus/Artifactory) for the task at hand which can be directly used by Maven without giving URLs to separate artifacts (the URL of the repository suffices to find all artifacts in it).
AFAIK GitHub and GitLab offer services to provide Java artifacts as Maven repositories. So if you use on of these services, you probably have cheap other option.
I have a Maven project with several dependencies, all taken from the Maven repo. The project is hosted / stored in VSTS and uses CI. All bar one of the dependencies were available from the Maven Repository online so now I have to find a way of adding this .jar file to this project (and VSTS for the CI build) and making Maven recognise and use it.
Can anyone point me in the right direction?
Thanks
If you don't have or want a Nexus/Artifactory, I would install the jar on every relevant account/computer with the help of the Maven install plugin (see https://stackoverflow.com/a/4955695/927493).
But let me stress that it is standard practise to have a Nexus/Artifactory running in the company - there are free OpenSource versions, and they are easy to set up. Furthermore, you have a canonical place for the artifacts you create yourself.
You should be able to create your own feed with the VSTS Packages Extension.
See here for instructions how to setup a feed and publish an artifact to the feed.
This is an alternative to Artifactory and is no extra cost to your existing VSTS.
I am new to java web development and the book I am using to learn uses Maven and Tomcat for development. After searching some basics about Maven on internet all I know is that it is a tool for managing dependencies in project. I am using Netbeans 8 and every time I create a new project or clean-build an existing project Maven downloads lots of files. Is there any way I can keep a common place/repository for all my Maven projects which can be used locally? I have gone through some existing answers on stackoverflow but for me as a beginner they are difficult to understand.
Maven indeed has such a local repository (in .m2/repository in your home folder) where the files found to be needed are downloaded are automatically stored for future use.
The source repository - Maven Central - is very large, so you do not want to download everything as you will most likely not need most of it.
If you need to go offline, or want to be sure that everything you may need in your current build, you can run the dependency:go-offline target. You can then safely use the -o switch to maven to avoid network usage.
When you create a Maven project and build it for the first time, Maven will automatically create a local repository for you, downloading the necessary jars for your project to this location. From then on, all your maven projects will share this repository.
On Windows, the default location for your local Maven repository is
%HOMEPATH%\ .m2\repository
You will find this page useful: http://maven.apache.org/guides/mini/guide-configuring-maven.html
You can also download 'Maven the complete reference' for free as a PDF from here: http://www.sonatype.com/resources/books/maven-the-complete-reference/download
I have a big war file over-sized due to lots of external dependencies & also I have internet connection speed issues because of which I don't want to keep the dependency jars in my war, so that I could reduce war size & do faster uploads of my updated wars from dev machine to remote server.
I would like the maven project to instead download the dependencies on the remote tomcat server itself when it has been uploaded there & starts running. How do I configure maven to do that ?
There is a pretty simple solution: Build the project on the server.
An easy way to do this is to put all the sources into a version control system like Mercurial or Git.
In addition to giving you a history and an automated backup, DVCS have insanely efficient algorithms to update remote copies (they just transfer the changes, so if you change a single line, only one line is sent over the wire).
Building on your server also means that you get the very fast download of dependencies on the server (which has probably very good download rates). And local deployment will be very, very fast.
Last but not least: When you use version control, you will be able to go back to the last stable version quickly when something goes wrong.
As Aarom says you should build the project on the server directly.
There are two requirements:
You need to have a command line access on the remote server.
Maven must be installed on the remote server.
Then you can upload the sources of your project on the remote server (without dependencies).
Go in the root directory of your project and run your build command (mvn package or whatever custom build command that you use).
So that's it, you have the .war on the remote server loaded with all the dependencies; you can then remove the source files.
#user01
Install all desired 3rd-party jars to Tomcat's lib folder.
Set the scope of those dependencies to "provided" in you Maven pom.xml.
Install Maven on your remote server.
Install a CI server such as Jenkins, Continuum, Bamboo, Hudson, CruiseControl, etc. I'd suggest Jenkins.
Hopefully, you are using revision control software such as SVN, Git, Mercurial, Bazaar, or CVS. If not, then I'd suggest setting up
Git or SVN for your source code repository.
Configure the scm tag in your pom.xml to point to your project's location within your source code repository.
Configure your CI server to get your pom.xml from your source code repository. Your CI server will read the scm tag, and the
URL's you've configured within the scm tag, and will check your
project out. Your CI server will then build your project.
You can either have Jenkins deploy your built war artifact to Tomcat via the Jenkins Deploy Plugin, or you can use a Maven plugin such as the
tomcat7-maven-plugin or Cargo.
I'm confused about the use of maven in development and production environments - I'm sure it's something simple that I'm missing. Grateful for any help..
I set up maven inside eclipse on my local machine and wrote some software. I really like how it's made things like including dependent jars very easy.
So that's my development environment. But now I want to release the project to production on a remote server. I've searched the documentation, but I can't figure out how it's supposed to work or what the maven best practice is.. Are you supposed to:
a) Also be running maven on your production environment, and upload all your files to your production environment and rebuild your project there? (Something in me baulks at the idea of rebuilding 'released' code on the production server, so I'm fairly sure this isn't right..)
b) use mvn:package to create your jar file and then copy that up to production? (But then what of all those nice dependencies? Isn't there a danger that your tested code is now going to be running against different versions of the dependent jars in the production environment, possibly breaking your code? Or missing a jar..?)
c) Something else that I'm not figuring out..
Thanks in advance for any help!
You're supposed to have your code under version control (and you never "upload" files to another machine, you "download" them from the Version Control System if required).
You're supposed to package your code in a format (a WAR, an EAR, another kind of bundle) that can be deployed on the production environment for execution. Such bundles typically include the dependencies. To build more complex bundles, the Maven Assembly Plugin can help.
Maven generated artifacts (JARs, WARs, whatever) should be shared via a remote repository (and thus deployed - I mean mvn deploy here - to this remote repository). A remote repository can be a simple file system served via a web server or a more advanced solution like Nexus.
Development is usually done using SNAPSHOT dependencies (e.g. 1.0-SNAPSHOT). At release time, you're supposed to change the version into a "fixed" version (e.g. 1.0) and some other bits from your pom.xml, run the build to check that everything is ok, commit the modified pom.xml, create a tag in the VCS, promote the versions to a new SNAPSHOT (e.g. 1.1-SNAPSHOT) in the pom.xml, commit the new pom.xml in the VCS. The entire process require some work but this can be automated using the Maven Release Plugin.
On the production environment, get the artifacts to be deployed from the remote repository and deploy them (some projects automate the deployment to the production server using Maven but that's another story).
Of course, there are variations around this (deployment to production is most of time company specific) but the general idea is there.
You need to look into the Maven Assembly Plugin and the Maven Release Plugin.
When building artifact you usually state what scope the dependency has. In default scope it should be packaged in your archive. If you do not want it, use scope "provided" - in such case you have to prepare runtime environment providing the dependency. It's generaaly a bad idea to rebuild a package only for deployment.
As for deploying, you can use maven's antrun plugin to copy files locally or via scp .