What should I mention in pom.xml to make my dependency published with <scope>test</scope>?
This functionality of mvnrepository doesn't have any connection with Maven. Mvnrepository copied this functionality from javalibs.com where if some library is used a lot with some scope, then such scope it will be added to dependency tag:
https://javalibs.com/artifact/junit/junit
https://javalibs.com/artifact/org.projectlombok/lombok
Article about this mechanism: https://javalibs.com/news/android-scope-charts
Mvnrepository enhanced it a little bit and they are currently IMHO manually setting the scope for well known libraries.
FYI: Mvnrepository doesn't have anything to do with Maven Central / Sonatype
Disclaimer: I'm author of https://javalibs.com
Related
I recently created my own API in maven, and I need to make the dependency available to others. I have tried using the dependency in another project, but it can't find it. What do I need to do in order to publish it?
My dependency:
<dependency>
<groupId>org.dec4234</groupId>
<artifactId>JavaDestinyAPI</artifactId>
<version>1.0</version>
</dependency>
Available on GitHub
You need to upload your library to a Maven repository. By default, every Maven project uses the Maven Central repository - which contains copies of most common publicly available libraries that you are probably used to using by just putting an entry in the <dependencies> section of your pom.xml.
Here is a guide to uploading a library to Maven Central - https://central.sonatype.org/pages/ossrh-guide.html. I've personally used it previously and whilst it does take some work, its probably your best option.
You can also host your own Maven repository, but I'll leave detailing that route to someone else's answer.
With the SDK 6.3.10, I am trying to develop a plugin for Jira 7.x.
This plugin should use an external Java dependency named "maven-handling". I did the following:
First I added the dependency in the POM:
<dependency>
<groupId>some-company</groupId>
<artifactId>maven-handling</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
Then I changed the import-package entry in the maven-jira-plugin to:
<Import-Package>org.springframework.osgi.*;resolution:="optional",
org.eclipse.gemini.blueprint.*;resolution:="optional",
some-company.maven_handling*;version="0.0";resolution:="optional", *
</Import-Package>
Still I get a classNotFound on the class I use from the some-company.maven_handling package. What did I miss?
Assuming that this plugin dependency is something that you wish to bundle with your plugin, and not something already included in Jira that you wish to access:
You only need to add <Import-Package> entries for packages that are defined elsewhere and made available to your plugin via OSGi. Since this dependency is not part of Jira itself and you are packaging it internally along with your plugin, you don't need to do this. Just remove it from the import list. I believe this will cure the problem.
You may also want to explicitly declare <scope>compile</scope> in the dependency in your pom to make it clear that you are intending to bundle this with your plugin (although this is the default scope, so it's optional).
I am not understanding what is the purpose of bom object? and I am working on Spring 3.2.8 version and with JBoss server, so which bom dependency I need to use? When I mention the following dependency in pom.xml:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-framework-bom</artifactId>
<version>4.0.1.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Does the jar file gets downloaded into my Maven Dependencies?
What is the purpose of bom object?
Maven parent-child relationship is very handy for managing dependencies of multiple projects in a single place. However, Maven projects can have only one (direct) parent. So imports were introduced for dependency management to allow using several projects for managing your dependencies. With an import you can define a single dependency like this and get multiple dependencies managed - handy! Although you could import any project, BOM is a special project designed to be used for imports like this. Usually a BOM project will have very little defined besides dependencyManagement section, and will not have any unrelated dependencies, to avoid affecting your main project too much.
Which bom dependency I need to use?
BOM is not a requirement, you don't need to use either. Instead, you could define all managed dependencies in dependencyManagement section yourself. These can include Spring, JBoss and any other dependencies. BOM, however, simplifies this for you significantly. You can add as many BOMs as you want, so add both! But as #Jesper mentions, don't forget to use correct versions. When using multiple BOMs their order will matter if they both reference a common dependency.
Does the jar file gets downloaded into my Maven Dependencies?
Notice BOM is <type>pom</type>, not the default jar. So there's no jar to be downloaded. A single pom.xml file will be downloaded and read by Maven.
While looking for informations on stackoverflow, I have seen a question similar to mine, but with no real answer here.
I need migrating my maven project from guava 11.0.2 to guava 14 or higher (I need RangeSet). I updated my maven pom with the dependency:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>14.0</version>
</dependency>
I then run the maven build, and got this error:
[ERROR] xxx.java: cannot find symbol
[ERROR] symbol : class Nonnull
[ERROR] location: package javax.annotation
I took a look closer, and this annotations is provided with JSR305, on which depends guava 11.0.2, as mvn repository reports it.
What I find strange is that guava 14 also depends on JSR305 as mvn repository reports.
If I add the JSR dependency to my pom, then the compilation just runs fine:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
<version>1.3.9</version>
<scope>provided</scope>
</dependency>
But why would I have to add this dependency to my pom if guava already depends on it ? This looks more to a workaround than to a solution, and I would prefer to understand and make things clean.
Thanks for participating.
The reason that you need to add it as a dependency is because Guava 14 defines the dependency in their pom as follows:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
<version>1.3.9</version>
<scope>provided</scope>
</dependency>
The important part for your problem is the <scope>provided</scope> line.
From the maven website they state the following with regards to provided dependencies:
provided:
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
So basically because Guava have set this as a provided dependency they expect whoever is consuming Guava to provide this dependency which is exactly what you have had to do.
In Guava 11.0.2 it was a normal compile dependency, hence you didn't have to provide it in your own project.
The change was made in Guava 13. From the release notes:
Made findbugs a provided dependency to avert dep conflicts when using findbugs 2.0. The side-effect of this change is that projects which relied upon Guava to grant access to the JSR-305 annotations "for free" will break unless they provide their own direct dependency on that jar (or an equivalent). Projects should always have been directly depending on JSR-305 (per maven best-practice), but this change makes that should into a must.
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!