Skip to main content

[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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>


[jsr363-experts] Re: EDR done, next steps

Werner Keil 02/05/2015

[jsr363-experts] Re: EDR done, next steps

Martin Desruisseaux 02/08/2015

[jsr363-experts] Re: EDR done, next steps

Werner Keil 02/08/2015
 
 
Close
loading
Please Confirm
Close