When I build my project by tycho-maven-plugin, I encounter the following message:
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: foo-updatesite raw:0.2.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.2.0-SNAPSHOT
[ERROR] Missing requirement for filter properties ~= $0: foo-feature.feature.group 0.2.0.qualifier requires 'foo-plugin 0.0.0' but it could not be found
[ERROR] Cannot satisfy dependency: foo-updatesite raw:0.2.0.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):0.2.0-SNAPSHOT depends on: foo-feature.feature.group [0.2.0,0.2.1)
This error occurs when building an update site. Plugin and feature are build normally. I build the update site from PDE without issues.
The project structure is common: there is a parent project with pom packaging and three modules: plugin, feature and updatesite. Of course, I invoke mvn clean package from the parent project.
What can be the reason for this error? How can I debug it?
UPD: I tried many things: removed "grandparent" pom, removed SNAPSHOT/qualifier, played with configuration. However, I found the solution: I switched to tycho 0.19 instead of 0.21. So I suppose there is a bug in tycho 0.21.
The error message
Missing requirement for filter properties ~= $0
indicates that you have defined an environment filter when you include the plugin foo-plugin in the feature.xml. However this does not explain the dependency resolution error you are seeing. The only way I can reproduce the error message is by adding an Eclipse-PlatformFilter header in the manifest of the plugin using a value which doesn't match environments configuration in the POM.
I had the same error message:
Missing requirement for filter properties ~= $0: foo-feature.feature.group 0.2.0.qualifier requires 'foo-plugin 0.0.0' but it could not be found
For some reason this error (also) means, that foo-plugin is present... twice.
So in your case, open the "Content" tab of the "Target Editor" and make sure that foo-plugin is not present in two distinct versions. I common way this could happen is if two features contain the same bundle.
Related
The following error occurs when gradle builds
Duplicate class androidx.lifecycle.ViewModelLazy found in modules lifecycle-viewmodel-2.5.1-runtime (androidx.lifecycle:lifecycle-viewmodel:2.5.1) and lifecycle-viewmodel-ktx-2.3.1-runtime (androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1)
Duplicate class androidx.lifecycle.ViewTreeViewModelKt found in modules lifecycle-viewmodel-2.5.1-runtime (androidx.lifecycle:lifecycle-viewmodel:2.5.1) and lifecycle-viewmodel-ktx-2.3.1-runtime (androidx.lifecycle:lifecycle-viewmodel-ktx:2.3.1)
Go to the documentation to learn how to Fix dependency resolution errors.
So I found the following documentation:
link
But I can't find AppName > Tasks > android. I noticed the following tip:
So I opened the settings and unchecked the Do not build Gradle task list during Gradle sync
but this still doesn't work.
I already know the answer to this question, when you run the gradle command once, the interface will appear.
gradle app:dependencies
I have created performance test as a maven submodule to my main module. All the test classes are written under src/main/java and not src/test/java
I am able to package the project as jar and run it to performance test my project.
I wanted to execute mvn test. For mvn test to work I should have <testSourceDirectory> value set. As in this case I have my code in src/main/java I set this to :
<testSourceDirectory>src/main/java</testSourceDirectory>
Now mvn test works.
But the Problem is sonar build fails with error complaining: can't be indexed twice. Which is obvious as for my pom testSourceDirectory and sourceDirectory are same.
[ERROR] Failed to execute goal
org.codehaus.mojo:sonar-maven-plugin:2.5:sonar (default-cli)
on project Blah: File [relative=XYZ.java, abs=/Path/XYZ.java] can't be indexed twice.
Please check that inclusion/exclusion patterns produce
disjoint sets for main and test files ->
How to fix this issue?
I was facing the same problem. Finally, solved it with help of below documentation:-
https://github.com/SonarOpenCommunity/sonar-cxx/wiki/FAQ
Q: ERROR: Caused by: File [...] can't be indexed twice.
A: In case of below error you have to verify your exclusion/inclusion
properties. Please check that inclusion/exclusion patterns produce
disjoint sets for source and test files
ERROR: Caused by: File [...] can't be indexed twice. Please check that
inclusion/exclusion patterns produce disjoint sets for main and test
files An example could look like this:
sonar.sources=.
sonar.tests=.
sonar.test.inclusions=**/*Test*/**
sonar.exclusions=**/*Test*/**
This is not a standard Maven usage but you can easily fix SonarQube analysis using exclusions.
sonar.exclusions=src/main/java/**
or
sonar.test.exclusions=src/main/java/**
depending on whether you want your source files to be considered as tests or main files.
But the proper Maven way would be to put your tests in src/test/java and ackage your tests:
https://maven.apache.org/guides/mini/guide-attached-tests.html
If project does not follow default Maven directory structure then in project's pom you can explicitly specify where is located the part of source code and the part of tests:
<properties>
<sonar.sources>src/main/foo</sonar.sources>
<sonar.tests>src/test/bar</sonar.tests>
</properties>
I was seeing this can't be indexed twice error when running sonarqube Gradle task on an Android project. The issue related to files stored in app/src/debug/assets.
I tried setting sonar.sources and sonar.tests properties to use disjointed sets but I wasn’t able to resolve the error.
To fix the error I changed:
property "sonar.coverage.exclusions", "**/assets/**, ..."
to:
property "sonar.exclusions", "**/assets/**, ..."
in order to ignore the /assets/ directory completely.
In my project's POM, I use maven-resources-plugin to set some properties from a file. However, Intellij flags these property references in the POM with the error "cannot resolve symbol", presumably because it cannot see them being defined anywhere. Is there a way to suppress this error?
Warning: The solution to define the property blank as vikingsteve mentioned is very dangerous because in Maven 3 properties which are declared in pom.xml could not be changed by other plugins.
So if you have one plugin which sets a property and another plugin which reads the value of the property it will always get an empty string if you initialize it in the pom.xml.
In fact you can't define it in the pom.xml but i have no idea what i can do to eliminate the IntelliJ IDEA warning. For now i have to disable the "Maven model inspection". :-(
The best way I see to solve the issue is to use the following comment:
<!-- suppress UnresolvedMavenProperty -->
Empty properties are not overwritten or may be a risky operation as #Josef mentioned.
Yes, you can open Settings (spanner icon), go to Project Settings -> Inspections and then disable the inspection Maven -> Maven Model Inspection.
Alternatively, you might like to try defining "blank" values for the properties, and see if the plugin successfully overwrites them.
<properties>
<myproperty></myproperty>
</properties>
Good luck!
Error “cannot resolve symbol” can occur if you open a directory maven project, but intellij project has not yet been created. Why does the "Maven model inspection" there is such a relationship - is not clear, but it helped me.
I am trying to build a p2 repository using Tycho and the tycho-p2-repository-plugin in an eclipse-repository packaging type. When I run the build, it is giving me the following exception:
Failed to execute goal org.eclipse.tycho:tycho-p2-repository-plugin:0.13.0:assemble-repository (default-assemble-repository) on project com.mycompany: No content specified for p2 repository
Can someone point me to the cause of this problem?
You need either of the following files in the root of the eclipse-repository project:
A category.xml files with at least one feature referenced in it
A *.product file
These files define what should be included in the p2 repository, so if there is none of these, the p2 repository would be empty. This is probably not what you wanted, so Tycho fails the build. (Admittedly, the error message could be more helpful...)
I had this problem too, unfortunately it was one of many problems and I do not remember which thing I did to fix it.
Make sure you are using 0.14.1 of tycho.
My working version is a very empty pom.xml, much like Packaging Types
I have not needed to configure the eclipse-repository via tycho-p2-repository-plugin.
Do you have a valid target definition defined in your reactor build somewhere?
Is your *.product file valid? The product file needs to be in the same directory as your eclipse-repository pom, I think it gets found via black magic.
Also make sure your product feature is separate from your eclipse-repository.
under PDE builds you could have the *.product file and the with the feature that is the root for your product.
In fact this is not a question because I've already found the solution but I've strugguled so long with it that I'd rather share this one with you than let it die in the depth of my mind
This problem occured to me on an existing project that was using maven assembly 2.2 for some time
The whole exception message was :
Failed to execute goal
org.apache.maven.plugins:maven-assembly-plugin:2.2:assembly
(default-cli) on project
test: Failed to create
assembly: Error creating assembly
archive jar-with-dependencies: Problem
creating jar: no entry name specified
There was no more message even with a mvn -X
At the beginnig I thought it was due to a bad url like :
jar:file://MY_FILE.jar!
But all this was caused by an hidden file named ".#log4j.xml..." which was automatically created by CVS during a conflict resolution
==> solution is resolve the conflict and remove the file
I've filed a bug report on this : PLXCOMP-169
As I said this is not a bug and will need an improvment from the plexus team.
Until then you will need to find by yourselves ".#" files in your project AND dependencies (this one was in a project of mine which was a dependency to the project beeing assembled).
Thanks to Jon to point me out the fact that an accepted answer would be more intuitive.