Restore Java 8 compatibility

[bestbeforetoday]

Build with source and target bytecode compatibility for Java 8. This allows chaincode implementation code that requires Java 8 compatibility to compile against the fabric-chaincode-shim package.

Avoid use of mavenLocal() and (deprecated) jcenter() Gradle repositories.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.3% Duplication on New Code

See analysis details on SonarCloud

[MuthuSundaravadivel]

Here the fabric-chaincode-shim:2.5.2 version needs to be changed fabric-chaincode-shim:2.5.3. Line No:24. I will create the separate PR that way i can understand process

[MuthuSundaravadivel]

Here the fabric-chaincode-shim:2.5.2 version needs to be changed fabric-chaincode-shim:2.5.3 Line No 17. I will create the separate PR that way i can understand process

[MuthuSundaravadivel]

In examples we need to change the version from 2.5.2 to 2.5.3. I will create the separate PR that way i can understand process. Apart from this i have couple of question can you guys help me to clarify my question.

1. Does the vulnerability scan action check every dependency that the Java SDK uses?

2. The ubuntu-latest job is executed whenever a PR is merged, its handling the build, jar, and image pushes to the registry. How will the tagging take place? Do I need to run git tag in order to release a new image tag?

3. Every PR merge will update the existing image and its taking existing image tag using this job Docker meta in release.yml. Is my understaning correct ?

4. What scenario is the task Scheduled buildin schedule.yml being used in? is use a cron job to start the build process. is there any specific reason ? In case if we have't made any changes also this job gets triggered is my understanding correct ?

5. Our current release 2.5.2 but Java Doc(https://hyperledger.github.io/fabric-chaincode-java/) and API (https://hyperledger.github.io/fabric-chaincode-java/release-2.2/api/)pointing to 2.2.4 . is there seprate process to update ?

@denyeart @bestbeforetoday

[MuthuSundaravadivel]

Here the fabric-chaincode-shim:2.5.2 version needs to be changed fabric-chaincode-shim:2.5.3. Line No:24. I will create the separate PR that way i can understand process

[MuthuSundaravadivel]

Here the fabric-chaincode-shim:2.5.2 version needs to be changed fabric-chaincode-shim:2.5.3. Line No:24. I will create tghe separate PR that way i can understand process

[bestbeforetoday]

In examples we need to change the version from 2.5.2 to 2.5.3. I will create the separate PR that way i can understand process. Apart from this i have couple of question can you guys help me to clarify my question.

There is currently no v2.5.3 release. I deliberately left the examples pointing to the current (latest) v2.5.2 release so they can be used as working examples. Once a v2.5.3 release is created, the examples can be updated to point to that release, and all the other version references can be moved on to v2.5.4 to be used in snapshot builds and in preparation for the next release.

[benjsmi]

What scenario is the task Scheduled buildin schedule.yml being used in? is use a cron job to start the build process. is there any specific reason ? In case if we have't made any changes also this job gets triggered is my understanding correct ?

Your understanding is correct -- the build will run periodically with no action on our part

So just because we don't make changes doesn't mean nothing changes around us. Dependencies can move, scans can/could find new vulnerabilities, etc.

Running a build at some regular, hands-off interval is generally considered good CI/CD practice.

[MuthuSundaravadivel]

Changes looks good. Hence i am approving this PR