Develop Reference

Web Application Code Coverage using JaCoCo

I have been assigned a task where I want to generate the code coverage report of web application execution (development code) when a manual or automation test script is executed, I have to identify (using any tool) what percent of development code has been executed against that particular action.
After doing my RnD, I found that this can be achieved using JaCoCo (Java Code Coverage). JaCoCo uses class file instrumentation to record execution coverage data. Class files are instrumented on-the-fly using a Java agent. I have used the java command in the java agent flag.
Points to Mention
Application front-end is Angular, backend is Java/BPM and is deployed on JBoss Server.
Backend code contain multiple modules.
Testcase are executed from my local machines, that hits the application deployed on the server.
APPROACH
I have added the below mentioned command in /app/JBoss-EAP-7.2/bin/standalone.sh file because this is the file that is executed when the server starts.
Javaagent:<path_to>/jacocoagent.jar=classdumpdir=<path_to>/jacocoClassDump, destfile=<path_to>/jacocoST.exec
Restart JBoss server. [After this jacocoST.exec file is created in the respective folder]
Run automated testcase using maven on my local machine.
Stop the JBoss server. [so that jacocoST.exec file is updated]
Run the command:
java -jar <path_to>/jacococli.jar report <path_to>/jacoco-it.exec -- classfiles=<path_to>/jacocoClassDump --html /app/Jacocoreport --xml cov.xml
The above steps show error Can't add different class with same name
Why do I get the error "Can't add different class with same name"?
The FAQ that I’ve come across from JaCoCo Official Documentation
For coverage report generation all classes within a group must have unique names. You get this error during report generation if JaCoCo is supplied with multiple different class files with the same name. To fix this remove those duplicate classes or create separate reports or report groups for each version.
The main problem is the error which I am getting. According to FAQ, they suggest to delete duplicate files but there are no duplicate class files (each class files has unique number at the end).If somebody has done such work so please guide me, Are the steps which I followed right?

How to generate Swagger's "api-docs" during build process?

I think this is a trivial use case, but can't find anywhere about it.
Our build should have 2 parts that are related to Swagger:
Run regular swagger and create the JSON (available in \api-docs url) and other Swagger-related items.
Create DTOs from the JSON.
I want to run step 1 as a part of the build process.
Details:
Currently, our project has springfox-boot-starter (3.0.0) that includes Swagger-UI. This allows the api-docs to be available when the server is online (I believe this is created on runtime, and doesn't display an existing JSON file). So I can fetch that JSON from the browser.
I added to Maven's pom.xml file the awesome openapi-codegen (openapi-generator-maven-plugin), and so when I set the plugin to point on the JSON file (created when the server was online) and run mvn clean install it does what I need in step 2: generates DTOs.
However, I can't find anywhere how to do step 1 (create the JSON) during the build process, when the server is offline.
I believe this is very common use case so this is surprising, since generating DTOs is needed on the build process and shouldn't be dependent on a running server.
I know there is a project called Swagger2Markup in GitHub but it is un-maintained.
Thanks!

How to integrate offline JaCoCo exec files from Maven multiproject build into SonarQube

I have a Maven multiproject build. The unit tests are using PowerMock 1.6.6, and I've managed to generate individual Jacoco (0.7.8) exec files for each module using the "offline" process. I also have a single module that uses the "report-aggregate" to generate a single JaCoCo report.
I'm now trying to integrate with SonarQube 5.6.5, using sonar-scanner 2.8.
Using this doc page I naturally constructed a command line setting the "sonar.jacoco.reportPaths" property to a comma-separated list of paths to the "jacoco.exec" file in each child module. This appeared to have no effect. I saw a message in the output saying "INFO: JaCoCoSensor: JaCoCo report not found : <mycurrentdirectory>\target\jacoco.exec".
So, I instead set property "sonar.jacoco.reportPath" to the same comma-separated value. This at least had an effect, but it confused the scanner, as it obviously expected this to be a single location.
I then tried setting that property to just the first of the several "jacoco.exec" files. That at least completed, but with minimal coverage data.
How do I proceed? Am I instead supposed to somehow use the Jacoco "merge" goal to merge all of my jacoco.exec files into a single file, and specify that, or is there a different undocumented property that allows a list of paths to files?

I verified that the advertised "sonar.jacoco.reportPaths" property only works in SonarQube versions 6.2 or newer (the docs have apparently been updated to reflect this).
Therefore, I moved forward with implementing "merge", specifying the filesets for all the modules. It took a while to get the data correct for that fileset list (Maven, like many frameworks, often says nothing when your configuration data represents files or components that don't exist).

Jenkins & Java : How to specify input file location

I have a java project which compares data in two excel files and displays the output. IN my eclipse project i created a folder data and in the code I wrote code read from root/data and it works fine as well. But my manager asked me to move this job to Jenkins. So my question is how do i specify the input folder path in Jenkins , Should it be the same server where Jenkins is installed or Jenkins can read data from another location in another server ?

By default, Jenkins will work on the Job's workspace location, if you provide a path in the job (be it via Parameter or Env. variable etc), it will be relative to that location.
However, you can specify an absolute path for anywhere on the Jenkins Server, which will also work.
If you wish to read data from another server, you will need to make it available to the job's runtime/access level.
One example would be to put this file on IIS or Network Share or other form of sharing, and download it during your chef job into the workspace.
Powershell example for downloading a file from IIS site:
$source = "http://my-web-server-ip/download/mycsvfile.csv"
$destination = "c:\my-jenkins-job-workspace\mycsvfile.csv"
Invoke-WebRequest $source -OutFile $destination
Please consider the above is just a basic implementation of this, and this can be accomplish in a number of ways - which some may be better than others.

Avoiding hardcoding of Property File path specification

I'm having a small problem decoupling the path specification for properties files that my JAVA program uses , from the implementation itself.
The program may be deployed at multiple locations with different directory structures and I don't want the path specification to be hard coded into the Program code.
Here is the situation as it exists now.
I have one folder server/
Inside which there are 2 packages core/ & support/ (both of which have many subpackages underneath)
What I had done earlier was that , wherever the path for a properties file needed to be specified , I just gave a relative path i.e. properties/
In this scenario, the properties file needs to be wherever you're launching the program from. This worked during testing , when i was manually starting the program up using
"java ". and i would put the properties folder wherever I was starting the program from.
But in a real scenario, this program will be autostarted by a script (ksh) which is executed at scheduled intervals by a job.
In this case , giving the relative path doesn't work. I tried putting the properties files in the folder where the scripts are located , but that doesn't work either.
Right now , I am having to manually specify the path for each environment recompile the code and deploy a separate copy for each environment.
Is there any way to remove this coupling and just have one location for the properties file regardless of where it needs to be deployed?

use a System.Properties entry to specify the path, then on command line add it via
java -DmyProp=somepath -cp yourclasspath YourClass
In your app, you can retrieve it with System.getProperty("myProp"), just be sure to add proper testing and handle the Property Not Found scenario.
Another practice is to leave props in a jar and then load 'em with the LoadResource, in this way you just need to deploy different config jars in each deployment, but I think that the System.setProperty way is the fastest.

Generally some clients may not prefer to use -D= while starting your application. In fact you should also provide a .sh/.bat script file along with your jar file so that client can just double click on the script to run your application.
In this script you can have variable declared which you can ask the client to be configure accordingly. Client can just open the script file in text editor and type in the path of the configuration file.
Other way to use this script file would be to do following :
1) Check if YOUR_APP_NAME_CONFIG variable is set in system environment. If yes then go to step 3 or got to step 2
2) Ask the user on command line for the location of configuration file. Check if the location is correct. If correct then set the environment variable YOUR_APP_NAME_CONFIG with value of location of configuration file.
3)Start your application
Having a script file for your application gives you lots of liberty to do many stuff around automating the environment configuration for your application.
In your application get the config file path by System.getProperty("YOUR_APP_NAME_CONFIG").
This all may look like lot of pain but think from client perspective. Its cake walk for client that he just double click a script to start your application and for the first launch of application the script asks for some inputs if needed and then your application is good to go :)

What I did was pass another classpath parameter with the jar invocation..
java -cp classpath1;folder-where-propertiesfile-located Application.jar
and in the application use getClass().getClassLoader().getResourcesAsStream("properties-file");
This will automatically fetch the properties file form the appropriate classpath folder..
With this setup, I could change the properties file inside the folder and use the same jar file without re-archiving the jar..