I have some proprietary.jar that I need to include in my project, but I don't wish to install it to the local repository.
What I did initially was to put the jar into version control in my project's lib/ folder, and then specify the Maven dependency as:
<!-- LOCAL DEPENDENCY -->
<dependency>
<groupId>topsecret</groupId>
<artifactId>proprietary</artifactId>
<version>0.0.1</version>
<scope>system</scope>
<systemPath>${basedir}/lib/java/proprietary.jar</systemPath>
</dependency>
However, this becomes a big problem when my project becomes someone else's dependency. Maven will not be able to validate this POM because the path is not absolute.
What is the best way to overcome this problem?
I think the first question that needs to be answered is, why don't you want to install it in the local repository?
Maven follows a convention over configuration philosophy, so the more you fight "The Maven Way" the harder things are going to be for you. Unless you have a compelling reason for not installing the jar to the repository, that seems like the best solution to me.
If you are concerned about unauthorized users gaining access to the proprietary jar, there are alternative solutions such as using a repository manager like Nexus or Archiva.
I described in a previous answer how you can setup a file based repository and avoid the evil system scope when you can't use a corporate repository. Check it out.
For third party artefacts, it's cleanest and least pain free to create a separate repository dedicated to 3rd party artefacts. This makes it easy for anyone else in your team to build your project.
For example, I'm using Nexus (community editoin) to manage maven artefacts. When someone has a dependency on a 3rd party lib not in maven central, we add it to the third party repo. This allows everyone else to build without having to manually find and download the artefact.
Nexus supports various authentication strategies, including LDAP, so can guard sensitive artefacts from unauthorized use. Since moving to a repository manager, managing artefacts, particularly 3rd party artefacts has become a whole lot easier.
See
Repository management with Nexus
PS: Another plus with Nexus is that you can create a "virtual" repository that is the composition of several repositories "flattened" into one. This puts an end to adding repositories to settings.xml or putting repositories in the project pom. You can dd your own repository, your 3rd party repository, and other popular repositories (central, apache, codehaus, jboss etc...) and set nexus up as a mirror. All requests then go through Nexus, speeding up the build and easing repository configuration.
Related
We are using SVN as a Maven Repositary. We knew that it isn't advisable to have SVN backed maven repository, but still we have to go with it due to limitation within our organization. SVN backed repository used currently is partially implemented.We have developers working from two different geographical location. Problem we face now is whenever a developer adds a artifact to maven repo(svn repository) all other developers have to update the local svn view manually to get the newly added artifact before we do mvn clean package.
IS there a way to automatically download the artifact from svn maven repository to local repo if the artifact doesn't exists locally?
SVN is hosted with a webserver so maven repositary is accessed using HTTPS protocol only. We use maven 2.2 version.
I tried with wagon plugin which would deploy the build output(jar\war) to scm directly. We are not interested in deploying the build outputs. We need a solution to download artifacts automatically from svn maven repo if it isn't exists locally?
You make no mention of how your SVN repository exposes it's artifacts to the development teams. If it truly a Maven repository (conforming to the standard Maven repository layout) then you could just specify it's URL in the "repositories" section of your POM. Updating the local repo would then no longer be necessary.
I suspect that what you have checked into subversion is not a Maven repository layout? You'd lose one of the key benefits of using subversion if each new version of an artifact was being checked in as a new file....
You are describing the functionality offered by any Maven repository manager, for example: Nexus.
I understand your reluctance to embrace a new repository technology, but SCM systems like subversion are primarily designed for tracking changes to textual files.
In conclusion, if you truly wish to keep subversion in the loop I'd suggest one of two options:
Use subversion to control the contents of the local repository. (3rd party dependencies and the artifacts generated by the developers)
Use a repository manager like Nexus. Let Nexus manage cached content from external repositories, but commit the contents of locally hosted repositories into Subversion.
My customer needs a more organized inventory of all 3rd-party libraries (such as JAR files) that are used in production for their projects. I am involved with a number of their Java-based projects. Their inventory has not been consistently maintained in the past and the time has come to account for all the libraries that are currently being used (there are quite a few!) and to enforce a structured process for introducing new libraries into the build environment.
I have tried pitching the idea of using Maven and Artifactory in their build process to leverage those tools' ability to manage a repository of binary libraries and handle transitive library dependencies. The customer is resistent to the suggestion because they think it will create more work for them to maintain an Artifactory server and learn the basics of Maven.
Currently, their Java projects are all built using Ant scripts. Transitive dependencies are largely managed by trial-and-error. The inventory of libraries currently in use is maintained by hand and the binaries are stored in a Subversion repository. The customer recognizes that this needs to be improved, but the current suggestions for improvement involve more ad-hoc "manage it by hand" approaches.
I want to convince the customer that a combination of Maven and Artifactory is a viable off-the-shelf solution for their Java library management needs. Can anyone direct me to literature/materials that I can use to create a presentation for my customer on the features and strengths of Maven and Artifactory?
Any other arguments/suggestions/etc that would assist me in this would also be appreciated.
I want to convince the customer that a combination of Maven and Artifactory is a viable off-the-shelf solution for their Java library management needs.
As pointed out in a comment, your customer doesn't necessarily need to fully adopt Maven to benefit from dependency management, you could adapt the existing ant scripts to use the Maven Ant tasks or Ivy. This might be less scary and already remove some pain.
Regarding the way Maven manages dependencies, I would simply explain that:
An artifact is identified by coordinates (groupId, artifactId, version).
This allows to store store them using a standardized directory structure (a repository)
A dependency is more that a JAR: it's a JAR with a POM which enables things like transitive dependencies resolution.
And the benefits of such a dependency management solution are:
no mess with dependencies, they are uniquely identified (no more "what version is that?" syndrom)
no more binary data in the VCS (faster checkout, less space)
easier reuse of artifacts between projects (no more jars sent by email)
easier management with transitive dependency resolution
And because you don't want to rely on public repositories, because you need to store your own artifacts, you need an enterprise repository. My personal choice would be Nexus:
because it's file based (unlike Artifactory, and I don't want to put my artifacts in a database)
because it's simple to install/use
because it's easy to administrate
Here are some resources about Nexus (sorry, I just don't use Artifactory):
Should we use Nexus or Artifactory for a Maven Repo?
Ning’s Migration from Artifactory to Nexus Professional
From Apache Archiva to Sonatype Nexus
And just in case, here are some presentation material about Maven:
Several presentations by Arnaud Héritier.
Maven 2.x by Jason van Zyl.
Maven 2.0 - Improve your build patterns by Vincent Massol.
3.5. Core Concepts in the Maven Definitive Guide
I am working on converting websphere portal project to maven framework for CI build. I am wondering if there is a way to reference websphere jars other than via dependencies in pom.xml and loading them all to maven repository? I cannot imagine loading them ALL to the repository...
Please advice! Thanks!
When using Maven, it is advisable that all dependent jars are installed in the repository. Even Websphere ones.
Ideally a corporate repository will come in handy here, so that you keep a separate repository for all the Websphere jars accessible to all the users in your project. See http://maven.apache.org/repository-management.html for more.
If this is not an option, then use the local file repository explained on a previous questions - here.
You'll still need to add each dependency in POM.
Also read http://sdudzin.blogspot.com/2007/09/maven-2-and-websphere-automated-build.html
if you have a lot of projects that require this, you can also create a parent pom that would have all the dependencies so your project/module/portlet poms are cleaner.
I want to start using maven in code I distribute but I can't find an efficient way to work with dependencies. Every new dependency takes me far too long to add.
As a simple example, I need to add Tomcat for compilation. Do I really have to manually trawl the repo in my browser to find the group-id, artifact-id and version number?
In every case it seems easier to find the non-maven downloads. I hope I've missed something obvious.
Do I really have to manually trawl the repo in my browser to find the group-id, artifact-id and version number?
No. Use a repository search engine. Some are mentioned here, more here. Some IDE also offer facilities to search and add dependencies (e.g. Eclipse with m2eclipse).
First of all, using some IDE really helps. Eclipse has m2eclipse plugin and if you define locations of remote maven repositories in your pom definition, you can add dependencies in its pom editor and it will automatically search the proper artifacts for you.
What is really helpful is using repository manager like Nexus / Artifactory, where you gather the most important maven repositories and then you don't need to declare particular repository locations in your pom definition for various artifacts, but everything will be proxied via Nexus.
I have a stable opensource library and was wondering how (and if) I can publish my lib to maven official repositories so people can include it in their pom.xml files and get the dependency downloaded automatically.
The process to get your library in the central repostiory is documented in the Guide to uploading artifacts to the Central Repository. In short, the new process is to get your project hosted by one of the approved Forges that will be synced with central, the Maven folks don't rsync personal repository anymore. In your case, your best bet would be to use the Sonatype Forge (open to any OSS Project). Check the given link (and also this document).
If you want reliable access for everyone out there, you need to stick with central. Due to the tendency of people at dev.java.net to break rules about the immutability of released artifacts, some people don't trust it. Further, it can be Very Slow.
To get your project into central, you need have your code in some public repo that they can sync from.
Central repository
A bit less bureaucratic dev.java.net Maven2 repository - allows completely automatic deployment.