My sonar version is 5.6.4 which throws java.lang.NoSuchMethodError at my code.
org.sonar.plugins.javascript.api.tree.expression.CallExpressionTree.argumentClause()Lorg/sonar/plugins/javascript/api/tree/expression/ArgumentListTree;
public void visitCallExpression(CallExpressionTree tree) {
if (tree.callee() instanceof DotMemberExpressionTree){
DotMemberExpressionTree dmTree = (DotMemberExpressionTree) tree.callee();
System.out.println(tree);
if (isLionGetProperty(dmTree) && tree.argumentClause().arguments().size() < 2) {
addIssue(tree.callee(), MESSAGE);
}
super.visitCallExpression(tree);
}
}
My local plugin works fine which is based on Sonar 6.2. Where can I get some doc regarding an old version of SonarJS
Method argumentClause was added in SonarJS 3.0, you need to have at least this version of SonarJS installed to be able to use it. There is no documentation, you can find information in the source repository or JIRA (e.g. argumentClause was added in this ticket)
Related
I'm using Micronaut 3.1.3 together with Gradle 7.2 to build my project.
After switching to Gradle 7.3, built breaks emitting some context-free error message:
$ ./gradlew clean build
Executed by Gradle 7.3
- using Java 11.0.13
- using Kotlin 1.5.31
- using Groovy 3.0.9
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring root project '[PROJECT]'.
> The value for this property is final and cannot be changed any further.
With --stacktrace a very long trace appears. The following excerpt makes me guess
that the problem might lay in the Micronaut plugin:
* Exception is:
org.gradle.api.ProjectConfigurationException: A problem occurred configuring root project '[PROJECT]'.
at org.gradle.configuration.project.LifecycleProjectEvaluator.wrapException(LifecycleProjectEvaluator.java:75)
at org.gradle.configuration.project.LifecycleProjectEvaluator.addConfigurationFailure(LifecycleProjectEvaluator.java:68)
at org.gradle.configuration.project.LifecycleProjectEvaluator.access$400(LifecycleProjectEvaluator.java:51)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Caused by: java.lang.IllegalStateException: The value for this property is final and cannot be changed any further.
at org.gradle.api.internal.provider.AbstractProperty$FinalizedValue.beforeMutate(AbstractProperty.java:489)
at org.gradle.api.internal.provider.AbstractProperty.assertCanMutate(AbstractProperty.java:263)
at org.gradle.api.internal.provider.AbstractProperty.setSupplier(AbstractProperty.java:212)
at org.gradle.api.internal.provider.DefaultProperty.set(DefaultProperty.java:71)
at org.gradle.api.tasks.testing.Test.useTestFramework(Test.java:979)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1049)
at org.gradle.api.tasks.testing.Test.useJUnitPlatform(Test.java:1032)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$null$1(MicronautLibraryPlugin.java:103)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.api.internal.DefaultDomainObjectCollection.withType(DefaultDomainObjectCollection.java:201)
at io.micronaut.gradle.MicronautLibraryPlugin.lambda$apply$4(MicronautLibraryPlugin.java:101)
at org.gradle.configuration.internal.DefaultUserCodeApplicationContext$CurrentApplication$1.execute(DefaultUserCodeApplicationContext.java:123)
[...]
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
Cause "problem occurred configuring root project" I'm not sure which part of my
build.gradle raises the problem. So following my first guess regarding Micronaut
plugin, here is an excerpt telling you the list of plugins in use and config of this plugin:
plugins {
id('org.jetbrains.kotlin.jvm') version "${kotlinVersion}"
id('groovy')
id('org.jetbrains.kotlin.kapt') version "${kotlinVersion}"
id('com.github.johnrengelman.shadow') version '7.+'
id('io.micronaut.application') version '2.+'
id('org.jetbrains.kotlin.plugin.allopen') version "${kotlinVersion}"
id('com.google.cloud.tools.jib') version '3.+'
id('org.openapi.generator') version '5.+'
id('com.heroku.sdk.heroku-gradle') version '2.+'
}
[...]
micronaut {
runtime('netty')
testRuntime('spock2')
processing {
incremental(true)
annotations('[PACKAGE]')
}
}
Maybe this gives enough information to tackle down the cause of the problem?
If not please let me know.
Regards
I hit the same issue with my Java build and asked for help on gradle slack channel. It found to be a change in Gradle 7.3 behavior.
This issue contains an explanation of the cause and how to fix it.
It helped me to solve the issue with my build: I had options defined in one of the test tasks and then useJUnitPlatform was applied across all test tasks afterwards using this snippet:
tasks.withType(Test).configureEach {
useJUnitPlatform() // <-- this line was breaking the build
}
This broke the build after migrating to Gradle 7.3. Removing options solved the problem for me.
Here's an issue requesting to convert this breaking behavior to a warning in Gradle 7.3 and make it a breaking change in 8.0.
FYI: Upgrade to Gradle 7.3.1 brings back successful builds.
I am attempting to update an EMF/XCore project to newer versions to get around a versioning roadblock. Currently the repository that houses this project must target Gradle 4 and Bndtools 4.3 because of problems when targeting newer versions. I readily admit that a problem here is my lack of understanding of XText, XCore, and otherwise. Now I find myself on a machine without access to Java 8 which has forced an attempt to update the project settings if at all possible.
The last safe targets for this project were XText 2.16.0 and org.xtext.builder version 1.0.21. The examples I have been able to locate match the settings of this project for the most part.
So now, attempting to run in a Gradle 6.3 environment with OpenJDK 13 (if the Java version is the issue that can be changed)...
Notes
Some changes are based on researching solutions to my build problem and some comments are added
${mavenURL} is currently pointing to Maven Central
I added the compile platform() line based on XText's Release notes. It does not seem to help this issue, though
I changed version numbers to match those found in the Maven BOM
I have attempted various combinations of changing the org.xtext.builder version as well as targeting both EMF 2.21 and 2.20
I have tried a lower XText version. 2.17.0 fails with a different issue
build.gradle:
plugins {
id 'org.xtext.builder' version '2.0.8'
id 'java' // Helpful? Doesn't appear so
}
repositories {
maven() {
url "${mavenURL}"
}
}
ext.xtextVersion = "2.21.0"
ext.emfVersion = "2.20.0"
dependencies {
compile platform("org.eclipse.xtext:xtext-dev-bom:${xtextVersion}")
xtextLanguages 'org.eclipse.emf:org.eclipse.emf.codegen.ecore.xtext:1.4.0'
xtextLanguages('org.eclipse.emf:org.eclipse.emf.ecore.xcore:1.12.0') {
exclude group: 'org.antlr', module: 'antlr-runtime'
}
xtextLanguages "org.eclipse.xtext:org.eclipse.xtext.ecore:${xtextVersion}"
xtextLanguages "org.eclipse.xtext:org.eclipse.xtext.xbase.lib:${xtextVersion}"
xtextLanguages 'org.eclipse.emf:org.eclipse.emf.codegen:2.19.0'
xtextLanguages 'org.eclipse.emf:org.eclipse.emf.codegen.ecore:${emfVersion}'
xtextLanguages 'org.eclipse.emf:org.eclipse.emf.mwe2.runtime:2.11.2'
compile "org.eclipse.xtext:org.eclipse.xtext:${xtextVersion}"
compile "org.eclipse.xtext:org.eclipse.xtext.xbase:${xtextVersion}"
compile 'org.eclipse.emf:org.eclipse.emf.ecore.xcore.lib:1.4.0'
}
xtext {
version = "${xtextVersion}"
languages {
ecore {
setup = 'org.eclipse.xtext.ecore.EcoreSupport'
}
codegen {
setup = 'org.eclipse.emf.codegen.ecore.xtext.GenModelSupport'
}
xcore {
setup = 'org.eclipse.emf.ecore.xcore.XcoreStandaloneSetup'
generator.outlet.producesJava = true
// Have also tried generator.javaSourceLevel = '1.8'
}
}
sourceSets {
main {
srcDir 'model'
// Move the generated Xcore output to the src directory
output {
dir(xtext.languages.xcore.generator.outlet, 'src-gen')
}
}
}
}
Multiple tries have ended up resulting in the following error:
> ./gradlew jar
...
> Task :com.example.project:generateXtext FAILED
ERROR:A generic type in this context must refer to a classifier or a type parameter (file:...file.xcore)
...
> Xtext validation failed, see build log for details.
for a multitude of lines. The XCore file looks something like this
#GenModel(
complianceLevel="8.0",
loadInitialization="false",
modelDirectory="com.example.project/src-gen",
bundleManifest="false",
updateClasspath="false",
oSGiCompatible="true",
forceOverwrite="true")
#Ecore(
nsPrefix="query",
nsURI="something"
)
// These lines had to be added to resolve the above annotations no longer working
annotation "http://www.eclipse.org/emf/2002/GenModel" as GenModel
annotation "http://www.eclipse.org/emf/2002/Ecore" as Ecore
interface Node wraps an.external.Node {}
abstract class ENode extends Node
{
op Object getParent() // This line fails due to not referring to object or classifier
{
eContainer
}
}
I have seen this error pop up in bug reports on XText sites (such as https://github.com/eclipse/xtext-maven/issues/71), and they were resolved. But generally the projects reference Github examples such as https://github.com/itemis/itemis-blog/tree/xcore_gradle or https://github.com/ghillairet/xcore-gradle-example which both point to versions of XText and the corresponding builder which were indeed working prior to this upgrade attempt.
The project is an XText project. Relevant portion of the .project file is here:
<buildSpec>
<buildCommand>
<name>bndtools.core.bndbuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.xtext.ui.shared.xtextBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>bndtools.core.bndnature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.xtext.ui.shared.xtextNature</nature>
<nature>org.eclipse.pde.PluginNature</nature>
</natures>
Any help would be appreciated.
I received assistance from the folks working on the XText Gradle plug-in via https://github.com/xtext/xtext-gradle-plugin/issues/171.
The biggest issue is that src-gen cannot exist on the classpath prior to execution of the generateXText task. To assist with this updating the clean task to remove the src-gen folder is recommended. Additionally, the second 3 compile dependencies should be xtextLanguages dependencies.
I'm trying to configure Kotlin net.researchgate.release plugin. I have following setup (kts script):
plugins {
...
id("net.researchgate.release") version "2.8.1"
}
In the same script I'm trying to configure plugin:
release {
svn {
username = "some"
password = System.getenv("SOME")
pinExternals = false
}
}
During build I've got:
Unresolved reference: svn
How would I configure this plugin?
That plugin does not support the Kotlin DSL. The reason is that it uses Groovy meta-programming constructs to configure the nested extensions, and you are not using Groovy.
There are two open issues for this problem: 281 and 288. The former suggests a few different work-arounds, including configuring the SVN adapter like this:
release {
with (propertyMissing("svn") as SvnAdapter.SvnConfig) {
username = "some"
// etc...
}
}
I recently updated to gradle version 5.0-rc-4, and when running ./gradlew assemble (or any other task) I now get the following message:
Deprecated Gradle features were used in this build, making it incompatible with Gradle 6.0.
Use '--warning-mode all' to show the individual deprecation warnings.
When I use ./gradlew assemble --warning-mode all I get:
> Configure project :
The DefaultSourceDirectorySet constructor has been deprecated. This is scheduled to be removed in Gradle 6.0. Please use the ObjectFactory service to create instances of SourceDirectorySet instead.
But in the following build.gradle I don't see where I'm using any DefaultSourceDirectorySet, so what is this warning about, and what would I need to change to be compatible with Gradle 6.0?
plugins {
id 'org.jetbrains.kotlin.jvm' version '1.3.10'
}
dependencies {
compile 'org.jetbrains.kotlin:kotlin-stdlib-jdk8'
}
repositories {
mavenCentral()
mavenLocal()
jcenter()
}
Related
I found create version.txt file in project dir via build.gradle task(gradle 5.0) but I don't have constructs like that so I don't know how it would apply.
I found this deprecation mentioned in the release notes at https://docs.gradle.org/5.0-milestone-1/release-notes.html but they say
In this release of Gradle, the ObjectFactory service, which is part of the public API, now includes a method to create SourceDirectorySet instances. Plugins can now use this method instead of the internal types.
but I don't see how.
I also found the SourceDirectorySet interface at https://docs.gradle.org/current/javadoc/org/gradle/api/file/SourceDirectorySet.html but I don't see how to use it.
Template repository: https://github.com/PHPirates/kotlin-template-project
Update 2019-01-23 Five minutes ago, kotlin 1.3.20 was released and also updated in the Gradle repository so this issue should be solved by updating the Kotlin Gradle plugin to 1.3.20.
Update 2019-01-11 The target version in Youtrack issue KT-26808 has just been updated to 1.3.20. You can view the latest released version in the Gradle repositories here, but at the moment there are still a lot of open issues for 1.3.20.
Update 2018-12-17 The deprecation warning is fixed in commit https://github.com/JetBrains/kotlin/commit/67e82a54e5ee529116e881953f93a4c8f216e33a, the Youtrack issue is closed. Now waiting for a release to roll out.
As #Javaru pointed out, this has already been reported (in september 2018) at Youtrack issue KT-26808.
Using information from Lance's comment in the link that Thomas David Baker pointed to:
Answer:
If you get this warning while you are not using DefaultSourceDirectorySet directly, this is probably coming from a Gradle plugin you use. You could check this using the --warning-mode all --stacktrace flags for the Gradle build, so like ./gradlew assemble --warning-mode all --stacktrace.
In this particular case it's the Kotlin Gradle Plugin, they use it at DefaultKotlinSourceSet.kt#L140-L155:
private val createDefaultSourceDirectorySet: (name: String?, resolver: FileResolver?) -> SourceDirectorySet = run {
val klass = DefaultSourceDirectorySet::class.java
val defaultConstructor = klass.constructorOrNull(String::class.java, FileResolver::class.java)
if (defaultConstructor != null && defaultConstructor.getAnnotation(java.lang.Deprecated::class.java) == null) {
// TODO: drop when gradle < 2.12 are obsolete
{ name, resolver -> defaultConstructor.newInstance(name, resolver) }
} else {
// (code omitted)
}
}
We can trust that they will resolve the issue in time, so don't worry about the warning.
I'm trying to fetch a maven artifact's dependencies using aether. I see a RepositorySystem.collectDependencies(), but that fetches only compile and runtime scoped dependencies. How do I fetch all dependencies for the artifact, including test and provided?
Take a look at jcabi-aether (I'm a developer), which is a wrapper around Sonatype Aether:
File repo = this.session.getLocalRepository().getBasedir();
Collection<Artifact> deps = new Aether(this.getProject(), repo).resolve(
new DefaultArtifact("junit", "junit-dep", "", "jar", "4.10"),
JavaScopes.RUNTIME
);
Assuming you are using DefaultRepositorySystemSession you may do the following:
defaultRepositorySystemSession.setDependencySelector(new DependencySelector() {
#Override
public boolean selectDependency(Dependency dependency) {
return true;
}
#Override
public DependencySelector deriveChildSelector(DependencyCollectionContext context) {
return this;
}
});
and then
CollectResult result = repositorySystem.collectDependencies(defaultRepositorySystemSession, request);
Here is an example project that does this.
These three files:
https://github.com/terraframe/Runway-SDK/tree/v1.8.0/runwaysdk-server/src/main/java/com/runwaysdk/business/generation/maven
Are a working, stand-alone, example using Aether.
It worked for a few months then I all of a sudden had an issue pop up where it would sometimes on Mac JRE throw a DependencyResolutionException on com.sun:tools.jar.
Good luck, if you decide to use it, I'm instead going to use maven-dependency-plugin dependency:build-classpath.
You can utilize DependencyFilter in Eclipses Aether. A complete version for a sample below can be found in this awesome set of Aether snippets.
DependencyFilter classpathFilter = DependencyFilterUtils.classpathFilter(JavaScopes.COMPILE, JavaScopes.PROVIDED);
CollectRequest collectRequest = new CollectRequest();
collectRequest.setRoot( new Dependency( artifact, JavaScopes.COMPILE ) );
collectRequest.setRepositories(repositories);
DependencyRequest dependencyRequest = new DependencyRequest( collectRequest, classpathFilter );
List<ArtifactResult> artifactResults =
system.resolveDependencies( session, dependencyRequest ).getArtifactResults();
UPDATE
Version 0.9.0M3 is not compatible with Maven 3.1.0, so don't use it inside Maven, i.e. in a plugin.
Take a look at this github project: https://github.com/Gemba/mvn-dd
It downloads all dependencies including test and provided.
It uses aether's library to fetch them.