Use Advanced Search to search the entire archive.
[jsr363-experts] Re: EDR done, next steps
- From: Werner Keil <
>
- To: "
" <
>
- Subject: [jsr363-experts] Re: EDR done, next steps
- Date: Thu, 5 Feb 2015 12:56:32 +0100
The JSR 349 TCK contains some good examples on how to use these JBoss
annotations:
https://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_single/
Anybody up to helping with the TCK yet?;-)
Regards,
Werner
On Sat, Jan 31, 2015 at 2:32 PM, Werner Keil
<
>
wrote:
>
Actually the best place for such requirements or a "test plan" is a file
>
like https://github.com/JavaMoney/jsr354-tck/blob/master/test-audit.xml
>
We got a smaller one here
>
https://github.com/unitsofmeasurement/unit-tck/blob/master/test-audit.xml
>
While the Spec only has sections or headers on the 1st level, everything
>
else needs to be retrieved and looked up by the number of sub-headers, this
>
file allows us to gather actual tests. And then refer to them in the actual
>
test. Please feel free to populate the file. It should in most cases match
>
a similar or identical chapter of the Spec.
>
>
Thanks,
>
Werner
>
>
On Fri, Jan 30, 2015 at 9:08 PM, Werner Keil
>
<
>
>
wrote:
>
>
> P.s.: Google Docs unfortunately doesn't seem to offer default numbering
>
> of headers, but converting to OpenOffice or Word lets you check the number
>
> and depth of headlines underneath the top level. Should we some day migrate
>
> to Asciidoc or something similar, there some more levels can be numbered.
>
>
>
> On Fri, Jan 30, 2015 at 9:05 PM, Werner Keil
>
> <
>
>
> wrote:
>
>
>
>> As seen by JSR 354 (the @SpecAssertion annotations by JBoss help
>
>> further clarify that, but tests would also be OK without them) every
>
>> requirement should be in the Spec;-)
>
>>
>
>> So one of our Spec paragraphs like 5.4 Supported quantities
>
>> we'd check the SI system, if all quantity types from that list are
>
>> returned by the getUnits() collection.
>
>> Of course such test would need to apply only to a profile containinng
>
>> both "quantity" and "spi", so we also neeed to categorize tests
>
>> appropriately and define some profile (likely by using Maven profiles)
>
>>
>
>> Similar to the most basic tests in JavaMoney TCK a "core" test against
>
>> 5.2 The Unit Interface could be if at least one implementation of Unit
>
>> exists.
>
>> Actually some basic structures like the ServiceConfiguration interface
>
>> already exist in the TCK with methods like getQuantityClasses() or
>
>> getUnitClasses().
>
>>
>
>> The "core" tests simply check that Quantity and Unit are "at leasts
>
>> once" implemented, while extended tests against "quantity" or SPI check in
>
>> more detail against the supported quantities. The discussion I had with
>
>> Mark Reinhold at the recent F2F clarified that an implementation making
>
>> full use of "quantity" should expose all these quantities. Whether ornot
>
>> we
>
>> may further diversify the TCK, we may see, but the package must always
>
>> contain all interfaces, the idea of "stripping" was abandoned by Oracle.
>
>> And we would not want to create a separate package for each quantity now
>
>> to
>
>> allow "mix & match", that would be an overkill;-D
>
>> Whether we reduced the number of quantities, especially now that UCUM
>
>> is no longer in the RI, that's probably a good follow-up JIRA task and
>
>> discussion item.
>
>>
>
>> Regards,
>
>> Werner
>
>>
>
>> On Fri, Jan 30, 2015 at 8:13 PM, Legrand, Karen
>
>> <
>
>
>> wrote:
>
>>
>
>>> Maybe we should start by putting together a list of requirements that
>
>>> need to be tested. After reviewing the coverage, we could parcel those
>
>>> out
>
>>> for implementation.
>
>>>
>
>>>
>
>>>
>
>>> *From:* Werner Keil
>
>>> [mailto:
]
>
>>> *Sent:* Thursday, January 29, 2015 11:45 AM
>
>>> *To:*
>
>>>
>
>>> *Subject:* [jsr363-experts] EDR done, next steps
>
>>>
>
>>>
>
>>>
>
>>> Dear Experts,
>
>>>
>
>>>
>
>>>
>
>>> As you may know, EDR finished yesterday. Thanks everybody who helped
>
>>> with any relevant part at this stage. Therefore the ticket for EDR
>
>>> https://java.net/jira/browse/UNITSOFMEASUREMENT-82 is now closed.
>
>>>
>
>>>
>
>>>
>
>>> Except the somewhat inconsistent (though correct against the Spec, so
>
>>> having no symbol or name for derived units is perfectly fine from the
>
>>> point
>
>>> of the Unit interface or Spec;-) behavior between units defined by RI
>
>>> elements (mostly unit systems) and pure parsing/marshaling of the same
>
>>> defined by UCUM.
>
>>>
>
>>>
>
>>>
>
>>> Removing UCUM from the RI and focusing on other definitions like those
>
>>> in the Unicode CLDR (most likely with just a "default" language for ME,
>
>>> could leverage Unicode's power and 70+ languages in SE, but for small
>
>>> devices that seems an overkill) seems like a good idea. Not that UCUM is
>
>>> bad, but it is bound to a large XML file while even the native
>
>>> unprocessed
>
>>> CLDR data comes as JSON, which has some support by ME 8, too and for
>
>>> actual
>
>>> usage we should bring it into a suitable format for the RI (either a
>
>>> class,
>
>>> properties or similar)
>
>>>
>
>>>
>
>>>
>
>>> Since even those in the EC who may not review all JSRs in greater
>
>>> detail heard our presentation and saw the material, it is reasonable to
>
>>> believe, had any of them felt uneasy about a particular aspect, they
>
>>> would
>
>>> have said so either during the F2F or via mailing lists.
>
>>>
>
>>>
>
>>>
>
>>> Since there were no significant issues raised other than the UCUM one
>
>>> (and a few bugs all fixed by now) we don't seem to benefit much from an
>
>>> Early Draft 2. One of the most important pieces to work on is the TCK,
>
>>> see
>
>>> https://java.net/jira/browse/UNITSOFMEASUREMENT-101 and its sub-tasks.
>
>>>
>
>>>
>
>>>
>
>>> I encourage especially those who provided a lot of input into the spec
>
>>> and API/RI before Early Draft to help with the TCK. It is proof of
>
>>> relevant
>
>>> statements and definitions in the Spec regarding implementations. Take a
>
>>> small example from JSR 354 in
>
>>>
>
>>>
>
>>> https://github.com/JavaMoney/jsr354-tck/blob/master/src/main/java/org/javamoney/tck/tests/ModellingCurrenciesTest.java
>
>>>
>
>>>
>
>>>
>
>>> /**
>
>>> * Ensure at least one javax.money.CurrencyUnit implementation
>
>>> * is available and registered/accessible from MonetaryCurrencies.
>
>>> */
>
>>> @SpecAssertion(section = "4.2.1", id = "421-A1")
>
>>> @Test(description = "4.2.1 Ensure TCK has CurrencyUnit classes
>
>>> configured.")
>
>>> public void testEnsureCurrencyUnit(){
>
>>> AssertJUnit.assertTrue("TCK Configuration not available.",
>
>>> TCKTestSetup.getTestConfiguration() != null);
>
>>>
>
>>> AssertJUnit.assertTrue(TCKTestSetup.getTestConfiguration().getCurrencyClasses().size()
>
>>> > 0);
>
>>> }
>
>>>
>
>>> Based on
>
>>> https://github.com/JavaMoney/jsr354-api/blob/master/src/main/asciidoc/JavaMoneySpecification.adoc#CoreAPI
>
>>> in the Spec.
>
>>>
>
>>>
>
>>>
>
>>> Essentially it checks there is at least one implementation of a
>
>>> CurrencyUnit.
>
>>>
>
>>>
>
>>>
>
>>> We'd have similar assertions, e.g. that a SystemOfUnit implementation
>
>>> must be present and either that or comparable implementation classes like
>
>>> Quantities return at least one Quantity implementation, etc.
>
>>>
>
>>>
>
>>>
>
>>> Where actual standards like SI/BIPM, ISO or at least CLDR specify which
>
>>> particular units make a proper unit system, such assessments would also
>
>>> make sense regarding the size / completeness of certain unit collections.
>
>>>
>
>>>
>
>>>
>
>>> Based on my Eclipse CQ the Eclipse SmartHome project also just filed
>
>>> their intent to use the JSR from Orbit. That's good support. Probably
>
>>> others follow (at least UOMo;-) and there are some interesting
>
>>> Embedded/IoT
>
>>> projects ike Kura or COAP there, too. Kura even explored Oracle's Device
>
>>> I/O on Java SE Embedded.
>
>>>
>
>>>
>
>>>
>
>>> Should e.g. the UOM-SE port suffer lack of interest or resources, then
>
>>> of course some de-scoping of e.g. the UCUM parts may occur there, too. It
>
>>> is not a core part of the JSR, so it does not affect our mandatory
>
>>> output.
>
>>> Of course it would be nice as we also stated to have one or the other
>
>>> implementation that can be verified by the TCK, too;-)
>
>>>
>
>>>
>
>>>
>
>>> Regards,
>
>>>
>
>>>
>
>>> Werner
>
>>>
>
>>>
>
>>>
>
>>>
>
>>>
>
>>
>
>>
>
>
>