mybatis-generator-maven-plugin has dependencies of sisu-guava(maven-plugin-api) and google-collect(plexus-container-default). Both of them has com.google.common.collect.Ordering class, but
the one in google-collect does not have the "reverse" function. How can I make sure the reverse function in sisu-guava is called.
Also， why the war package has maven related jars like "maven-plugin-api-3.0.4.jar" 、"maven-model-3.0.4.jar". I don't think they are useful for tomcat .
It sounds like you have a plugin as a dependency defined in your pom which is simply wrong. If you need to use a plugin use it as plugin and NOT as dependency.
Related
We have splunk-library-javalogging as compile-dependency and added com.squareup.okhttp3/okhttp as a test-dependency. okhttp is also a compile-dependency of the splunk-appender.
Using spring-boot-maven-plugin we realized the okhttp-Dependency is no longer included, when added as a test-dependency. Removing it, it is included again.
So it seems scoping okhttp as test overrides the transitive compile-dependency (excluding it from the jar) - and this doesn't feel correct!?
This does not feel correct, but it is unfortunately the case.
Maven determines the scopes first, then creates the classpaths. And direct dependencies override transitive ones.
It would be smarter to create the compile classpath by just ignoring test scoped dependency entries, but this is not how Maven does it.
Quintessence: Only add a test dependency if the dependency is not already in mvn dependency:list.
I am trying to install some dependencies using maven in a spring boot project.
I am looking for a jar
org.apache.maven.plugins:maven-resources-plugin:jar:3.1.0
But I wanna know if the jar file should have this name maven-resources-plugin, or if the file name is not important for maven. I mean if maven will automatically know which jar file should use.
I will appreciate any help or feedback.
That is a plugin, not a dependency as such (meaning that Maven needs it for building your project, your code doesn't need it to compile or run).
You should only have to specify the plugins groupId, artifactId and version plus any configuration in your pom.xml, and Maven knows exactly what jar to get and how to use it.
See https://maven.apache.org/plugins/maven-resources-plugin/plugin-info.html for further information.
I'm trying to override a dependency version through a maven profile. I did a test installing the war and it works. The problem is when I run the war using maven tomcat plugin. I wanted to check which version of the jar is used, but I have no idea where it reads the jars from. I cannot find anything useful on available documentation..
Any help?
I believe this page will help you to understand: http://tomcat.apache.org/maven-plugin-2.2/tomcat7-maven-plugin/adjust-embedded-tomcat-version.html
Use the dependencies section in plugin section
HTH
I've spent a lot of time and my head is blowing up already so I'll be very thankful for any help.
I'm migrating Netbeans Platform application from ant to maven, and so I'm changing all the jars in my version control repo to maven dependencies. I've found needed artifact in main maven repo and I've added it as a dependency with a help of Netbeans, but it's of type POM and was placed in Non-classpath Dependencies and I have no idea how to use it as it wasn't added to classpath etc…
Can someone explain what are these POM dependencies and how to use them?
Thank you in advance!!
EDIT
here is dependency definition in pom.xml
<dependency>
<groupId>com.kitfox.svg</groupId>
<artifactId>svg-salamander</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>
Adding a pom dependency only pulls down transitive dependencies, that is jar dependencies defined as dependencies in the pom. The pom does not get added on the classpath for obvious reasons, but the transitive dependencies reachable from pom will be added to classpath.
What you ideally need to do is have dependencies of type jar Default dependency type is jar and you can simply define dependencies without any type element in the dependency section.
If you have located the jar files you need in Maven Cental, then you simply need to provide groupId artifactId and version for each one of those in dependencies section.
Personally I cannot think of any case when one would need to add pom type dependency. I usually use pom packaging for parent module in a project (specify common project configuration like plugin versions, common dependencies, like log4j for example, repositories, properties etc.) and for utility package module (the one that assembles the project and does some other necessary things).
Judging from my experience (I did it several times), when migrating project from ant to maven you should take all the jar files that your project used to depend on and convert them into maven dependencies (groupId:artifactId:version). Most probably all of these dependencies will not have any <type> (e.g. be jars).
We have created a new artifact to generate javadoc. We have 40 artifacts defined as dependencies. Task is to create javadoc.jar and html pages for the 40 dependency artifacts.
Whats the best approach to achieve this in maven?
This is very unusual. Javadoc works on sources, not compiled classes, whereas maven dependencies reference classes, not sources.
So to make this work you'll have to do all of this:
since this is a dedicated javadoc artifact, it won't have a main JAR artifact, so you'll probably want to set the packaging to POM
make sure all your referenced artifacts have attached sources
add <classifier>sources</classifier> to all your dependencies
unpack all dependencies to a common root folder using dependency:unpack-dependencies
run javadoc on that folder
create a jar using the maven-assembly-plugin
attach that jar to the build using the buildhelper plugin
On re-reading the question: I'm assuming that you want to create combined docs of all dependencies. If not, you'll need 40 separate executions each of the javadoc, assembly and buildhelper plugins. Good luck with that.
A slightly more automated approach than the answer above:
So to make this work you'll have to do all of this:
since this is a dedicated javadoc artifact, it won't have a main JAR artifact, so you'll probably want to set the packaging to POM
make sure all your referenced artifacts have attached sources
add <classifier>sources</classifier> to all your dependencies
unpack all dependencies to a common root folder using dependency:unpack-dependencies
Change your sources directory to where you unpacked all the dependencies
Use the source plugin to manage all the Javadoc generation and deployment