I have a very large scale java project whose structuring is like this:
java->ROOT/A, java->ROOT/B, java->ROOT/C java->ROOT/...
Where A, B ,C are individual java projects. I tried to use sonar ant task in the build.xml of A, B ... but it was giving "org.sonar.squid.api.AnalysisException" error as the packages in A, B are something like package ROOT.A.xyz.
So I was bound to add the sonar ant task target in build.xml file of ROOT.
Now I am specifying the sonar.sources and sonar.binaries to java directory and including the exact project to be build using sonar.inclusions property i.e. A/B/C.
But the problem is though its analysing only files of A/B/C but its searcing from dependencies i.e. jar dependencies etc in entire project (ROOT) and is taking a lot of time. May I know what is the solution I can have were only dependencies of the respective project will be resolved.
Related
I really don't have much experience in developing let alone using build tools.
I was assigned a task to build dependencies locally and get the jar files.
say I have a list of deps (GAV) like this:-
1. org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC
2. com.auth0:java-jwt:3.18.2, etc
3. openapi4j:openapi-operation-validator:1.0.7, etc
So i was able to download the source code url from maven repository and source code from github programmatically, for example :-
org.jetbrains.kotlin:kotlin-stdlib:1.6.0-RC - https://github.com/JetBrains/kotlin
com.auth0:java-jwt:3.18.2 - https://github.com/auth0/java-jwt
openapi4j-openapi-operation-validator-1.0.7 https://github.com/openapi4j/openapi4j
but there are many build.gradle files in different directories, how do I know which directory should I move into before running the gradle build command.
Things I have already tried and failed:-
For deps like this openapi4j:openapi-operation-validator:1.0.7, i can directly go into the openapi-operation-validator folder in the Github repo (https://github.com/openapi4j/openapi4j ) and run the gradle build command, but not all projects are structured like that I guess?
For deps like this com.auth0:java-jwt:3.18.2, the artifactId (java-jwt
) is already present in the github path (https://github.com/auth0/java-jwt), so i can run the gradle build command on the root github repo.
From the spring guides , among all the Gradle.build files available I can check which file has:-
jar {
archiveBaseName = <artifactId>
archiveVersion = <version>
}
, then I can move to that dir and run Gradle build, but not all build.gradle files have this.
None of the above approaches are concrete, is there any other firm approach that I can use to tackle the problem?
Your approach is generally correct.
You need to find the source code in github/gitlab/wherever, read the readme file and try to build it with whatever build tool was used there.
This may or may not work.
I am building a Java project, call it A. A has sources in A/src/main/java. There are other projects B, C, D (more, actually), and they have B/src/main/java, C/src/main/java , D/src/main/java. When I took over this project A, I noticed that the old JBuilder build script for A referenced the sources of B, C and D in parallel directories. I don't like that, because source files in those other directories could change. I want to modify the build, using Gradle, so that versioned sources of the other projects are pulled from a local Maven repo, and, from A's perspective, during compilation I reference the source .zip files of the other projects. Can I do that with Gradle?
I have a largish Maven multiproject build. I'm scanning the codebase with SonarQube (5.6.5). For background, I successfully integrated the various JaCoCo exec files into SonarQube by using the "jacoco:merge" goal, to produce a single exec file. The SonarQube property that alleges to allow specifying a list of JaCoCo exec files doesn't work in our version of SonarQube, but specifying a single one does work.
I'm now trying to integrate the numerous "TEST-*" files in "target/surefire-reports" in each of the subprojects. The "sonar.junit.reportsPath" property expects a single directory, so I can't specify a list of them.
That means I'm going to have to do something as part of the build to merge the entire contents of all of the "target/surefire-reports" directories into a single directory, so I can specify that directory.
I already have a pom that does nothing but merge JaCoCo data. This seems like a logical place to store the surefire reports.
How can I do this sort of thing with Maven? Would this be an application of the "maven-resources-plugin", or something else?
Ok, well, I guess I answered my own question. I was able to get this to work with the resources plugin, specifying every one of my modules as resource directories. I now have one ridiculous-looking POM that has three lists of all of the modules in my multiproject build, for three tasks that require me to list all of the modules to process. The Gradle version would be amazingly short.
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.
Newbie question : I have 2 C# projects in TeamCity, call them A and B. A contains a reference to B.dll. B builds fine. However, A fails to build because it cannot find B : Could not locate the assembly "B"
It seems really simple : how do I tell my project A on the buildserver where to find the binaries from B\bin\Release?
You do this by creating 'Artifacts' and artifact dependencies.
If project A is dependent on project B, then you create an Artifact on project B using an artifact path like so:
bin/Release/B.dll
Then on project A you setup a artifact dependency on B with path like:
B.dll
And set the destination path to be where ever project A is expecting to find B.dll e.g.
./Libs
You can do other cool stuff like automatically archiving all your artifacts into a zip by using the syntax:
bin/Release/*.dll => B.zip
and access them via:
B.zip!B.dll
All these paths are relative to build directories so makes it easy and you dont need to worry about the TeamCity guid folders or use absolute paths.
The problem you're encountering is that Teamcity runs each build in it's own temporary directory and since this is a randomly generated name you can't set a reference directly from one to the other.
Typically you would write a build script that builds both A and B in the right order and just have Teamcity run that build script. (Since you're using C#, MSBuild is ideal for this).
The alternative would be to have B.dll copied to a known location (e.g. c:\currentbuild) at the end of its build and have A always reference it from here. You can set up build dependencies in Teamcity so that if B is rebuilt, A is also rebuilt.