Need to be pointed in the right direction on this perhaps, but if I add a "provided" dependency that is not included in the tomcat set of provided dependencies, running tomcat7:run from within eclipse fails with a classnotfoundexception on the class from the provided scope jar.
It needs to "provided" because it's a custom jar from a separate project that I've run mvn install on and for production am copying the jar to the $CATALINA_BASE/shared directory so that it's available (as a singleton) across applications/webapps.
<dependency>
<groupId>IndexFileAccessTracker</groupId>
<artifactId>IndexFileAccessTracker</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>provided</scope>
</dependency>
Only way I see (with my limited knowledge of Maven and the Tomcat7 plugin) is to change the scope to compile when running tomcat from the plugin in Eclipse and then change the scope back to provided when running the package goal.
Are there solutions to this? I tried adding the dependency to the the tomcat maven plugin (keeping the main maven dependency as provided but got the same class not found error:
<!-- For Maven Tomcat Plugin -->
<plugin>
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat7-maven-plugin</artifactId>
<version>2.2</version>
<configuration>
<path>/CounterWebApp</path>
</configuration>
<dependencies>
<dependency>
<groupId>IndexFileAccessTracker</groupId>
<artifactId>IndexFileAccessTracker</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
</dependencies>
</plugin>
Again, it needs to be provided in the main Maven dependency because I don't want it included in the deployed WAR.
Resolved by using profiles, similar to https://stackoverflow.com/a/5951630
...
</dependencies>
<profiles>
<profile>
<id>runineclipse</id>
<dependencies>
<dependency>
<groupId>IndexFileAccessTracker</groupId>
<artifactId>IndexFileAccessTracker</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>
</dependencies>
</profile>
</profiles>
<build>
...
Then in my run/debug configuration just added runineclipse to the Profiles: box.
(On a side note, to do step through debugging I had to manually add the project to the Source tab.)
The build configuration was just the same package in the Goals: box; and I left the original dependency to have scope provided.
The tomcat7-maven-plugin and its run goal
Requires dependency resolution of artifacts in scope: test
Everythig that is on the compile classpath is also on the test classpath.
Thats why it is working with scope compile.
So the solution in your case would be to mark your dependency as test what even is (imo) semantically correct.
This will make the library available at local test-time, but not in the final artifact.
Related
How can you depend on test code from another module in Maven?
Example, I have 2 modules:
Base
Main
I would like a test case in Main to extend a base test class in Base. Is this possible?
Update: Found an acceptable answer, which involves creating a test jar.
I recommend using type instead of classifier (see also: classifier). It tells Maven a bit more explicitly what you are doing (and I've found that m2eclipse and q4e both like it better).
<dependency>
<groupId>com.myco.app</groupId>
<artifactId>foo</artifactId>
<version>1.0-SNAPSHOT</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
Thanks for the base module suggestion. However, I'd rather not create a new module for just this purpose.
Found an acceptable answer in the Surefire Maven documentation and a blog. See also "How to create a jar containing test classes".
This creates jar file of code from src/test/java using the jar plugin so that modules with tests can share code.
<project>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-jar-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<goals>
<goal>test-jar</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
In order to use the attached test JAR that was created above you simply specify a dependency on the main artifact with a specified classifier of tests:
<project>
...
<dependencies>
<dependency>
<groupId>com.myco.app</groupId>
<artifactId>foo</artifactId>
<version>1.0-SNAPSHOT</version>
<type>test-jar</type>
<scope>test</scope>
</dependency>
</dependencies>
...
</project>
We solved this by making a maven project with test code as the src/main/java and adding the following dependency to projects:
<dependency>
<groupId>foo</groupId>
<artifactId>test-base</artifactId>
<version>1</version>
<scope>test</scope>
</dependency>
Worked for me for 1 project, but I didn't for another after doing exactly the same steps.
So I debugged:
After mvn clean install I checked /target directory: .jar was there so thats good
Ran mvn dependency:tree on a project which should use those test classes. Noticed that generated jar file with test classes is marked as dependency, so thats good.
Conclusion could be only one - I restarted my Intellj. At first class import was still not visible, but after a minute it started to see it!
Note: I only restarted Intellj, no caches removal etc
Yep ... just include the Base module as a dependency in Main. If you're only inheriting test code, then you can use the scope tag to make sure Maven doesn't include the code in your artifact when deployed. Something like this should work:
<dependency>
<groupId>BaseGroup</groupId>
<artifactId>Base</artifactId>
<version>0.1.0-SNAPSHOT</version>
<scope>test</scope>
</dependency>
I am trying to get used to Eclipse/Java but am more familiar with MS VisualStudio. Lets say I have Java Library (Project1) which has some dependencies on jar files via Properties->Java Build Path->Libraries (eg: AWS SDK, gson, swagger, etc). Now if I have Project2 and set a project dependency for Project2 to Project1 via Properties->Java Build Path->Project, I would hope that Project1 dependents would also be included for Project2. I dont see that happening or I am missing a step. I have been googling but I don't see any tutorial/documentation discussing 2 levels of dependents. I see that the Project1 jar is being referenced but what about the dependents for Project1? I am receiving an error such as:
The type XXXX cannot be resolved. It is indirectly referenced from
required .class files XXXX
I strongly suggest using Maven, which is a great and easy to use dependency manager.
Probably your eclipse already comes shipped with it, all you have to do is:
Do this for both projects:
Right click both projects, go to Configure -> Convert to Maven Project.
Create a group id,artirfact id and specify the version for your projects.
It will generate a pom.xml file in the root of your project.
Something like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>4.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jdbc</artifactId>
<version>4.2.1.RELEASE</version>
</dependency>
<dependency>
<groupId>commons-dbcp</groupId>
<artifactId>commons-dbcp</artifactId>
<version>1.2.2</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.6</version>
</dependency>
</dependencies>
</project>
You can add dependencies for your projects just by adding a dependency tag.
<dependency>
<groupId>yourGroup</groupId>
<artifactId>yourProject</artifactId>
<version>1.0.0</version>
</dependency>
After that just right click your projects go to
Run -> Run Configurations -> Maven Clean
Run -> Run Configurations -> Maven Install
and it will automatically download and install your dependencies for you.
You might want to have a look at Maven or a tool like this (Gradle, Ivy...) to handle your dependencies.
Relying on Eclipse for defining your build process (and dependencies) is a bad idea for long term projects.
This depends a little, on your project.
In case it is just a Java project, then it is better to use a build tool like Ant with Ivy, Maven or Gradle. As these contain the dependencies and other configuration details. Eclipse Mars (v4.5.1) comes with build in support for all these build tools.
In case it is an Eclipse Plug-in which you are developing, then you can configure it in Eclipse. And then store the configuration files, with the source code in the code repository.
I have a Maven module with two different database profiles.
<profile>
<id>db-localhost-oracle</id>
<dependencies>
<dependency>
<groupId>ojdbc6</groupId>
<artifactId>ojdbc6</artifactId>
</dependency>
</dependencies>
<properties>
<db.driver>oracle.jdbc.driver.OracleDriver</db.driver>
<db.dialect>no.jbv.sergej.util.FixedOracle10gDialect</db.dialect>
<db.url>jdbc:oracle:thin:#//localhost:1521/xe</db.url>
<db.hbm2ddl>update</db.hbm2ddl>
</properties>
</profile>
<profile>
<id>db-localhost-mysql</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<dependencies>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
</dependencies>
<properties>
<db.driver>com.mysql.jdbc.Driver</db.driver>
<db.dialect>org.hibernate.dialect.MySQL5Dialect</db.dialect>
<db.url>jdbc:mysql://localhost/${mysql.schema}</db.url>
<db.hbm2ddl>update</db.hbm2ddl>
</properties>
</profile>
When is run maven install with "db-localhost-mysql" it includes the "mysql-connector-java" jar file in lib directory. Now I do clean install with "db-localhost-oracle" and it includes the both "mysql-connector-java" and "ojdbc6" jars in the lib directory.
How can I make it like, if I build with one profile maven automatically remove the jars for other profile?
Your problem does not match what should happen in practice. Your profile definition sounds about right to me:
mvn clean install will enable the db-localhost-mysql (as it is marked as to be activated by default) and it will add mysql-connector-java. The same will happen if you run mvn clean install -Pdb-localhost-mysql
mvn clean install -Pdb-localhost-oracle will add the ojdbc6 driver. The mysql profile will not be enabled (as it is triggered only if no profile is explicitly active).
That does not mean your current dependency hierarchy hasn't already one of those jars. It might come as a transitive dependency. To isolate this case and know which project needs to be fixed run mvn dependency:tree -Pdb-localhost-oracle to look at your dependencies hierarchy when the mysql profile is not enabled.
I assume you download your downloaded dependencies using maven-dependency-plugin somewhere outside your target dir (${basedir}/lib).
If that is the case, you would need to include your lib dir inside your clean definition (see http://maven.apache.org/plugins/maven-clean-plugin/examples/delete_additional_files.html):
<build>
[...]
<plugin>
<artifactId>maven-clean-plugin</artifactId>
<version>2.5</version>
<configuration>
<filesets>
<fileset>
<directory>lib</directory>
</fileset>
</filesets>
</configuration>
</plugin>
[...]
</build>
However: Please consider doing it differently:
do not have your regular build change anything outside the target directory, if possible (which would have prevented your problem in first place), instead download to something like target/lib
Please do not use profiles to change the outcome of your build. This is dangerous. (see http://www.blackbuild.com/how-to-really-use-maven-profiles-without-endangering-your-karma/ for an extended explanation)
If you want different outcame consider Maven Assemblies.
I have a module whose pom file is:
<groupId>com.mycompany.Common</groupId>
<artifactId>common</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>common module</name>
In that artifact ('common'), I have a package named com.mycompany.common.objects. In the consuming package, my pom file is:
<dependency>
<groupId>com.mycompany.Common</groupId>
<artifactId>common</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
</dependency>
When I run mvn install it always complain: package com.mycompany.common.objects does not exist.
I tried explicit importing in the class where the error was:
import com.mycompany.common.objects
No luck. I tried in both the IDE (IntelliJ) and in commandline. Any idea? thanks
While working with IntellijIDEA, generated files can cause this issue. Writing
mvn idea:idea
on IntellijIDEA Maven console to reset those files did the trick for me. Also, see:
Package doesn't exist error in intelliJ
From your sample, we cannot see any artifact containing the package com.mycompany.common.objects you are using.
You are adding dependency com.mycompany.Common:common as a POM (and you are declaring the packaging of com.mycompany.Common:common as POM too). If it is actually a JAR artifact that contains the package you need to use, then remove the packaging from the POM and dependency (which means, using default which is JAR).
For anyone struggling with this and not familiar with java, make sure that the said package exists in your local repository. Maven has a local repository ~/.m2 where the packages are installed for local access, so even if your dependency package is correctly declared as a dependency in pom.xml and is compiled and exists in your project, if it does not exist in the local repository, the mvn compile will trigger a "package does not exist" error.
To fix this:
In the missing package folder, do:
mvn install //--> this will package and install your missing package in the local repo
Then in your project that you wanted to compile:
mvn compile // --> now that the missing package is in the local repo it should work
Please correct me, If I'm wrong. I understand that the common is a POM that defines several dependencies which intents to be used by other modules. The Importing Dependencies may meet your requirement.
For example
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.mycompany.Common</groupId>
<artifactId>common</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
I hope this may help.
I had the same problem recently. Everything in my project was setup correctly with dependencies etc. I tried removing /target dirs but nothing worked.
Finally, I solved it by removing the Module Dependency from my dependent project and then readding the dependency. Not sure what is going on in the background, but some sort of refresh of the classpath must have been made. Perhaps the problem was due to the Maven setup.
Hope it helps someone who reaches this question from a search engine.
Not sure if there was file corruption or what, but after confirming proper pom configuration I was able to resolve this issue by deleting the jar from my local m2 repository, forcing Maven to download it again when I ran the tests.
For me the problem was with the sourceDirectory and testSourceDirectory nodes in my pom.xml.
I was using
<sourceDirectory>${basedir}/src/test</sourceDirectory>
<testSourceDirectory>${basedir}/test</testSourceDirectory>
and changed it to
<sourceDirectory>../src/test/java</sourceDirectory>
<testSourceDirectory>../src/test/java</testSourceDirectory>
Your IDE (Eclipse in my case) may not distinguish between compile and runtime scope. This means that the IDE will let you use runtime scope dependencies in your code, but maven won't. In such a such change the dependency scope from runtime to compile.
you need to add the maven-plugin into (each) child module (for compiling main and test source)
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugins>
and then you add the plugin-management into the parent pom, for centralizing the plugin config (version...)
<pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</pluginManagement>
Then you can add your dependency into the dependent module pom
<dependency>
<groupId>com.mycompany.Common</groupId>
<artifactId>common</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
</dependency>
http://www.jouvinio.net/wiki/index.php/Projet_Maven_multi-modules
I hope I'm explaining this as accurately as possible, and I want to know if I set up the maven dependencies correctly, or if there's a better way to do it.
Most of my development team's projects rely on a home-grown jar that is deployed at server class loader. The reason for this jar to reside at this level is to the ease of updating the jar at one place without repackaging each project that's using it, assuming changes made to it are backward-compatible.
I develop my web apps against Jetty in my local development. So, in order for the web apps to work locally, I set up the dependencies this way:-
<dependencies>
<!-- Configuring external jar dependency -->
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${env.EXTERNAL_JAR}</systemPath>
</dependency>
...
</dependencies>
<build>
<plugins>
<!-- Configuring Jetty -->
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<version>6.1.26</version>
<configuration>
<contextPath>/${project.parent.artifactId}</contextPath>
<jettyEnvXml>${env.JETTY_ENV_XML}</jettyEnvXml>
<scanIntervalSeconds>1</scanIntervalSeconds>
<connectors>
<connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
<port>7777</port>
</connector>
</connectors>
<webAppConfig>
<extraClasspath>${env.EXTERNAL_JAR}</extraClasspath>
</webAppConfig>
</configuration>
</plugin>
...
</plugins>
</build>
In this approach, I set up an environment variable that points to the external jar path, and reference it in my pom.xml as ${env.EXTERNAL_JAR}.
After doing some reading, it seems like using "system" scope is considered a bad practice. So, I installed this external jar in Nexus and change the scope to "provided":-
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
<scope>provided</scope>
</dependency>
This allows me to compile my project properly, but I'm not sure if it is even possible for me to get rid of the "EXTERNAL_JAR" environment variable completely because it's still needed by Jetty for the runtime to work properly. My take is using "provided" scope is a little tedious and more work, because I now need to remember to update the jar in Nexus when it is modified AND I still need to update the jar located at the path pointed by the environment variable.
Is there a way for me to expose the external jar to Jetty through maven dependencies, yet not being packaged into the project when the war file is built?
What are you advice on this? Should I just stick with "system" scope so that I just need to update the jar at one place, or should I use "provided" scope? Or if there's even a better way to do this?
Thanks much.
You should be able to add dependencies to the jetty plugin. And then I have the provided scope for the project itself.
http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin
as in
<project>
...
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<configuration>
<systemProperties>
<systemProperty>
<name>logback.configurationFile</name>
<value>./src/etc/logback.xml</value>
</systemProperty>
</systemProperties>
</configuration>
<dependencies>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.15</version>
</dependency>
</dependencies>
</plugin>
...
<project>
The best thing to do is setup an external repository with your dependency, and add it to your pom.
<repositories>
<repository>
<id>my-repo</id>
<name>my-repo</name>
<url>http://your.repo.url</url>
</repository>
</repositories>
and then you can add your dependency as
<dependency>
<groupId>com.test.app</groupId>
<artifactId>app-jar</artifactId>
<version>1.0</version>
</dependency>
I approve of provided. Provided means - download the dependency for compile-time, but I expect to see it on classpath on the application server.
I did not realize you care only for your local development, so the following would be useful if you were running Jetty on an external server:
Maven will let you deploy a file to a server using the Wagon plugin. So a part of your build process could be pushing the proper .jar into your Jetty server. That way you would not have to do it manually. I would prefer this solution to running a local Maven repository on the Jetty server as suggested by #Paul.
If you wanted to be super-clever (usually a bad idea), you might try to set up a repository directly on the machine with Jetty, that would serve the jar directly from your Jetty install. That way you would not have to modify Nexus, the jars would be only at one place. You can even set up Nexus to mirror another repository, so it could pick things up automatically.
It is a bad practice to modify .jar contents and keep the same Maven coordinates. So this "clever" approach would not work that great anyway.