Our team of developers uses Maven for building software. We have Maven local repository on our computers. The problem is that sometimes builds made from two different developer differ, because the built packages include different version of included dependencies.
This happens when version tag is not mentioned in POM.xml file for dependencies. For example:
<dependency>
<groupId>mylib-group</groupId>
<artifactId>mylib-artifact</artifactId>
</dependency>
In this case Maven gets the newest library installed locally.
To avoid this problem We installed Maven on one computer (we call Build server) and all members of our team make build on that computer.
Is there any better solution for this case?
How can I have centralized Maven local ?
First of all: if you have a dependency like
<dependency>
<groupId>mylib-group</groupId>
<artifactId>mylib-artifact</artifactId>
</dependency>
Maven will not take the latest version, but the one defined in the <dependencyManagement> section. So you get the same results on every computer (unless you have SNAPSHOT versions which might differ).
Having said that: Having a build server is generally a good idea for having a stable environment for builds.
Addendum: You can not share a Maven local repository. This repository is not thread safe and running two builds at the same time on the same local repository can have strange effects (I speak from experience).
Related
This question is for getting feedback on a suggested versioning system for a multi-module java application built using Maven.
We have developed a multi-jar system (micro-services) with about 15 modules/jars. Some of them (5) are libraries used by the other modules in the system but not outside of the system. The modules are all stored in separate git repositories.
We have released first version and need to get serious with branching/versioning.
Goal: Minimize work needed to be done regarding versioning (updating version numbers, manual merge because of different version information per branch, etc).
How: Modules are identified by module name and git branch name, not by module name and version
We build our own "version-files" saved as resources in each module. These contain build time, git commit-id, branch name, build URL, etc, for the module itself plus included modules. So we have no need for any Maven version number after deployment.
Note: For library modules outside the system we use standard approach both for internally developed and externally developed modules. Ie. strict numbered versioning using Maven dependency system.
The system I'm contemplating is to
always use the version number <branch-name>-SNAPSHOTin the pom files, plus configuring Maven to always fetch latest SNAPSHOT version (not only daily as it does by default - ref. What exactly is a Maven Snapshot and why do we need it?).
Use a BOM (ref. Maven BOM [Bill Of Materials] Dependency) to define dependencies.
The pom file for a module in this system will be similar to:
<project>
...
<version>${revision}</version>
<dependencies>
<dependency>
<groupId>mygroup</groupId>
<artifactId>bom</artifactId>
<version>${revision}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
<properties>
<revision>default_version</revision>
<properties>
</project>
This version is specified during build by executing mvn using similar to: mvn deploy -Drevision=<branch-name>-SNAPSHOT (ref: https://maven.apache.org/maven-ci-friendly.html).
As the pom shows, we will (mostly) have one BOM version per branch name used in the system, with version name <branch-name>-SNAPSHOT - same as the module itself. The BOM file should include dependencies using explicit versions, also for system internal modules.
Example flows:
A simple feature branch. In branch modify pom so the BOM reference refer to same as parent branch - replace ${revision} for the BOM reference. Ie. you don't need a separate BOM (yet...)
A simple feature branch for internal library. Same as previous, but you should probably create same branch for a module using this library and a same branch for BOM ensuring the two modules are linked.
A system release. Create a release branch on all modules (git repositories). Including the BOM module. E.g: release201810. In BOM file in branch release201810 ensure that all referenced system-internal modules are referred to using version release201810-SNAPSHOT.
Parallell development. Create custom branch on modules as needed. Update the custom BOM as modules are branched for this development.
Is this a good idea?
I have some concerns:
You usually put the whole multi-module project into one git repository. Then you branch on the whole project, not on single modules.
The whole project usually has a version number in x.y.z-SNAPSHOT form which is increased over the time. Releases should be built with release versions, while during development you can have SNAPSHOT versions.
It is possible to build branches as x.y.z-branchname-SNAPSHOT, but dropping the version number all together is very non-standard.
I must say that every time I deviated from the standard (for good reasons, like legacy structures in the company), it caused problems later.
There are a lot of questions about this, but the answers seem to contradict each other. So I wanted to ask it for my version of Maven (3.0.4).
I have a JAR file that's not part of any maven repository. It's a local dependency. I understand there are two ways to add it to my Maven project.
Add it as a dependency and specify the file path in the <systemPath> property. (No other work needed.)
Create a local repository <my-project>/repo and install the JAR in this repository. Then, add the new repository in my pom.xml file and add the new dependency.
I'm curious which way is better practice? I've heard some negative things about the <systemPath> property, although that way looks faster.
The answer is, it depends...
If you add it as a system dependency it is likely to become path dependent which makes it more difficult to share among other developers. Sure you can also distribute the 3rd party jar relative to your POM via your SCM but the intention of systemPath is more for dependencies that are provided by the JDK or the VM. From the docs about systemPath:
They are usually used to tell Maven about dependencies which are provided by the JDK or the VM. Thus, system dependencies are especially useful for resolving dependencies on artifacts which are now provided by the JDK, but where available as separate downloads earlier.
To install the jar in the local repo is also not friendly for sharing. It requires all developers to "upload" the jar to their local repo before building. You can of course add a script that handles this for you but it is always easy to forget to upload and IMO a better solution is point 3 below. The local install process is described here.
If you are working in an organization where the developers share the POM you should upload the 3rd party jar to a local repository manager. That way you can easily work with the 3rd party jar as if using any other maven enabled jar. Check this link for a comprehensive list on repository managers.
To summarize, if you are sharing the POM with others I would suggest that you upload it to a local repository manager. Otherwise the second option can work for you. As a last option, I would fall back to option number 1.
Also note that this has nothing to do with which version of Maven you are running.
You can add jar to your local maven repository. Usually it located at:
$home_directory/.m2/repository
For example you have expample.jar and you want to add it to your pom as:
<dependency>
<groupId>com.example</groupId>
<artifactId>example</artifactId>
<version>1.0</version>
</dependency>
Then you must add example.jar to:
$home_directory/.m2/repository/com/example/1.0/example.jar
In my case NetBeans do it for me.
The best way I see so far is to use install:install-file goal with maven. You can use the mvn command line to execute it directly with appropriate parameters, or if you are using eclipse EE, you can do so by leveraging the embedded maven and creating a Run Configuration as follows:
Then, you include the jar as follows:
<dependency>
<groupId>mylocal.weka</groupId>
<artifactId>weka</artifactId>
<version>1.0</version>
</dependency>
Of course adjust the parameters as per your needs.
Best,
Haytham
I have two projects in eclipse:
framework: A general library used in several projects.
client: A project that uses framework.
client is quite large, possibly larger than framework at this point. I am using client as sort of a test fixture for framework. I want to make a few changes in framework and test them in client. Currently, I have to do a full build of framework, install it into a maven repo, and then rebuild client.
Is there a way to just have client point to framework directly on my local disk? Any other hints for developing in such a situation (ie is the a better way)?
Running mvn install on Framework will build it and install it in your local Maven repository (that is, the Maven repository on your local disk). When you run your tests in Client, Maven will automatically use the version of Framework in your local repository.
You can specify dependencies from the local disk using <systemPath> like so:
<dependency>
<groupId>example.logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/commons-logging.jar</systemPath>
</dependency>
I'm not sure if you can point to a directory that has a pom in it, but at least you don't have to deploy it into maven.
The m2eclipse plugin is fairly intelligent about Maven dependencies. If you have the framework dependency open as a separate project in Eclipse, I think it should use its code for client rather than the version in your repository. You might need to tweak your project settings if you're already using m2eclipse and it doesn't do this.
Warning: I have just picked up Maven, so things mentioned might be wrong or not best practice.
I have a medium size open source project that I am migrating to Maven from the basic
NetBeans project management. This is not a developer team sharing the same room, this is 1-5 people over the internet sharing a SVN repo. Reading over the how-tos on dependencies, it seems that the only way to get dependencies is to get them from an online repo or install them locally.
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons including portability (anybody can pass by, check out the repo, build, and use; all that simply without manual adding to local repo's and whatnot), getting newer versions (discussed below), and manual versioning.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
So
How can I force all dependencies to come from /lib for example
On a related note, can mvn build from library's SVN repo directly? Just curious
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
FYI, this is a Java project with 3 modules, project global dependencies and module specific dependencies.
Bonus points if it can work with the bundled version of Maven that comes with NetBeans.
Not a duplicate of
Maven: add a dependency to a jar by relative path - Not wanting to install to local repository
maven compile fails because i have a non-maven jar - Don't think a System dependency is the right answer
maven look for new versions of dependencies - Still uses(?) repository, just the latest (old) version
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons (...)
I will come back on this but the solution I described in Maven: add a dependency to a jar by relative path (using a file-based repository) allows to implement such a solution.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
It looks like mvnbrowser indices are totally out of date (making it useless as repository search engine) because the maven central repository does have logback-core-0.9.24.jar (the logback project is doing what has to be done to make this happen) but only has an old pircbot-1.4.2.jar. Why? Ask the pircbot team. Anyway, you're right, the central repository might not always have ultimate versions.
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
Yeah, this happens too.
How can I force all dependencies to come from /lib for example
As previously hinted, you should re-read carefully the solution suggested in Maven: add a dependency to a jar by relative path. This solution is not about installing libraries to the local repository but is about using a file-based repository (that could thus be stored in SVN). You might have missed the point, this matches your use case. And also check Brett's answer for a variation.
On a related note, can mvn build from library's SVN repo directly? Just curious
Didn't get that one. Can you clarify?
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Maven supports version ranges and you could use a syntax allowing to use "any version greater than X". But I do NOT recommend using version ranges at all, for the sake of build reproducibility. You don't want the build to suddenly fail because of some automatic update that happened on your back. Only upgrade if you need bug fixes or new features, but do it explicitly (if it ain't broke, don't fix it).
You might also find mentions of the LATEST and RELEASE version markers. I don't recommend them neither for the same reasons as above and even less since they're removed from Maven 3.x.
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
Can't say for Ivy. But in the Maven land, if you can't host up a "corporate" repository for your project (Nexus, Archiva, Artifactory), then the file-based repository is IMO the best approach.
Setup your own Maven repository.
http://archiva.apache.org/
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!