I am looking at jar hell right now between selenium and a google cloud jar. selenium is a bit out of date but in trying to see the versions in the pom file found here, I see no versions...
https://repo1.maven.org/maven2/com/google/auth/google-auth-library-oauth2-http/0.17.1/
How to tell what the version of guava that it will use is?
I saw something like this but not sure how to run it
mvn -P help:effective-pom -Dverbose
I use gradle so not sure how to point that at the remote artifact. I can use gradle to see what version it's bringing in, but what I don't get is how there is no version in the pom file and where gradle is getting it from. I am praying it's not just bringing in the latest version as that would be really really bad and create an unreproducible build over time where if we tag a version of our release, later when we build, it would bring in the wrong jars and could break. Where is the version coming from for guava there?
thanks,
Dean
The POM defines a parent POM, which is
https://repo1.maven.org/maven2/com/google/auth/google-auth-library-parent/0.17.1/google-auth-library-parent-0.17.1.pom
Here you find the version of guava as a property, which is then used in the <dependencyManagement>.
Related
I have added the latest version of AEM Mocks (2.7.2) as a Maven dependency in my AEM project. When I try to build my project, I get an error saying that this artifact cannot be found: com.day.commons:day-commons-gfx:jar:2.1.28. So I looked online, found it and added it as a dependency. But now I get the same error when trying to build. Does this artifact still exist? When trying various recent versions of AEM Mocks, I found that they all depend on this missing artifact.
For now, I downgraded to version 2.3.0, which works fine without that artifact but I would like to use the most recent version if possible.
Can anyone please help? Thanks!
This artifact is defined as a workaround, it is explained here in comment:
https://github.com/wcm-io/wcm-io-testing/blob/develop/aem-mock/core/pom.xml#L254:
Workaround for AEM 6.5: The new uber-jar does no longer contain the package com.day.imageio.plugins
It works without any issues for me, so I would check if you have correctly configured Maven repositories. To do it, in your Maven project root type:
mvn help:evaluate
and then:
${project.repositories}
It should list your project effective repositories. Ensure that there is Central Repository (https://repo.maven.apache.org/maven2/) listed. If it is there, then maybe your corporate network cuts requests to external repositories or it was temporarily down.
I'm working in eclipse and I have a problem that I can't import my personal java libraries.
I created the libraries and 'installed' them into my local maven repo (using mvn install). This created a subdirectory related to the 'version' name that was in the POM file from when I ran the command. Which seemed fine.
So in this directory there where the usual jar files and other stuff.
When I released this file I manually changed the name of the version in the POM. going from 0.0.1-SNAPSHOT to 0.0.1-RELEASE
This seems to have worked as I would have expected.
However I can't seem to find import the new release jar.
Using the maven repositories browser in eclipse I can see that the new artifact is in the 'local' repository.
I try to add the dependency in the following methods:
Select the main project -> Maven -> add dependency.
This adds the dependency details into the pom but with a type value detail of <type>pom.lastUpdated</type>
Select the project pom.xml file -> Maven -> add dependency.
This time the artifact for the 0.0.1-RELEASE is greyed out I can select it, but I guess nothing is actually happening.
The original 0.0.1-SNAPSHOT it selectable, and if I use this I do not have a <type> detail in the pom.
I don't understand why there is a difference in the RELEASE and SNAPSHOT artifacts, as they have both been generated in the same way, and clearly they are both visible in the browser, the contents of the directory on disk are the same. The file names and contents are identical with the exception of the word RELEASE or SNAPSHOT.
I know that I can simply add in the RELEASE jar to my build path, but this seems to be a ridiculous thing to have to do if I intend to use maven (or do I need to do this).
I don't want to use an external repo for storing my artifacts, and I'm not too keen to go to the trouble of installing nexus (or similar) on my local machine (just because I've had trouble with it in the past).
What am I missing so as I can get my maven project to see my local repository and all its artifacts.
Thanks in advance.
David
ps I've already tried things such as mvn dependency:purge-local-repository which definitely pulled in / updated all the local jar dependencies.
So I've managed to work around my problem.
As such this solution is ridiculous, and breaks all the purpose of maven.
So I found (from running maven from the cli) that there was an error in the parent of the project I was attempting to use.
The parent was missing a direct link to the scm plugin (version error).
Once I solved this problem, I then returned to the sub project, and got a lot of errors from missing stuff from the parent.
Essentially it was not 'seeing' all the log4j dependencies.
The solution (well non-solution really).
Add all the log4j dependencies to the sub project.
Edit in SCM and surefire test plugins (as it also started to fail the test code due to missing junit).
So this is great.
I have to define all my dependencies on log4j and in my sub / child project's pom.xml file.
I also need to define them all in my parent's pom.
As it then still refused to run tests in my new project (that used the above as a dependency), and refused to find log4j also. I then decided to add all of these as dependencies for my current project.
Great.
I thought the whole point of maven was I could define my dependency on log4j in my my logging library that I use (which is the dependency), and then it would 'automagically' pull in all the required from this dependency.
Clearly not.
As stated at the start. This is NOT AN ANSWER it is a crazy work around.
My logging library that I use should be able to define its own requirement on a specific log4j version (such as moving from log4j to log4j2), and then when I include this as a maven dependency any change to the required dependency should be seen automatically.
But No : I have to import the dependency on log4j in my other projects also. So now if I had updated my logging library from log4j to log4j2 I would need to go to all my project that use this library and update their pom's to ensure that I have the correct version of log4j.
Seems the whole point of maven has just been lost!
Can someone please tell me where I am going wrong!
David.
I recognized that Maven not always uses the latest version of a plugin.
For example org.codehaus.mojo:sonar-maven-plugin version 2.7 has beed released on 19th of October but on 23th of October, 2.6 was still used by Maven (mvn sonar:sonar).
I even remember some plugins, where the latest version was several minor releases above the version that Maven decided to use.
Is there any (central) index/list/database where Maven looks up what version to use? If yes, where can it be accessed manually?
I know this is an ancient thread but in the interest of posterity and accuracy: all pom.xmls logically inherit from the super POM. You can always see what your "real" pom.xml looks like by typing:
mvn help:effective-pom
The resulting pom.xml that is printed is a combination of the super POM, your pom.xml, and of course any parent POMs in the mix as well.
The super POM is provided by the org.apache.maven.model.superpom.DefaultSuperPomProvider class (https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/java/org/apache/maven/model/superpom/DefaultSuperPomProvider.java#L56-L85). The resource it loads is org/apache/maven/model/pom-4.0.0.xml (https://github.com/apache/maven/blob/bce33aa2662a51d18cb00347cf2fb174dc195fb1/maven-model-builder/src/main/resources/org/apache/maven/model/pom-4.0.0.xml#L23-L149).
As far as i know, this link will answer your question.
Automatic Plugin Version Resolution
When a plugin was invoked without an explicit version given in the POM
or on the command line, Maven 2.x used to pick the latest version
available where the latest version could either be a release or a
snapshot. For the sake of stability, Maven 3.x prefers the latest
release version over the latest snapshot version.
Given the threat of non-reproducible builds imposed by automatic
plugin version resolution, this feature is scheduled for removal as
far as plugin declarations in the POM are concerned. Users of Maven
3.x will find it output a warning when missing plugin versions are detected to encourage the addition of plugin versions to the POM or
one of its parent POMs. The Enforcer rule requirePluginVersions can be
used additionally check for missing plugin versions in the POM
For command line execution if a version is not specified Maven looks up the latest version from the GA (group ID/artifact ID) maven-metadata.xml file.
Example: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-clean-plugin/maven-metadata.xml
If you're encoding command line execution of Maven goals into your builds you should specify a version for these, otherwise your builds may change as new versions of plugins are released.
Per a previous question on here, I was able to run:
mvn com.isomorphic:isc-maven-plugin:1.1.1:install -Dproduct=SMARTGWT -Dlicense=LGPL -DbuildNumber=5.0p -DbuildDate=2014-11-30
This did work. But I wonder ... do we need to do this again for the latest build? How do we even know where to find the latest build. I just want to use the latest, stable version, and not a nightly build.
Also, what is the correct dependency for SmartGWT 5.0p in my pom.xml file?
I have the old version which worked with 4.0, or do I need to use a new dependency? Is there anything else I might need to add to my pom.xml file?
Believe I hit Google for the last two days, and even on the SmartGWT Isomorphic site I still couldn't find a definitive answer.
Thanks for any help!
Due to Isomorphic licence scheme unfortunately if you need to update to a newer smartgwt build you cannot rely on maven "by design" features. You should run the install command again changing buildNumber or/and buildDate as desired.
Example
mvn com.isomorphic:isc-maven-plugin:1.1.1:install -Dproduct=SMARTGWT -Dlicense=LGPL -DbuildNumber=5.1p -DbuildDate=2016-01-07
The dependencies in your pom file should then use:
<version>5.1p-20160107</version>
where 5.1p corresponds to the buildNumber value and 20160107 to the buildDate.
Installed files are in ~/.m2/repository/com/isomorphic/smartgwt/lgpl you can check availability and versions there too.
By design, there is no answer: Maven dependency upgrades are manual.
When appropriate, you can look for new releases of your dependency (in this case SmartGWT), find out what the new version is called in the dependency's public Maven repository, update your project's POM, and update your local repository as necessary (mvn install like in the example, deleting old versions, etc.)
With maven-3, it uses aether to resolve dependency.
Unfortunately, "mvn dependency:tree" use legacy (maven-2) resolution engine.
How do I find out the true dependency resolution for maven-3. I'm running into an issue where "exec:exec" creates different classpath then "dependency:tree".
In maven 3 - compatibility notes, it says I need to use "-X" and look at the log but there is no pointer what to look for.
Also, "assembly:assembly" brings in different 'jar' than when I print out classpath from "exec:exec".
dependency:tree is the correct way to get the project dependencies. Since version 2.5 of the plugin it now resolves the tree using aether.
exec:exec runs the maven exec plugin. The classpath it generates is based on the plugin dependencies, if specified. It is relevant only for the purpose of the plugin execution and not to be taken in the context of project.
The similar explanation holds good in case of assembly:assembly. The jars that it brings in entirely depends on the plugin and assembly-descriptor configuration.
Since version 2.5 of the Maven Dependency Plugin, dependency:tree works with Maven 3 (see the bug report, and the release notes)