I am really new to maven. I am bit confused about the dependency feature. I know that I can add dependency in the pom file like this
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.1</version>
</dependency>
What does this actually mean? Does it mean that I dont need to import the slf4j jar files into my project? If so how does my project get access to those libraries?
I have read about dependency from maven site but didnt help me much.
Can some one explain it in a simpler way.
Thanks
Nutshell: It means your project has a dependency on slf4j, version 1.6.1.
Furthermore:
If you build your project with Maven (or your IDE is Maven-aware), you don't have to do anything else in order to use slf4j. (Aside from normal source-code considerations, like a reasonable import statement, etc.)
slf4j v. 1.6.1 will be retrieved from a default Maven repository to your local repository, meaning...
... ~/.m2/repository is your repository. slf4j will be put in $M2_HOME/org/slf4j/$(artifactId}/1.6.1 and will include (in general) a jar file, a pom file, and a hash file.
Slf4j's dependencies will be downloaded into your local repository as well.
Dependencies of those dependencies will be downloaded ad infinitum/ad nauseum. (The source of "first use of a library downloads the internet" jokes if there are a lot of dependencies; not the case for slf4j.) This is "transitive dependency management"--one of Maven's original purposes.
If you were not using maven, you would manually download and use the dependencies that you needed for your project. You would probably place them in a lib folder and specify this location in your IDE as well as your build tool.
maven manages these dependencies for you. You specify the dependency your project needs in the prescribed format and maven downloads them for you from the internet and manages them. When building your project, maven knows where it has placed these dependencies and uses them. Most IDEs also know where these dependencies are, when they discover that it is a maven project.
Why is this a big deal? Typically most open source libraries release newer versions on a regular basis. If your project uses these, then each time a newer version is needed, you would need to manually download it and manage it. More importantly, each dependency, in turn may have other dependencies (called transitive dependency). If you do not use maven, you would need to identify, download and manage these transitive dependencies as well.
It becomes complex the more such dependencies that your project uses. It is possible that two dependencies end up using different versions of a dependency common to them.
When compiling your project, Maven will download the corresponding .jar file from a repository, usually the central repository (you can configure different repositories, either for mirroring or for your own libraries which aren't available on the central repositories).
If your IDE know about Maven, it will parse the pom and either download the dependencies itself or ask Maven to do so. Then it will open the dependencies' jars, and this is how you get autocompletion: the IDE "imports" the jars for you behind the scenes.
The repository contains not only the ".jar" file for the dependency, but also a ".pom" file, which describes its dependencies. So, maven will recursively download its dependencies, and you will get all the jars you need to compile your software.
Then, when you will try to run your software, you will have to tell the JVM where to find these dependencies (ie, you have to put them on the class path).
What I usually do is copy the dependencies to a target/lib/ directory, so it is easy to deploy the software and to launch it. To do so, you can use the maven-dependency-plugin, which you specify in the <build>:
<build>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.1</version>
<executions>
<execution>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
</build>
There are a variety of servers on the internet that host artifacts (jars) that you can download as part of a maven build. You can add dependencies like you show above to describe what jars you need in order to build your code. When maven goes to build, it will contact one of these servers and download the jar to your computer and place it in a local repository usually
${user_home}/.m2/repository
The servers that maven contacts must be configured in your maven project pom file, under a section like
<repositories>
<repository>
</repository>
</repositories>
The prototypical server can be seen at repo1.maven.org
The nice thing about maven is that if a jar you list is needed, it will pull not only that jar, but any jars that that jar needs. Obviously, since you are pulling the jars to your machine, it only downloads them when it can't find them on your machine, thus not slowing down your build everytime (just the first time).
Related
This is with Java and Maven - I am trying to import some classes from a project that I could either build on my machine to the local mvn repository or I can download it from company's external mvn repository already a packaged jar. I did notice when looking on IntelliJ at the left "project" pane when looking at "External Libraries" and expanding the library in question that there is a "BOOT-INF.classes" prefix to all the classes underneath the jar in question. It's also a springboot project if that helps, although I'm able to import all the springboot classes and all the other classes from external repository just fine.
(Inside of IntelliJ Project View in Left Pane under "External Libraries")
Maven: org.springframework.boot:spring-boot-starter-test:2.0.0.RELEASE
Maven: com.fasterxml.jackson.datatype:jackson-datatype-jdk8:2.8.1
---jackson-core-2.8.1.jar
------com.faster.xml.jackson.core
------com.faster.xml.jackson.core.async
........(More packages listed)
Maven: com.mycompany.my.project:component-two-1.0.0-SNAPSHOT
Maven: com.mycompany.my.project:component-three-1.0.0-SNAPSHOT
---com.mycompany.my.project:component-1.0.0-20181201.jar
------BOOT-INF.classes
------BOOT-INF.classes.com.mycompany.project.my.package.one
---------MyClassOne
---------MyClassTwo
------BOOT-INF.classes.com.mycompany.project.my.package.one
------BOOT-INF.classes.com.mycompany.project.my.package.one.alpha
------BOOT-INF.classes.com.mycompany.project.my.package.one.bravo
It sounds like you are trying to use a Spring Boot application as a dependency. Generally speaking this isn’t recommended as, like a war file, a Spring Boot application is not intended to be used as a dependency.
The Spring Boot documentation says the following:
If your application contains classes that you want to share with other projects, the recommended approach is to move that code into a separate module. The separate module can then be depended upon by your application and other projects.
If that’s not an option then you’ll need to configure your project to build both the application jar and one that is suitable for use as a dependency. From the same section of the documentation:
If you cannot rearrange your code as recommended above, Spring Boot’s Maven and Gradle plugins must be configured to produce a separate artifact that is suitable for use as a dependency. The executable archive cannot be used as a dependency as the executable jar format packages application classes in BOOT-INF/classes. This means that they cannot be found when the executable jar is used as a dependency.
To produce the two artifacts, one that can be used as a dependency and one that is executable, a classifier must be specified. This classifier is applied to the name of the executable archive, leaving the default archive for use as a dependency.
You’re using Maven so the appropriate configuration would look something like this:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<classifier>exec</classifier>
</configuration>
</plugin>
</plugins>
</build>
If you were using Gradle, the appropriate configuration would look something like this:
jar {
enabled = true
}
bootJar {
classifier = 'exec'
}
With either build system, your application’s executable fat jar will now be published with an exec classifier. The normal jar that can be used as a dependency will be unclassified.
You can just ignore the build spring boot maven plug-in, and you'll have a simple jar created.
I am a beginner in maven and now I'm confused with the difference between these maven plugins. Is these all create jar files? now my questions are
what's the difference between the jar created in each plugins.( assembly plugin, jar-plugin, shaded plugin)
The purpose of each plugin. ( assembly, jar plugin, shaded plugin )
I know even without specifying any of these plugins once type mvn package there will be a jar output. What is the difference of the output jar without these plugins and the output jar with these plugins?. TIA
maven-jar-plugin: This plugin provides the capability to build and sign JARs. But it just compiles the java files under src/main/java and src/main/resources/. It doesn't include the dependencies JAR files.
maven-assembly-plugin: This plugin extracts all dependency JARs into raw classes and groups them together. It can also be used to build an executable JAR by specifying the main class. It works in project with less dependencies only; for large project with many dependencies, it will cause Java class names to conflict.
maven-shade-plugin: It packages all dependencies into one uber-JAR. It can also be used to build an executable JAR by specifying the main class. This plugin is particularly useful as it merges content of specific files instead of overwriting them by relocating classes. This is needed when there are resource files that have the same name across the JARs and the plugin tries to package all the resource files together.
Refer: comparison:maven plugin jar,assembly,shade
Jar plugin
Let's see what the following command can tell.
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-jar-plugin
It has 3 goals, help, jar and test-jar. I believe you are mostly interested in the jar goal, which according to the description does the following:
Build a JAR from the current project.
As a side note, executing mvn help:effective-pom on a project with packaging set to jar, shows that this plugin is automatically configured and gets executed during the package phase.
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>default-jar</id>
<phase>package</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
Assembly plugin
This one serves a different purpose. It has 8 goals, but 6 of them are deprecated. So apart from the help goal, this leaves us with the single goal.
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-assembly-plugin
Assemble an application bundle or distribution from an assembly descriptor. This goal is suitable either for binding to the lifecycle or calling directly from the command line (provided all required files are available before the build starts, or are produced by another goal specified before this one on the command line).
You may use the assembly plugin when you want to deliver more than your project's artifact (JAR, WAR, etc.), but the configuration goes in another file.
Shade plugin
The description of the main goal is a bit disappointing.
mvn help:describe -Dplugin=org.apache.maven.plugins:maven-shade-plugin
Mojo that performs shading delegating to the Shader component.
You mostly want to use this plugin if you want to produce an uber-jar, which is your artifact in a JAR with all its transitive dependencies in it.
Basicly, if you're building a library, you'll stick with the default JAR plugin. If you're building an application, you could consider using the shade plugin, though to me, it's kind of quick and dirty. If uber-jar is not your taste or the distribution cannot fit inside a single JAR (external configuration, native dependencies, etc.) then you should go for the assembly plugin.
I've created a boiler-plate project following vogella's extensive Tycho tutorial.
Facts:
There's no feature, and there's no plugin. The only plugin is the RCP app, which is also the entry-point.
Problem:
I have no idea in which pom.xml do I include the 3rd party dependencies.
I cannot include them in the RCP project, because the packaging of that pom is eclipse-plugin, and not jar. From what I've noticed, if I change the packaging to jar, then the "Maven Dependencies" library is added automatically. If I change back to eclipse-plugin, they get removed.
Questions:
Where do I add the dependencies? There's no pom with jar packaging in my project.
Should I create a separate project with the necessary JARs? How do I include that dependency to my entire project?
Is it really that much of a good practice to create a separate plugin and a feature for this RCP app?
Related solutions:
"Update projects" doesn't work, and neither do the n other solutions in the other SO questions.
There's also this question and that question, but I don't fully get the answers
I think that you have a fundamental misunderstanding.
Maven: Maven determines all of the project dependencies via the pom.xml and resolves transitive dependencies automatically (assuming that all of the pom files and artifacts exist in repositories that you've configured and correctly declare their dependencies).
Tycho: The problem is that Eclipse already has its own project model based on product files, feature.xml files, and plug-in MANIFEST.MF files. Tycho leverages the Maven machinery for Eclipse, but the idea is that the pom.xml files just configure the Maven plug-ins and declare the packaging type. That provides an entry point for Maven, but then Tycho takes over. While Maven would normally build the dependency chain from information in the pom.xml files, Tycho is building the dependency change from information in the product, feature, and MANIFEST.MF files. You don't put any dependencies in the pom.xml files. Tycho also uses Eclipse p2 repositories (instead of normal Maven repositories) for finding dependent plug-ins that are not found in the local modules or target platform.
That's actually a benefit for many Eclipse developers since they've already set up everything properly in their Eclipse plug-ins, features, and products. They do not want to have to repeat all of the dependencies in the pom.xml.
Using Libraries in Eclipse plug-ins: In Eclipse, if you want to use a library that is not already packaged as an Eclipse plug-in, you have a few options. Your plug-in can include a set of JARs in a libs folder and then include that libs folder in the plug-in and runtime classpath (see the build.properties file). Another option is to create your own "library plug-in" that repackages a JAR library as an Eclipse plug-in. See also https://wiki.eclipse.org/FAQ_What_is_the_classpath_of_a_plug-in%3F. That's the answer that you're getting above.
The problem is that if you're trying to include a complex library with multiple JARs that is normally distributed and included in a standard Java project via Maven. We hit this problem with the Jersey JAX-RS implementation in my project. There's no p2 repository that includes all of the pieces of the libraries as plug-ins with correct dependency information.
Easy Solution: If you need a common library, check the Orbit project first to see whether the libraries have already been packaged as Eclipse plug-ins, http://www.eclipse.org/orbit/. In that case, you can download them and include them in your target platform, or you can pull them in dynamically at (Tycho) build time from their p2 repository. Your plug-ins would just include those plug-ins as dependencies (in the their MANIFEST.MF files).
Workaround / Solution: In our case, Jersey JAX-RS was not available as an Eclipse plug-in, and it had a bunch of transitive dependencies. The workaround was to create an Eclipse "library plug-in" like I mentioned above with two pom files. We initially created a skeleton plug-in with an empty libs folder. One pom file is just a standard Maven pom file with <packaging>jar</packaging> that declares the top-level dependencies required to pull in the Jersey JAX-RS implementation and all of its dependencies. The dependencies are declared with <scope>compile</scope>. We use the maven-dependency-plugin to copy all of those dependencies into the project's libs folder.
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>compile</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>libs</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
We actually ended up running Maven with that pom by hand from time to time to update the libs, and then we just checked the plug-in with all of its dependent JARs into source control. Checking the build later, I see that we actually populate the libs folder on-the-fly with Maven with a separate build task just before we start the Maven/Tycho part of the build. Of course, plug-in's MANIFEST-MF file's Bundle-ClassPath and Export-Package entries are coming straight from source control. We have to check those from time to time to ensure that they match the libraries and packages that we're getting from Maven. (That doesn't tend to change much unless we bump major library versions or add a new dependency at the Maven level.) The plug-in's build.properties has the libs/ folder as part of bin.includes.
In the development environment, after we first check out the code, we just run mvn (with an External Tools launch config that's also checked in with the project) on the project's "copy dependencies" pom file. That populates the libs folder with all of the JAX-RS libraries and dependencies. We only have to run it again when we update something about the dependencies or when we're jumping between branches that have different versions of the JAX-RS dependencies. We set .gitignore to ensure that we don't commit the libs to Git.
The other pom for this project is set up like a normal Tycho pom file with <packaging>eclipse-plugin</packaging>. During our automated build, we run one step early in the build process (just after check out) that calls mvn with the jar pom to populate the libs. Then we proceed with the main Maven/Tycho build using the eclipse-plugin pom. The eclipse-plugin pom has no dependency information (as I said above). It's just providing Tycho a way to recognize the Eclipse plug-in and build it based on its MANIFEST.MF and build.properties files. But the built plug-in includes and exposes all of those libs that were populated by the mvn call to the jar pom step.
So, it's a bit of a mess, but that's the best solution we found a couple of years ago when we hit this problem. I'm not sure whether Tycho is doing any work to permit some sort of hybrid Maven/Tycho build that could do this automatically as part of the build. I guess I should ask the developers. :)
Your questions:
Where do I add the dependencies? There's no pom with jar packaging in my project. Answer: The workaround above lets you do it with one project. You just have two pom files, like pom_deps.xml and pom.xml. You just have to invoke the pom_deps.xml separately to populate the libs folder (in the dev environment and with your automated builds).
Should I create a separate project with the necessary JARs? How do I include that dependency to my entire project? Answer: the workaround that I described above lets you do it with a single project. Another way to do it is to create a separate JAR project, but I don't think that your Eclipse RCP app can really include a <packaging>jar</packaging> module in a useful way. The only way I've found to do it is to use a similar workaround. You build the JAR module first, install it into the maven repository, and then have one of your plug-in projects bundle the JAR in its libs folder. (If you really want to do it that way, ask. We have a case where we have to do that, too, and I can provide the steps we do in development and the build to make it work. I think the single project workaround that I provided above makes more sense for your case.)
Is it really that much of a good practice to create a separate plugin and a feature for this RCP app? Answer: that's really a separate question. If you have a feature with multiple plug-ins, you have the same problem. Tycho can handle the product/feature/plug-ins, but it cannot jump across into Maven-based dependency resolution. You'll end up having to use the same workarounds
Summary: The fundamental issue is that Eclipse plug-ins can't "see" a bare JAR library. The plug-in needs to have the library included in its local libs folder (with a matching Bundle-ClassPath entry in MANIFEST.MF), or it needs to depend on some other plug-in that exports the appropriate packages. Tycho just resolves dependencies via Eclipse plug-ins, and it cannot leverage normal Maven dependency resolution directly to pull in a bunch of JARs. If all of your dependencies are already plug-ins, you're fine. If not, you may have to use the workaround above to package a set of libraries for your plug-ins to use.
Just adding the plugin to pom dependencies and including the entry <pomDependencies>consider</pomDependencies> in the configuration of target-platform-configuration makes it work.
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho.version}</version>
<configuration>
<!-- The configuration to make tycho consider the maven dependencies -->
<pomDependencies>consider</pomDependencies>
<!-- other configurations -->
</configuartion>
</plugin>
<!-- other plugins-->
</plugins>
<dependencies>
<!-- An example third-party bundle (plugin) present in maven repository-->
<dependency>
<groupId>org.apache.felix</groupId>
<artifactId>org.apache.felix.gogo.shell</artifactId>
<version>1.1.0</version>
</dependency>
</dependencies>
Reference link here.
Sorry if this is too trivial, but I've recently jumped into Wep Applications from standard console java projects, and since in java projects I successfully used maven to download jars and include them into the classpath... in the web app I don't know how to accomplish the same stuff and downloading to the lib folder on WEB-INF instead of just adding the jars to my classpath.
I have searched stack overflow and the google for an answer, but since I haven't found any single answer, I'm afraid I should be completely wrong with my approach for this.
I have just created my webapp on eclipse, then converted it to maven project, and then added this dependencies in pom.xml, as I used to do in a normal java project:
<dependencies>
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>2.9.1</version>
</dependency>
</dependencies>
Everything seems to be ok, and no error is shown, but the jars are not downloaded into the WEB-INF/lib folder.
Thanks in advance for any help you can provide.
If your project is correctly configured as "Maven project" there should be a folder called "Maven Dependencies" in your package view.
A good hint if your project is configured as Maven project is a little "M" on the top level folder.
Eclipse will download in a so called "Repository". This is mostly located in $HOME/.m2
Generally you don't have to care about jars directly. Maven will download them and create a classpath transparently for you.
The eclipse maven integration is called m2e.
The concept of Repositories is central to maven. They are the place where your dependencies and external dependencies are stored. Two repositories you can always assume to exist are the already mentioned local one and the other so called "Maven-Central" see here. Beside that you can setup , for example, company wide Repositories with tools like Nexus or Artifactory.
To upload a dependency in your local Repo use the mvn install command.
What maven within mvn install is executing the install lifecycle.
and then uploads the resulting artifact (generally a jar or war, but not necessarily) and some metadata (your pom mainly) to the repository.
You can then develop against these dependencies via the dependency mecahnism.
Dependencies in you installed in your local Repository are always of type "SNAPSHOT". There is more to know about the difference between SNAPSHOT and Release (only version number) and how to deploy/release them, but these questions are already awnsered several times.
Adding this plugin to pom.xml will help to get jars in lib folder.
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<outputDirectory>WebContent/WEB-INF/lib</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
I have a Maven project, which uses JAR packaging. When I run the install phase, it will install both Project-1.0.jar and Project-1.0.pom files in my local repository.
Now I would like the JAR to be built with a classifier. This is easy enough: I just add the line to my jar plugin configuration:
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<classifier>whatever</classifier>
[...]
</configuration>
</plugin>
Now, this works in that it installs Project-1.0-whatever.jar in my repo, but no longer installs a POM.
In case it matters, I want to use this feature in conjunction with profiles, i.e. I want to build JARs with different classifiers with different profiles.
The reason I want the POM is because I have other projects depending on this one. When I build one of these, it will try to find a POM for this dependency. If it can't, it will happily use the JAR, but that is not an acceptable solution for me for a couple of reasons:
It's bad enough that it will try to contact external repos and look for it, but even worse, we use a share repo, so it will download the POM from the shared repo, which may not be what I want - for example if I just made changes to the POM and am trying to test them.
Is there a solution, or can anyone suggest a reasonable workaround?
EDIT: I just discovered that the issue affects Maven 2.2.1, but not Maven 3.0.5. This may therefore be a bug or a difference in features between versions. I would still be interested in solutions/workarounds for Maven 2, as migrating the project to Maven 3 is a complicated affair and not likely to happen.
The reason turned out to be nothing to do with Maven version as such, and everything to do with the version of maven-install-plugin. It turns out versions prior to 2.3 have this bug.
Old installations of Maven are somewhat likely to suffer this issue, as Maven 2 will use any version of a plugin that it has unless a version has been explicitly specified in the POM, but maven-install-plugin is included by default and it's quite possible for a POM not to explicitly specify it at all (as it was in my case).