I have two maven projects, which I need to deploy through automatic deployment process. (like nightly build or similar)
Scenario is as:
mv-proj1
-dependency-1.jar
-dependency-2.jar
-dependency-3.jar
mv-proj2
-dependency-3.jar
-dependency-4.jar
-mv-proj1.jar
sources of mv-proj1 and mv-proj2 can not be disclosed.
mv-proj2 is executable jars and provide services to other application modules.
So what is the standard way of deploying these to production machine or lets say UAT machine?
Do I need to set up intra-organization maven repository?
Do I need to install maven repository to UAT machine?
One possible way I could think is to set up and host intra-organization maven respository as well as setting up maven on UAT machine to fetch data from intra-organization maven respository. and deploy only pom.xml.
I would let my choice depend on what the consumers of your artifacts are.
If the consumers are also Maven projects that can pull in your JARs from said intra-organizational Maven repository, that's definitely a great way to go. I believe that every organization that is serious about using Maven is sooner or later going to have use cases for such own repository anyway. I've worked with Artifactory and Nexus and feel that both are great products (and free beer for the use case as stated here). They're both easy to install, and it should not be an exploration that is daunting, go for it!
If your UAT machines would use Maven to build and install anything that pulls in your artifacts as a dependency, them would be running Maven client-side. There would be a local repository (artifact cache) on these clients, but that's a different beast than the organizational repository mentioned above, which you would likely deploy not on the actual UAT machines.
If mv-proj2 is rather a "final delivery", executable as you say, you may want to pack it all up as a nice, single JAR (Maven can do that for you) and distribute that to your users. You could do that again through an organizational repository. You could ultimately release it to some network drive or web server. Many ways to do so, e.g. use maven-jar-plugin with outputDirectory pointing to wherever you want to release.
Related
Is it possible to make the .m2 folder in my local machine a repository so that other team members can use my repository instead of checking anywhere else and get the dependencies from mine? I have seen http://www.sonatype.org/nexus/go but there, we have to upload all dependencies manually.
Can we make .m2 folder (in some machine) a maven repository so others can use it?
The important thing with you local repository is that it's stable. If you were to put it on a shared drive, everytime one of you team builds, the artifacts that the rest of the team see will change - development being what it is, this would be a nightmare as the bugs that are introduced while developing would immediately effect the whole team rather than being isolated to one person (the assumption here is that you have multiple artifacts and build with mvn install).
The correct way to do this is to setup a repo, that proxies the public Maven repos. Both Nexus and Artifactory are setup to do this out of the box and are very easy to install on either Windows or Unix. The proxy feature means that your repo only need contain the artifacts produced by your team and the repository will retrieve other artifacts from the public Maven repos as needed (often storing them for future use).
I am on Netbeans and don't know Maven much. Whenever I import, open some Maven project, it starts donwloading something from some central repository, sometimes huge. It downloads things in .m2\repository.cache\m2e. I have limited bandwidth and don't want this. How to stop this?
I have set Options>Java>Maven>Dependency Download Strategy to never. Also tried mvn -o install and mvn -o for offline. Not solved.
The Maven way is to get you what the project says it needs, but you have not already downloaded to your local repository.
The huge file is the list of what is actually available in Maven Central, and for some reason unknown to me it is downloaded on a regular basis. If you do it once, it should be kept for future sessions.
Maven will download all the dependency only once to the local repository and not again and again.
Weather you have limited or unlimited bandwidth you have to download it to execute your project.
Maven has a very modular architecture. That means the the thing you get when you download the Maven distribution is in reality small core functionality.
The rest is downloaded from a Maven artifact repository, like Maven Central (which is the default repo).
Note that this applies not only for dependencies (the library your project uses), but also your plugins (i.e. the stuff that compiles, packages, and otherwise builds the projects). Hence the large number of downloads.
Like the other answers said, if you don't delete your local repository it should eventually contain all the artifacts (dependencies and plugins) you need without re-downloading. The only exception are SNAPHSOT dependencies which can get re-downloaded periodically, depending what's in your POM and settings.
Ultimately, you have two possibilities:
If you have access to a higher-bandwith connection somewhere, you can build the projects while using it, and your local repo will still store the needed artifacts.
If you have several computers/configurations behind a local network, you can set up a Maven repository manager, like Nexus or Artifactory, and use it as a local mirror. Note that those still need to download the artifacts at first as well.
But there isn't much else you can do. "Maven downloading the Internet" is, unfortunately in your case, by design.
If I were using python I would probably like to use pip as a nice installer for continuous delivery with its nice repository integration and scripting capabilities.
Do I have anything similar in java which would be useful for me in continuous deployment?
Can someone recommend me how they do full continuous deployment in java?
I'm going to have multiple servers with complex configurations and huge multiple clusters with databases, NOSQL's (and using maven for the some of the projects while others are just downloaded pacakges) etc etc... anyone has recommendation for that?
Again I think pip is a very nice installer and could help me, anyone has experience maybe with ubuntu juju?
However if I use ubuntu juju that would mean I would have to use ubuntu based servers and not centos.
There's a kind of bright line between Java app build and Java app deployment. Build CI in Java is pretty straightforward with a variety of tools available - build scripting (Ant, Maven, Gradle, etc), continuous builds (Jenkins, Go, Anthill, etc), and repositories (Nexus, Artifactory, etc). Dependency management for libraries is a hairball for Java, so definitely use Maven or Ivy for it.
Deployment is a much wilder and less mature world. The environments are potentially far more complex, and often include messy non-Java things like relational databases. You can hand-roll scripts, or use ControlTier or Capistrano or something like that (which will still involve some hand-rolling).
I'm not completely clear what pip does, but here is my toolchain for CI/CD
You need a build tool:
Maven (does a lot of stuff, including downloading dependencies and driving you crazy)
ANT (will poke you until you die with xml brackets)
Gradle and others (pretty much everybody including ANT uses/can use Ivy for downloading dependencies from repositories)
You need an CI server
jenkins
various commercial options (Teamcity, Bamboo ...)
For the deploying part you need something to deploy your apps.
This really depends on the build tool you use (which should be able to do the deployment). Maven has some plugins for this afaik, but I think you will have to google for your app server and the build tool to find a solution for your specific need.
Probably what you are looking for is building a deployment pipeline. Check a video example here: http://www.youtube.com/watch?v=6CEQOuHM86Y
There are multiple ways to achieve it. Ill tell you my preferred one.
Components you will need:
VCS server (SVN, Git)
CI Server (Jenkins, Hudson, TeamCity)
Build Tool (Maven, Ant, Gradle)
Artifact Repository (Artifactory, Nexus)
Deployment Tool (Rundeck, Puppet, Deployinator, Capistrano)
Target Environment/s (Application Server like Tomcat, JBoss)
Workflow:
1) CI Server polls VCS Server for changes
2) When a change is found (i.e., a commit), starts job execution, getting an artifact (CI Server will compile and run tests). CI Server internally will use a Build tool like Maven.
3) CI Server uploads artifact to an Artifact Repository
4) Deployment Tool reads Artifact Repository and provides a list of artifacts to be deployed, plus the list of Target Environments where Developer/Ops can select a combination of both and deploy the artifact in the selected server.
Take into consideration some criteria at the moment of picking the tools. If you have a really big infrastructure (like 200+ Target Environments), robust solutions like Puppet make sense. If you have a modest one (let say, 10 Target Environments) then Rundeck may be enough. Also, take into consideration that some of the listed tools are not free (Puppet Enterprise is not free beyond ten nodes, for example).
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 .
EDIT: Ok... so I've gathered that SVN shouldn't really be used for this... which makes sense, I suppose (why version individual files when the version should be a separate jar?).
So we should use an internal server to host a repository management tool like Nexus (etc), and access that over http to pull down and put out dependencies. We are keeping our projects in SVN now. What is the standard for deployments? Dependencies go into Maven. Projects go into SVN. Should we ignore the dist and build folders? Where would our WAR files get deployed from?
OLD QUESTION (for posterity)
I'm brand new to Maven and don't know jack about it. I'm trying to evaluate it to see how it will do with our Java development.
I would like to have a Maven repository in our SVN server so that dependencies can be pulled down from there using NetBeans 6.7. I have not been able to find how to do this throughout many google and stackoverflow searches.
What are the best practices here? I'm thinking that we'd want to download dependencies using svn+ssh, but most things online seem to point to using http.
Fill my brain with great things!
I'd strongly recommend against doing this. Maven artifacts don't belong on an SCM server. You should consider using a repository manager like Nexus to store your artifacts. See here for a comparison of the main repository managers.
Having said that. If you are determined to use Subversion to host your artifacts. See this question on using the wagon scm to deploy to a Subversion repository.
If you want to find out more about Maven, check out Maven: the definitive guide.
There is a Maven plugin for Netbeans that will manage dependencies. This article lists some best practices for Maven and Netbeans.
Update based on your updated question. What to do with your own jars:
Maven has a deploy phase that will publish your artifacts to the remote repository. You need to configure the distributionManagement section of the pom, and provide appropriate credentials in your settings.xml to allow the deployment to happen. Typically you would set up a discrete logical repository on the server for your own artifacts to keep them isolated from third party artifacts. The Nexus book gives some good guidance on configuring repositories on Nexus. In particular see the Adopting a Repository Manager section.
If you have configured your project correctly, run mvn deploy and all phases up to and including the deploy phase will run, and your artifact will be published to the repository, available for use by the rest of your team/company.
If you need to restrict access to repositories, you can configure access controls to your repository so only authenticated users can access those artifacts (for Nexus see the Managing Security section of the book for guidance).
It's worth noting you can do largely the same things (more or less) with Artifactory or Archiva as Nexus, I've included Nexus references because I prefer it, and the documentation is really good.
Don't store them in SVN.
I would do two things to make sure you're not getting too many headaches:
Mirror a repository closer to your box someplace that you and your workmates can share. This will eliminate extra downloading and allow you to fix any problems that may come up (and they will) with the mirrored pom/jar files so your mates don't have to share in the headache. There are several repo managers out there that help with this.
Do your best to work with your machine repository and push changes/modifications to any pom files that you may make to the local shared repo.