In pom.xml , we will provide compiletime and runtime as scope in the dependency ? whats the significance of that ? Please provide some applicable example for understanding this.
The following is taken from the maven documentation
compile
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
runtime
This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
So for example if we have the following two dependencies in our POM:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging-api</artifactId>
<version>1.1.3</version>
<scope>compile</scope> <!-- can be ommitted as it is the default -->
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.3</version>
<scope>runtime</scope>
</dependency>
Then the classes from commons-logging-api would be on the classpath during compilation of my module, whereas classes from commons-logging would not be available - if by accident I had a direct reference to a class from commons-logging in one of my project's classes then the build would fail.
However during runtime or test compilation & execution the classes from commons-logging would be on the classpath so could be used (i.e. by classes from commons-logging-api, or directly in tests of the project).
Both compile and runtime dependencies are included transitively (under the same scope) by Maven when your project is referenced as a dependency in another project.
p.s. As mentioned by kostja there is also the provided scope
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.
Basically the difference between provided and compile is that provided dependencies are not transitive.
Imagine you are deploying your application to a Java EE compliant server. The server provides all libraries implementing the Java EE standard, so you don't need to deploy them with your application.
During development, you will need the Java EE libraries with the compile time scope, since you need to compile the classes.
During the runtime however the dependencies are provided by the application server. Maven uses the 'provided' scope for such cases.
Related
Project is Java and Maven.
I am required to integrate the selenium test which is under different project following multi module approach to integrate with single module spring project under one folder. Suggested information was to add the selenium test in src/test folder, but given this multi module looks difficult to follow that approach. Any best practices to follow ?
In pom there are scope field where you can mention test , this will make sure the dependencies are installed only for mvm test
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
test
This scope indicates that the dependency is not required for normal
use of the application, and is only available for the test compilation
and execution phases. This scope is not transitive. Typically this
scope is used for test libraries such as JUnit and Mockito. It is also
used for non-test libraries such as Apache Commons IO if those
libraries are used in unit tests (src/test/java) but not in the model
code (src/main/java).
https://www.baeldung.com/maven-dependency-scopes
3.4. Test
This scope is used to indicate that dependency isn't required at
standard runtime of the application, but is used only for test
purposes. Test dependencies aren't transitive and are only present for
test and execution classpaths.
The standard use case for this scope is adding test library like JUnit
to our application:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
The description for the "provided" scope of maven dependencies contains this note:
"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."
Question is if there is a xml snippet available (maybe an official one) that gives me the "provided" dependencies for a specific tomcat version.
The thing you are looking for is a Bill of Materials (BOM). This can be imported in the dependencyManagement section of your pom.xml by setting the type and the scope of the dependency to pom and import, respectively.
Unfortunately, Tomcat does not seem to provide an official BOM for its provided dependencies. There is an unofficial version on Github, but depending on what you want to use it for, this may not be the best solution. According to the docs at github, you can us it like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>fr.husta.tomcat</groupId>
<artifactId>tomcat-provided-spec-bom</artifactId>
<version>8.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
When you use a full-blown JavaEE-Server like JBoss EAP, official BOMs are provided, e. g. this one.
I have added the jar names on the classpath to the manifest file by the method described in official documentation.
i.e. by adding
<manifest>
<addClasspath>true</addClasspath>
</manifest>
to the ejb plugin. Now I do not want ALL such files, but want to exclude some of them (because they are directly provided by webSphere and should not be listed).
Question: Is there any exclude mechanism I can apply here?
Maven dependencies which are provided by your target container should be listed as scope provided. As per official documentation
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.
Hence, you should set the concerned dependencies as scope provided:
<dependency>
<groupId>...</groupId>
<artifactId>..</artifactId>
<version>...</version>
<scope>provided</scope>
</dependency>
Maven will use it for compilation, testing but not for packaging. And it will also be excluded from Manifest classpath.
You can check this SO question about difference between provided and compile scope (the default one, no need to specify it at each dependency declaraction) while this SO question had exactly the opposite issue.
Maven is a bit over my head sometimes... I have created a library which has an optional dependency on slf4j and on log4j. By optional, I mean:
My library needs those logging frameworks at compile time
My library doesn't need them at runtime, but if it "discovers" them, it will use them
Currently, I have marked that dependency as "optional" and "provided":
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.16</version>
<type>jar</type>
<scope>provided</scope>
<optional>true</optional>
</dependency>
But some of my users have reported issues, because they don't need log4 / slf4j. Is my dependency correct? Unfortunately, I find the official documentation a bit too abstract to understand this problem.
Did you check this documentation. It describes your use case very good. Marking dependencies as optional will not resolve them as transitive dependencies in the application which use your library (even if the scope is compile).
In difference to <scope>provided</scope> which is used for required dependencies which will be provided by the runtime environment an <optional>true</optional> dependency is not necessarily meant to be required (The idea is that some of the dependencies are only used for certain features in the project, and will not be needed if that feature isn't used.).
If a project which uses your library will use any functionallity provided by the optional dependencies the project has to declare these dependencies for their own.
As your configuration seems to be correct for me I do not know the reason what probles occur. Maybe your optional dependencies get resolved by other libraries in versions you do not expect. That of course might cause problems.
What is the meaning of "bundle" e.g in this dependency:
<dependency>
<groupId>org.apache.abdera</groupId>
<artifactId>abdera-core</artifactId>
<version>1.1.2</version>
<type>bundle</type>
<scope>compile</scope>
</dependency>
This kind of artifact is an OSGi bundle, typically produced using the maven-bundle-plugin which is part of Apache Felix.
The plugin treats all the classes available to your module (the module's own classes, classes provided by dependencies, other classes on the classpath) as one giant set, then lets you select a subset of those classes to bundle into a jar. It also creates the necessary manifest information to make the artifact an OSGi bundle.
So the artifact you're pulling in by using this dependency is a jar, however it's a jar built by choosing a subset from a much larger set of classes, not just the classes that were defined inside the abdera-core module.
If you have a look at the pom for the abdera project you'll see the maven-bundle-plugin configuration which will give you an idea of which classes have been added to the bundle, and which have been held back.