A dependency of one of our projects cut a new release four weeks ago -- 1.8.0.
The Nexus metadata duly lists this version as available:
<metadata modelVersion="1.1.0">
<groupId>com.splunk.logging</groupId>
<artifactId>splunk-library-javalogging</artifactId>
<version>1.7.3</version>
<versioning>
<latest>1.8.0</latest>
<release>1.8.0</release>
<versions>
<version>1.0.1</version>
<version>1.5.0</version>
<version>1.5.1</version>
<version>1.5.2</version>
<version>1.5.3</version>
<version>1.5.4</version>
<version>1.6.0</version>
<version>1.6.1</version>
<version>1.6.2</version>
<version>1.7.0</version>
<version>1.7.1</version>
<version>1.7.2</version>
<version>1.7.3</version>
<version>1.8.0</version>
</versions>
<lastUpdated>20200117004445</lastUpdated>
</versioning>
</metadata>
In the project's pom.xml file, the dependency's version is set as <version>[1.7.2,)</version> and so Maven is trying to download the newly-available 1.8.0. And fails, because our Nexus does not have it for some reason.
Our private Nexus is simply proxying nexus.pentaho.org -- which has the same (at the time of this typing) metadata file as I copy-pasted above, but not the actual splunk-library-javalogging-1.8.0.jar -- though earlier versions are available.
Is that, perhaps, because the <version> in the above metadata is still set to 1.7.3 -- even though both the <latest> and the <release> are set to 1.8.0?
Why would that be, and how should I deal with it -- without explicitly excluding 1.8.0?
The problem is on the remote web site... the maven-metadata.xml file from that site is showing 1.8.0, but that version isn't available:
https://nexus.pentaho.org/repository/proxy-public-3rd-party-release/com/splunk/logging/splunk-library-javalogging/1.8.0/splunk-library-javalogging-1.8.0.pom
Note that version 1.7.3 is available:
https://nexus.pentaho.org/repository/proxy-public-3rd-party-release/com/splunk/logging/splunk-library-javalogging/1.7.3/splunk-library-javalogging-1.7.3.pom
You'll need to either get the maintainers of that site to fix this, or lock down your version to 1.7.3.
Related
I cloned the repository at the G1ANT.Robot github page and opened G1ANT.Sdk.sln in VS Studio 2019 CE 16.1.5, Win10 Pro with latest updates. I left the default build properties as "Debug" and "AnyCPU". The following error can't be resolved, as I don't have the required files on my system:
Severity Code Description Project File Line Suppression State
Warning Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.CoreUtility, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. G1ANT.AddonTemplate
There are other errors, all seemingly related to dependencies on an earlier version or versions of VS (some I believe to be v14.0 dependent, some to be v15.0 dependent).
I do have the Microsoft.VisualStudio.CoreUtility available, but the version is 16.0 (i.e. VS 2019). In short, it appears that compilation may require an earlier version of VS than the one I have. Installing such an earlier version is not an option for me.
Thanks,
burque505
Yes, file /G1ANT.Sdk/G1ANT.Sdk/source.extension.vsixmanifest should be changed:
<Installation>
<InstallationTarget Id="Microsoft.VisualStudio.Community" Version="[15.0,]" />
<InstallationTarget Id="Microsoft.VisualStudio.Pro" Version="[15.0,]" />
<InstallationTarget Id="Microsoft.VisualStudio.Enterprise" Version="[15.0,]" />
</Installation>
<Dependencies>
<Dependency Id="Microsoft.Framework.NDP" DisplayName="Microsoft .NET Framework" d:Source="Manual" Version="[4.6.1,)" />
</Dependencies>
You can download the correct installation: https://github.com/G1ANT-Robot/G1ANT.Sdk/raw/master/G1ANT.Sdk.vsix
I believe it will help :)
I am using Vaadin 8 and want to add-on latest 3.0.0.beta1 vaadin-context-menu.
The maven update and build works fine but Tomcat fails to start with
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-context-menu</artifactId>
<version>3.0.0.beta1</version>
</dependency>
I am getting Error with Message "java.util.zip.ZipException: invalid LOC header (bad signature)"
However, I able to successfully implement Context Menu for version 2.1.0
<dependency>
<groupId>com.vaadin</groupId>
<artifactId>vaadin-context-menu</artifactId>
<version>2.1.0</version>
</dependency>
The error indicates that the JAR is broken. There is a bug in Eclipse's maven that breaks JARs randomly. Just delete it from .m2 cache and let maven redownload it.
The bug is described here https://bugs.eclipse.org/bugs/show_bug.cgi?id=534228
There is another StackOverflow discussion about the corrupt JAR's here, with solution how to find them: Deploying Maven project throws java.util.zip.ZipException: invalid LOC header (bad signature)
find /home/me/.m2/repository/ -name "*jar" | xargs -L 1 zip -T | grep error | grep invalid
I have a case where I need to build what could be considered a patch between 2 versions of the same object. I am using Maven 3.1.1
<dependency>
<groupId>my.group.id</groupId>
<artifactId>artifact1</artifactId>
<!-- managed version from parent pom -->
<!-- 1.0.1-SNAPSHOT -->
<type>zip</type>
</dependency>
<dependency>
<groupId>my.group.id</groupId>
<artifactId>artifact1</artifactId>
<version>1.0.0</version>
<type>zip</type>
</dependency>
I use the maven-dependency-plugin to unzip them into different directories during the build process. The exec-maven-plugin is used to execute an external tool that creates what is essentially a patch.
This all works.
The problem is a warning
[WARNING]
[WARNING] Some problems were encountered while building the effective model for my.group.id:build-patch:pom:1.0.1-SNAPSHOT
[WARNING] 'dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: my.group.id:artifact1:zip -> version (?) vs 1.0.0 # my.group.id:build-patch:[unknown-version], /my/jenkins/workspace/directory/stuff/build-patch/pom.xml, line 163, column 15
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
I know this is only a warning
However I want to make the build as clean as possible. Also note that the groupId:artifactId:type:classifier will never be unique. How can I set this up so that there are no warnings? Does anyone else suspect that this may be a problem in the future?
I have a project using spring mvc, and neo4j. After upgrading the dependencies, I am now getting the error "java.lang.NoClassDefFoundError: org/neo4j/cypherdsl/grammar/Execute". I want to see if I'm using incompatible packages together.
I changed packages to the following:
neo4j-kernel: 1.8.2
neo4j-cypher: 1.8.2
neo4j-cypher-dsl: 1.7
spring-data-neo4j: 2.1.0.RELEASE
spring-data-neo4j-rest: 2.1.0.RELEASE
When browsing the neo4j-cypher-dsl-1.7, I don't see a grammer subpackage. I'm wondering if this is the problem, or perhaps I'm missing something.
Hopefully that is enough info, if not, please let me know what to include.
You're mixing 1.7 and 1.8 versions. Use the following instead:
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j-cypher-dsl</artifactId>
<version>1.8</version>
</dependency>
In 1.7, the Execute class resides in "org.neo4j.cypherdsl" package.
After migrating to Mavent 3.0.3 Parent poms in several Projects cannot be resolved anymore.
The Projects are structured in a default manner, so I set
parent.relativePath to "../pom.xml"
superpom (located in repository)
|-rootpom (located locally: no error)
|-|-parentpom (located locally: error resolving parent)
|-|-|-module1 (located locally: error resolving parent)
|-|-|-module2 (located locally: error resolving parent)
|-|-|-module3 (located locally: error resolving parent)
|-|-|-module4 (located locally: error resolving parent)
The Error...
Non-resolvable parent POM for myGroup:myArtifactId:1.0: Failure to
find myGroup:myParentArtifactId:1.0 in
http://myRepo.net/archiva/repository/maven2 was cached in the local
repository, resollution will not be reattempted until the update
interval of maven2 has elapsed or updates are forced and
'parent.relativePath' points at wrong local POM #
myGroup:myParentArtifactId:1.0, C:\myProjectDir\parent\pom.xml, line
x, column y -> [Help 2]
... seems to indicate that the pom was searched for in the repository, so I wonder why the pom was not found locally before looked elsewhere.
I have read that maven3 might get confused when several repositories are defined in the settings.xml, but that was always when searching for a pom inside repositories and not locally.
update
Up until now we did execute the maven build on the parent-project level (parentpom) - a fact which I did not know was important, since maven2 completed successfully until now.
When using maven3 this seems to be of importance.
When executing maven3 on the root-project level (rootpom) the build finishes successfully.
So my immediate problem is solved.
Since I don't necessarily want to answer my own question maybe
someone can explain why maven3 behaves this way now or why the old
approach was wrong.
Make sure you Double-Check that the version you refer to in the child-pom is the same as that in the parent-pom. For me, I'd bumped version in the parent and had it as 3.1.0.0-RELEASE, but in the child-pom, I was still referring to the previous version via relativePath, and had it defined as 2.0.0.0-SNAPSHOT. It did not make any difference if I included just the parent directory, or had the "pom.xml" appended to the directory:
<parent>
<artifactId>eric-project-parent</artifactId>
<groupId>com.eric.common</groupId>
<!-- Should be 3.1.0.0-RELEASE -->
<version>2.0.0.0-SNAPSHOT</version>
<relativePath>
../../EricParentAsset/projects/eric-project-parent</relativePath>
</parent>
Here is answer to your question.
By default maven looks in ../pom.xml for relativePath. Use empty <relativePath/> tag instead.
'parent.relativePath' points at wrong local POM #
myGroup:myParentArtifactId:1.0, C:\myProjectDir\parent\pom.xml
This indicates that maven did search locally for the parent pom, but found that it was not the correct pom.
Does pom.xml of parentpom correctly define the parent pom as the pom.xml of rootpom?
Does rootpom folder contain pom.xml as well as the paretpom folder?
I had the same problem. My project layout looked like
\---super
\---thirdparty
+---mod1-root
| +---mod1-linux32
| \---mod1-win32
\---mod2-root
+---mod2-linux32
\---mod2-win32
In my case, I had a mistake in my pom.xmls at the modX-root-level. I had copied the mod1-root tree and named it mod2-root. I incorrectly thought I had updated all the pom.xmls appropriately; but in fact, mod2-root/pom.xml had the same group and artifact ids as mod1-root/pom.xml. After correcting mod2-root's pom.xml to have mod2-root specific maven coordinates my issue was resolved.
You need to check your relative path, based on depth of your modules from parent if module is just below parent then in module put relative path as:
../pom.xml
if its 2 level down then
../../pom.xml
Please check in logs if you have http.HttpWagon$__sisu1:Cannot find 'basicAuthScope' this error or warning also, if so you need to use maven 3.2.5 version, which will resolve error.
<parent>
<groupId>com.test.vaquar.khan</groupId>
<artifactId>vk-parent</artifactId>
<version>1.0.0-SNAPSHOT</version>
<relativePath>../projectname/pom.xml</relativePath>
</parent>
Add following line in parent
<relativePath>../projectname/pom.xml</relativePath>
You need relative path if you are building from local parent pom not available in nexsus, add pom in nexus then no need this path
For me, it works when I double checked the parent´s "group ID" and "artifact ID" that in my case were the wrong ones and that was the problem.