I learned Spring via Spring In Action 3 few month ago. I downloaded Spring libraries from official site (list was like in SIA3(aop, asm, aspects, beans ...)), added them to my project and everything worked fine. Now I want to use Maven, but I am getting a lot of errors and sinking in searching what library to add.
I am newby, dont know all Spring dependencies(within it libs) and the question is not about my errors, but about the way to add all Spring libraries to my project via Maven. How do you usually add Spring libs using Maven?
You don't have to download the libraries themselves anymore. That is what Maven is for. (and quite some more, of course)
set up Maven properly
set up Maven in the IDE tool you have (like this)
edit the pom.xml to include what you need, adding the dependencies in the in the dependencies tag.
Maven takes care of resolving the dependencies of the specified packages. If a package depends on other packages, it will do it for you. You only have to specify the packages you directly need
For example
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
</dependency>
You can easily find the packages using Google, and searching for "maven repository "
Avoiding version clashes
Also, as Bart mentioned, the common way of having Spring in the pom.xml - as it has way too many versions, and clashes can occur - is through a common property specifying the version for all Spring components. (Based on this answer)
Specify the property in the properties tag:
<properties>
<spring.version>3.0.5.RELEASE</spring.version>
</properties>
Then use it in the dependencies like this:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
Be careful to use it for ALL components to avoid version clashes. (of course, issues mught still occur, bz having different libraries reference spring too, but that is another story in its own.)
Side note
Keep in mind note that Maven projects use specific directory layout. When I first started using maven for my own projects, first I created a new blank one, and played around with it, before I began migrating my older projects to use maven. Believe me, it pays off.
Add spring artifacts to your pom.xml file. For example
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>3.2.4.RELEASE</version>
You can find more artifact info here
http://mvnrepository.com/
HERE you can find the dependencies as per your requirement. Just click on the dependency and inside click on the latest release, scroll down there is your code inside the <dependencies> Your required dependency and version</dependencies>.
Just copy the XML code and paste it in your pom.xml file.
Related
I am trying to create a maven version of the gradle-based treehouse 'unit-testing-a-spring-application' project used in this course. See course code here.
After not being able to build initially, I ended up adding dependency versions specified in the original gradle build file. Maven will build fine, but running the app gives this:
The following method did not exist:
org.springframework.data.repository.config.RepositoryConfigurationSource.getAttribute(Ljava/lang/String;)
Ljava/lang/String;
The method's class, org.springframework.data.repository.config.RepositoryConfigurationSource, is
available from the following locations:
jar:file:/C:/Users/home/.m2/repository/org/springframework/data/spring-data-
commons/2.1.6.RELEASE/spring-data-commons-2.1.6.RELEASE.jar!/org/springframework/data/repository/config/RepositoryConfigurationSource.class
It was loaded from the following location:
file:/C:/Users/home/.m2/repository/org/springframework/data/spring-data-commons/2.1.6.RELEASE/spring-
data-commons-2.1.6.RELEASE.jar
Action
Correct the classpath of your application so that it contains a single, compatible version of
org.springframework.data.repository.config.RepositoryConfigurationSource.
Several similar problems are solved here on S.O. by changing the version of some related dependency. I have tried various versions of the following to no avail (I stick normally with spring-boot-starter-parent v2.1.4 cause it works all the time with my projects):
spring-data-commons
spring-boot-starter-parent
I see the needed class below listed in my project Dependencies directory, but what dependency versions will work in this case? How can I solve this otherwise?
org/springframework/data/repository/config/RepositoryConfigurationSource.class
I looked at your code and found some mistakes. Since your project is a spring-boot one, you mustn't add direct spring dependencies in your pom file. Instead try to use spring-boot based dependencies. For instance, instead of having such this dependency:
<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-jpa</artifactId>
<version>1.9.2.RELEASE</version>
</dependency>
You must have the following one in your pom file.
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
I am currently learning Maven for a specific project. In this project, I need to have multiple modules (in the sense of a collection of classes and resources) that depend on each-other. Specifically, I need a module to store the classes of a public-facing API (the API is a Java API, as the desktop program can load addons at runtime), another for a set of common classes that are shared between the client and server but that are not part of the API, and of course the client and server themselves need a module each.
Using the system that I used before Maven (IntelliJ Idea's build system), I would simply create different modules and setup dependencies using IntelliJ's GUI. This works well because I can then put the whole IntelliJ Idea project in a git repository, and keep everything nicely tracked together with no fuss and no problems.
When researching how to do this in Maven, however, I ran into some problems. Maven's documentation has a section that seems to explain how to accomplish something similar, but its technique seems to have two problems. When Each sub-project, with its own pom.xml, needs to specify the version of the other sub-projects that it depends on¹. This implies that I need to make many changes all over the project whenever the version changes. This will (hopefully) be quite frequent. As it is perfectly plausible that my project will grow to have hundreds of modules, this is obviously impractical.
Additionally, based on my other research, it seems like a Maven repository is involved in the documented technique. Specifically, it seems like when, for example, the API module is built to be included in the client and server modules it will first be placed in a local repository and then the client and server modules will retrieve it from there. This sounds problematic as the API module will also be published in a public repository (maybe Maven central, I haven't really thought about this too much -- but it will be public in a repo), and this repository step seems like it could end up building the client and server with a published jar rather than the local one, which is problematic for many reasons. (eg. if a developer is making local changes to the api jar, building half the project without those changes is a problem).
Is there some better way to combine multiple modules to mitigate these problems (versions all over the place, and getting wrong jars from repos)? Is it better to modify the technique in the linked documentation instead? Am I misunderstanding something and the problems don't exist?
I have checked DuckDuckGo and all relevant questions that I can find on StackOverflow, and none address either of the two aforementioned problems.
¹:
<dependencies>
<dependency>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
In your multi-module project, you usually use just one version for all modules. This means that you can define dependencies between modules with <version>${project.version}</version> where the property ${project.version}$ is resolved during the build. Maven builds all the modules in the correct order.
Regarding your first question: you can create a parent pom over your whole project. In this parent pom you can add a dependencyManagement section where you can list your own modules with their version. In your modules you then only need to specify the dependeny without the version.
Here an example:
in parent pom:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>yourgroup</groupId>
<artifactId>yourmoduleA</artifactId>
<version>3.0.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>yourgroup</groupId>
<artifactId>yourmoduleB</artifactId>
<version>3.0.1-SNAPSHOT</version>
</dependency>
</dependencies>
</dependencyManagement>
and if your module A uses module B, you can add in pom of module A
<dependencies>
<dependency>
<groupId>yourgroup</groupId>
<artifactId>yourmoduleB</artifactId>
</dependency>
</dependencies>
I never worked with Maven before, but after having a lot of problems with mockito dependencies in my Netbeans module, I decided to create a new one using Maven and move everything to this new project. After some time doing so, I managed to get the module running just ok.
The problem is that when I use some functionalities that require the Netbeans API I get an exception.
My guess is that the problem is in the dependencies declared in pom.xml. In some of the imports that I use in my application, I get the following message:
Package from transitive module dependency referenced, declare a
direct dependency to fix.
When I clean and build or run mvn clean install in the root directory I get this error:
Project uses classes from transitive module
org.netbeans.api:org-netbeans-modules-projectapi:jar:RELEASE73 which
will not be accessible at runtime.
To fix the problem, add this module as direct dependency. For OSGi bundles that are supposed to be wrapped in NetBeans modules, use the
useOSGiDependencies=false parameter
In the org.codehaus.mojo plugin declaration (which was the only one that had the useOSGiDependencies tag) I tried to change useOSGiDependencies=true to useOSGiDependencies=false but that didn't work. I also tried to change RELEASE73 to RELEASE82, since I am using Netbeans 8.2 but that didn't work as well. I also tried a bunch of other possible solutions that I found on google, but none seemed to work for me.
These are the Netbeans api dependencies that I have in my pom.xml file:
<dependencies>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-netbeans-modules-project-libraries</artifactId>
<version>RELEASE73</version>
</dependency>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-netbeans-api-annotations-common</artifactId>
<version>RELEASE82</version>
</dependency>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-openide-util</artifactId>
<version>RELEASE82</version>
</dependency>
<dependency>
<groupId>org.netbeans.api</groupId>
<artifactId>org-openide-awt</artifactId>
<version>RELEASE82</version>
</dependency>
<dependency>
<groupId>org.netbeans.modules</groupId>
<artifactId>org-netbeans-core</artifactId>
<version>RELEASE73</version>
</dependency>
<!-- ... -->
</dependencies>
I looked everywhere but couldn't find a straightforward answer on how to declare a direct dependency.
Can anyone explain to me what am I doing wrong here?
After digging a bit more, I found that I had to add all the dependencies manually. This answer helped me a lot.
I just lack experience with maven. Basically I googled org-netbeans-modules-projectapi:jar:RELEASE73 maven entered the first link and added the needed dependency to my project.
I am new to Maven and am setting up my first maven project. I am also creating some maven assets in the form of some poms that can be inherited from or used as dependencies in any future projects as well. I want to group dependencies together and to be able to selectively add them to a project as needed.
I read this article on pom best practices. I like the idea of grouping related dependencies together into poms and then adding the pom as a dependency to a project as needed. This approach works great for compile scoped dependencies. However it fails for provided scoped ones since as transitive dependencies, they get omitted.
Here's an example of what I mean: Lets say I group together web dependencies for my projects into a web-deps pom.xml. These include compile scoped spring framework dependencies and also a provided scoped javaee one:
<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>mvn-web-deps</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>${org.springframework.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>${org.springframework.version}</version>
</dependency>
<dependency>
<groupId>javaee</groupId>
<artifactId>javaee-api</artifactId>
<version>${javaee.version}</version>
<scope>provided</scope>
</dependency>
</dependencies>
I then add this pom as a dependency in another project:
<modelVersion>4.0.0</modelVersion>
<groupId>com.xyz</groupId>
<artifactId>project-a</artifactId>
<version>0.0.1-SNAPSHOT</version>
<dependency>
<groupId>com.xyz</groupId>
<artifactId>mvn-web-deps</artifactId>
<version>0.0.1-SNAPSHOT</version>
<type>pom</type>
</dependency>
The dependencies in mvn-web-deps now become transitive. Since the dependency reference above is compile scoped, the provided transitive dependency gets omitted.
I want to avoid adding them to the dependency section of a parent since there can only be one parent and a project may need only some of these dependency groups, not all. I can perhaps add them to the dependencyManagement section, but then I will have to redeclare each dependency (sans the version) in each child project.
What is the correct/better way of grouping dependencies while avoiding the issues like above?
The short answer to your question is that you should only include 'provided' dependencies locally where the code requires it to compile, but not in parent pom.xml or other structures. Indicating that you have a 'provided' dependency in global pom.xml is non-sense for maven, because it does not need it to compile in such pom.xml.
Here is the long answer:
When I started using Maven, I had the same idea of trying to group artifacts and dependencies into pom.xml modules hoping they would be useful in the future. Now, that I have a bit more experience, I got to understand that it is a complete waste of time. For me, this was form of over-engineering.
I have learned to split my big projects into separate modules, each in their own subversion repository. I am including dependencies as necessary for each local module in their pom.xml. I release versioned tags of each module as I am coding and as necessary (i.e., when tested and stable).
I build my big projects by creating a separate maven project with its own pom.xml and import my modules as dependencies. From time to time, I update the module's version in the dependency when I have made a release. Then, I let maven do the job of pulling whatever it has to pull, transitively of not, when compiling/releasing the big project.
Maven allows all sorts of complex constructions and hierarchy between pom.xmls, but IMHO this feature creates unnecessary mess and complexities. So far it has not proved to be a real benefit for me. At the beginning, I was hoping that compiling one pom.xml would compile the rest properly in a cascading way. I did get some result, but what a mess to maintain in all the global pom.xml.
Releasing my module's artifacts separately and building my project on these releases has saved me so much time that I can only recommend it. In total, I have less pom.xml to maintain and they are also less complex. For the same final result...
So, if your only reason for building global/structural pom.xml is a hope to save time, I recommend abandoning this idea... Separate code in separate projects, release and THEN compile globally.
I concluded that Maven was not designed for this kind of use-case. I ended up having a parent pom.xml with all the libraries I use added to its <dependencyManagement> section. Any new projects/modules that I create have their pom.xml inherit from the parent pom.xml and add each dependency they need to their own <dependencies> section, minus the version. This scheme allows me to manage the versions for the libraries that I use and the respository declarations they need at a single place. Another advantage (over trying to create dependency bundles somehow) is that this gives more fine-grained control over the libraries added to child poms - only the dependencies that are actually needed are added.
Provided-scope dependencies are indeed inherited from parent POM, but NOT from POM defined as dependencies and I consider that a Maven weakness.
Given that Maven has also difficulties in adding modules as dependencies across module hierarchies, I can't say Maven is a sophisticated tool to manage multi-module projects. Maven expects a strict single-rooted hierarchy that is only suitable for the simplest projects.
I'm trying to use RichFaces in my learning JSF application. I have set up Maven using
https://repository.jboss.org/nexus/content/groups/public-jboss/
I have included the dependencies
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-components-ui</artifactId>
<version>4.0.0.Final</version>
</dependency>
<dependency>
<groupId>org.richfaces.core</groupId>
<artifactId>richfaces-core-impl</artifactId>
<version>4.0.0.Final</version>
</dependency>
<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-components-api</artifactId>
<version>4.0.0.Final</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.richfaces.core</groupId>
<artifactId>richfaces-core-api</artifactId>
<version>4.0.0.Final</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
This has fetched guava-r08.jar.
When I try to run the project in Tomcat7 I see a lot of class load exceptions - failing to load classes that I can see exist within guava-r08.jar along with sac-1.3 and cssparser-0.9.5.
If I try to use the source instead - taking source from guava-r09 - Eclipse tells me that it cannot find classes such as javax.annotation.Nullable. Problem is neither can I!
Where can I find these classes, or am I taking the wrong approach from the start?
Thanks
Richard
Maven configuration for RichFaces dependencies
Tomcat fails to load these classes, because RichFaces' dependency on Guava has a runtime scope. Contrary to the compile scope, these dependencies are not added to the classpath when compiling. You must include them yourself.
To achieve this, you should include richfaces-bom in the dependency management section of your POM, as explained in this JBoss wiki article. This will include Guava and all other required dependencies RichFaces might need.
This is the "Bill of Materials" (BOM) pattern. The JBoss wiki explains this pattern far better than I would, and links to other articles on the subject.
javax.annotation.Nullable warnings in the Guava source
These occur because Guava uses JSR 305 annotations. It is not required to depend on the JSR 305 jar when using Guava, because annotations do not require to be present on the classpath once compiled. Of course, if you want to use #Nullable and other such annotations in your code (you definitely should), you'll need to add a dependency on the JSR 305 jar.
I have started from scratch using instructions at jboss.org
I installed Maven 3.0.3
I copied the supplied settings.xml to my .m2 directory and added the JBOSS section from 1
I used the command line to create the project:
mvn archetype:generate -DarchetypeGroupId=org.richfaces.archetypes \
-DarchetypeArtifactId=richfaces-archetype-simpleapp \
-DarchetypeVersion=4.0.0-SNAPSHOT \
-DgroupId=uk.m0rjc \
-DartifactId=jsfplay
I then built the project. I had to remove the previously downloaded guava jars from my m2 repository because they were corrupt - perhaps my initial problem.
mvn clean package
I copied the WAR file it produced to Tomcat and navigated to the sample page at localhost:8080/jsfplay-1.0-SNAPSHOT/
I had some issues making the project work in Eclipse. These may be due to my setup from previous experiments.
I used the "Import -> Maven -> Existing Maven Project" to import it
I had to switch the project to JDK 1.6 and 1.6 compatibility mode.
I was unable to use the JavaServer Faces facet. This does not seem to matter.
I had to set my Server Profile to use the right JDK
I had to map *.xhtml to the Faces Servlet in web.xml. It may have been corrupted when I pressed a wrong button to accept a JSF addin.
Then it worked!!
Now to try porting my existing code to the new project.