unitsofmeasurement / unit-tck Goto Github PK
View Code? Open in Web Editor NEWJSR 385 - Technology Compatibility Kit (TCK)
License: Other
JSR 385 - Technology Compatibility Kit (TCK)
License: Other
Include information about the JDK that's used to run the TCK, as the Java versions change massively and it is also interesting to know, which OpenJDK distribution was used where the information is available.
Add signature tests for new methods added by unitsofmeasurement/unit-api#191
See #43 (comment)
As an API level method like compound()
or mix()
was disregarded by unitsofmeasurement/unit-api#190 the TCK shall be reviewed and adjusted where necessary.
If a UnitFormat
implementation extends java.text.Format
(which historically many formatters do, also in JSR 275) a method with the same name but different signature in the superclass gets picked up first causing 1 test to fail, see https://groups.google.com/forum/?hl=en#!topic/units-dev/8wk2a7dctUo
A future version of the TCK may also include SigTest or any other suitable tool from the JDK.
The QuantityTypesTest
class has some JavaDoc that seems copied from another class. It should be changed to what each method does.
Allowing to configure the TCK test suite via ServiceConfiguration
in a module-info
instead of META-INF:
module com.service.provider {
requires tech.units.tck;
provides tech.units.tck.util.ServiceConfiguration with com.service.provider.MyServiceConfig;
}
Also create GH-Pages for the TCK project similar to RI or API.
Update dependencies like lib and RI to the latest version. Also update parent POM to the latest version before releasing 1.0.1
Based on unitsofmeasurement/unit-api#184 TCK tests for Unit should be adjusted to the renamed method.
The FundamentalTypesTest already checks for prefixes,
The test description
Ensure at least one Prefix implementation is available/registered.
Should be refined, because the API already contains the two most common Prefix
implementations.
In addition to rephrasing it as "at least two" we may consider a type-check that MetricPrefix
and BinaryPrefix
are always part of that list.
In the ServicesTest
for SystemOfUnitsService
the method returning a Set
of Prefix
may also check, that MetricPrefix
and BinaryPrefix
are always part of the Set
. And the minimum size is 2.
The new version of the specification got a few chapters reordered or elements like Prefix
introduced to existing ones. This affects the numbering of test cases which must be addressed in the TCK.
Reduce the errors and warnings for JavaDoc generation.
JUnit 5 offers many new features, inspired by TestNG or otherwise. Could the JSR 385 TCK benefit from some of them?
Add a TCK test for the recently added getUnit(String string)
method in SystemOfUnits
.
A new test case for QuantityFormat
is needed similar to those for UnitFormat
.
Upgrade TestNG to Version 7
In https://github.com/unitsofmeasurement/uom-tools Airline is used for the CLI. Could we also use that or even JShell? (would require Java 9 as minimum version to run the TCK)
CI_DEPLOY_PASSWORD
for Sonatype/OSSHThere could be some minor refinements in test documentation, e.g.
"Test method: 4.2.1.2.1 Ensure the divide() operation is implemented."
might say
"Test method: 4.2.1.2.1 Ensure the divide(Unit) operation is implemented."
instead, to align with other method tests.
Executing mvn dependency:tree
on the TCK gives the following output:
tech.units:unit-tck:bundle:2.1.2-SNAPSHOT
+- javax.measure:unit-api:jar:2.1.2:compile
+- tech.units:indriya:jar:2.1.2:compile
| +- tech.uom.lib:uom-lib-common:jar:2.1:compile
(…snip…)
This is an issue when we want to test any implementation other than Indriya, because the ServiceLoader
used by the TCK can randomly pickup Indriya instead of the implementation that we want to test. It has happened to me today when trying to run Seshat tests. I got confusing test failures until I understood that tests specifically designed for Seshat were running with Indriya implementation.
As a workaround, importing the TCK in a project as below seems to work:
<dependency>
<groupId>tech.units</groupId>
<artifactId>unit-tck</artifactId>
<version>2.1.1</version>
<scope>test</scope>
<exclusions>
<exclusion> <!-- Avoid possible interference with the implementation under test -->
<groupId>tech.units</groupId>
<artifactId>indriya</artifactId>
</exclusion>
<exclusion> <!-- MutabilityDetector uses an older version than the one inherited from JUnit. -->
<groupId>org.hamcrest</groupId>
<artifactId>hamcrest-core</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>tech.uom.lib</groupId>
<artifactId>uom-lib-common</artifactId> <!-- Was a transitive dependency of excluded Indriya. -->
<version>2.1</version>
<scope>test</scope>
</dependency>
But if excluding Indriya does not prevent the tests to work, why the TCK depends on Indriya? If this is used for testing the tests, then could the Indriya dependency be declared with <scope>test</scope>
in the TCK project? It would make much simpler to import the TCK in another project.
As the groups property of the @test annotation expects a String array and does not work with enum values, it is best to give up the Group enum and use those string constants directly.
The Profile enum shall remain because it is used in a different place.
While it should be possible to override ServiceConfiguration.getPrefixClasses
, a vast majority of implementations may be happy with the two built-in prefixes of the API, therefore ServiceConfiguration
should get a default
method,
Add tests for the isEquivalentTo()
method in Unit
and Quantity
.
Release 2.1.1 after changes from #40
The following issue occurs while building:
System
This is a prerequisite for #20 .
While the current approach in the POM to JPMS works, the module-info
is placed in the (Java 8 backward compatible) default module. This confuses the compiler and breaks the build if the TCK is run with Java 8:
[INFO] �[1m------------------------------------------------------------------------�[m
[INFO] �[1;31mBUILD FAILURE�[m
[INFO] �[1m------------------------------------------------------------------------�[m
[INFO] Total time: 2.735 s
[INFO] Finished at: 2023-10-04T23:46:15+02:00
[INFO] �[1m------------------------------------------------------------------------�[m
[ERROR] Failed to execute goal �[32morg.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile�[m �[1m(default-compile)�[m on project �[36munit-tck-usage-java8�[m: �[1;31mFatal error compiling�[m: invalid flag: --release -> �[1m[Help 1]
If Java 9 or above are used, it works fine.
For API or Indriya RI, the module-info
is located in META-INF/versions/9
and higher, so the default JDK won't pick them up if it is Java 8. This should be possible with the AntRun plugin, as that is easier than the ToolChain plugin used by the RI.
MR2 could be the last version to still support Java 8, but with the new SI prefixes and Java 8 still around till at least 2030, the current MR still supports it as the minimal Java version.
The ServiceConfiguration
can be customized by a TCK test suite using the standard Java Service Loader mechanism, but it is not so well documented as are command line arguments, etc.
Update from the old Injection JSR to Jakarta Inject, 1.0 or better 2.0
jakarta.inject jakarta.inject-api 2.0.0JBoss Test Audit released https://github.com/jboss/jboss-test-audit/releases/tag/1.1.4.Final about a year ago. The TCK should be upgraded to use the latest final version.
The issueManagement
tag of the POM still points at java.net JIRA. As this system will be shut down by April 29, 2017 point to this GitHub issue tracker instead.
Building the TCK when JavaDoc is generated there are several warnings or errors. None break the build but adding necessary tags or information as well as changing some links or tags this can be improved and the number of warnings or errors reduced to a minimum.
Right now the system properties start with tec.units.tck
. They should be refactored to tech.units.tck
like the package or GroupId names.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.