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.
Related
I am setting up Maven corporate repository using Apache Archiva for my company.
Our requirements for now are quite basic - have an internal repo for our jar files and dependency management.
I want to make sure that Archiva does not upload any of our proprietary code / jar files to Central Repo (Public), but we would like to be able to download public libs from central repo if needed by the project.
(Our desired configuration: IDE/Developer <Download/Upload> Internal Repository <DOWNLOAD ONLY> Public Central Repo.)
My question is, by default, does Archiva upload my jar files to central repo if its configured as a proxy/mirror? if so, how do I prevent publishing to central/external repo while keeping the option to download from central when needed?
Appreciate any answers.
If you configure the local/managed repository which is linked to Central as read-only, then nobody can upload to it. This is done by only giving the "Repository Observer" role but not the "Repository Admin" (in fact you will most likely add additional roles, just make sure none of them is assigned for any developer to one of the mirrored repos).
BTW: you can also disallow re-deploy (aka overwrite of artifact versions) for a repository. This is generally a good idea. This is done in the repository settings (not by roles).
One additional thing you might want to look for: if you configure a repo to be Snapshot only, it still will accept SNAPSHOT uploads. This can be quite confusing, make sure nobody does that.
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.
I'm a long time Eclipse user but new to Git/Egit. Recently I've been trying to use Egit because I want to use GitHub to collaborate with a number of projects. The projects I want to work on are not Eclipse-specific projects but I'd still like to set up a workflow so that I can work on them in Eclipse.
It seems that there are a number of things that need to fit together:
The remote repository (on GitHub)
The local repository (somewhere on my filesystem)
The Git working directory
The Eclipse project that I want to work in (including stuff outside the source tree like Eclipse project files, Maven config, build folders etc.)
How do these relate to each other and what should be my workflow?
In particular:
Do I actually need a local repository or can I just work directly with the remote repository (like with SVN)?
Can the Git working directory also be the Eclipse project? Or is this a bad idea?
What should my workflow of push/pull/fetch etc. normally be?
If I use Maven for dependency management in the Eclipse project, but don't want all the Maven-specific stuff to get committed to SCM, can this work?
Guess I'm loking for some sound advice from someone who's successfully made this work!
Do I actually need a local repository or can I just work directly with the remote repository (like with SVN)?
Git is all about working on a local repository and pushing elsewhere when necessary.
Can the Git working directory also be the Eclipse project? Or is this a bad idea?
If it lines up this way, then yes. This is how I've managed my projects.
What should my workflow of push/pull/fetch etc. normally be?
You push when you feel you have made enough commits (sometimes only 1) that are worth pushing. You pull when you want to work with changes that other people have pushed.
See gitworkflows for the official doc on different types of workflows.
If I use Maven for dependency management in the Eclipse project, but don't want all the Maven-specific stuff to get committed to SCM, can this work?
Usually you just commit the pom.xml. Anything else is a user specific setting. Although, if I clone your repository and can't do a "mvn compile", then there's something wrong.
we use Gradle for building Java projects and at the moment we have Ivy repositories to store third-party artifacts and also to publish our own artifacts into (repo is build using Gant scripts and the Ivy ANT tasks). but repo management is basic.
Gradle is able to work with a maven repo as well, so switching to a Maven artifact manager like Archiva or Nexus is an option, but perhaps unnecessary. do you know any tools or best practices than can help us in building and maintaining Ivy repos?
just to be clear: we have already read the tutorials and more and understand how to do it, but it's still basic to maintain.
In the past, I've only used an ivy repository for small private repositories publishing artifacts using simple low level protocols like an FTP site. (All the site needs is a versioned directory layout and an ivy.xml file describing the arifacts)
The maven based repository infrastructure is now so pervasive, with some many projects using it, it's almost pointless to promote an alternative repository management standard.
Sonatype (company behind Maven) make their repository product, Nexus, available to all, because it's in everyone's interest to keep the band-width requirements to Maven central under control.
Thankfully, ivy plays nice with Maven meaning you can take advantage of the best of both worlds.
I've created a blog entry about my Ivy repository layout and choices. You might have different requirements, but I think it is always good to check other's solutions to get some ideas...
There's a community project called Ivy Roundup that aims to build a consistent, up-to-date ivy repo of common third party libraries. It may be a good idea to match the naming conventions used there, or even better, just get modules from there using the <ivy:install> task.
In my opinion there isn't much in Ivy's repository to work with because it just works. What you can't do with Ivy's Ant tasks you can do directly from the file system, simple as that.
Admittedly something like changing the artefact name can be difficult but then again that's something you shouldn't do anyway.
What I am typically doing in practice when I need a third-party library is to search for it in the MVN repository and then click on the "Ivy" tab to get the Ivy dependency for my ivy.xml.
I am getting tired of manually installing javax jar files in Maven and would like to know what is the best solution to include a dependency on javax.cache, javax.transaction, or other JSRs that are not easy to find in Maven repositories.
Have you seen https://people.apache.org/~ltheussl/maven-stage-site/guides/mini/guide-coping-with-sun-jars.html ?
This link suggests groupID and artifactID's to use, as well as a java.net repository.
It looks to me like almost all of these exist in the central Maven repository under this naming scheme.
I'm not aware of one, but adding the java.net repository may help you with some of these dependencies:
<repositories>
<repository>
<id>java.net repository</id>
<url>http://download.java.net/maven/2</url>
</repository>
</repositories>
If building on more than one box and/or for team development, a local (intranet) maven repository manager can help with these "missing" jars. This centralizes the configuration and management of not only 3rd party jars that are not in a public repository, but also all external repositories in general. It could also help automate your builds, creating more 'reproducable' builds (e.g., if you have a pool of continuous integration servers).
install a mvn repo mgr (see list -- imo, nexus is really simple to start with);
use a custom settings.xml that includes a "mirrors" section pointing to your intranet mvn repo mgr. Either update your ~/.m2/settings.xml, or run maven with "mvn -s etc/settings.xml"-- useful for hudson builds, where you don't want a custom per-user settings.xml;
manually upload your 'problem' jars to your internal repo (again, super-simple w/ Nexus via a web-interface);
set up the internal mvn repo mgr as a "mirror" of repo1.maven.org/maven2, codehaus, java.net, ... (etc).
Now, you can centrally define all 3rd party repositories & 3rd party jars -- rather than requiring each person, each box and/or each project define them individually in their pom or settings.xml. Each project / person / box would ONLY define your central, internal maven repo as the single repo for all maven projects.
This also really speeds up your artifact re-download time for fresh builds, or for those times when you need to (or would like to) delete your local ~/.m2/repository cache.
Repo managers: nexus, archiva, artifactory... e.g.,: maven.apache.org/repository-management.html
- http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix
javax.cache are in jcache:jcache:1.0-XXX artifact (in Maven's central repo)
<dependency>
<groupId>jcache</groupId>
<artifactId>jcache</artifactId>
<version>1.0-dev-2</version>
</dependency>
javax.transaction.* classes are in javax.transaction:jta:1.1 artifact, JTA jar can’t be inserted in the Maven repository because the Sun’s Binary License (I know, this sucks). To use it you need to download manually the JAR (it's free) and put it into a local repo or use 1.0.1B version which is contained in java.net.
NOTE: I've read in some place JTA will be integrated in future versions of the JDK
I know is really a pain to find these artifacts in Maven's repositories but you can make a search of a class in www.mvnrepository.com and it will show you the correct groupId and artifactId for mostly all the packages.
In the particular case of JTA, I hit this post:
http://www.jugpadova.it/articles/2005/11/26/maven-2-spring-and-jta-depencies
.. which makes sense, if I didn't have to spend a lot of time in Oracle's horrible site to get the forementioned JAR file. (I was an Oracle's enthusiast myself but that site could use a lot of UX rework here and there).
I decided to replace the dependency with what Hibernate provides, via Geronimo, as per this post (worked perfectly):
https://forum.hibernate.org/viewtopic.php?p=2420836
The deal with Java licensing and Maven is currently being worked on by the Hibernate team, or so it seems here:
https://hibernate.onjira.com/browse/HHH-4548
Thanks to everyone for sharing!