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: Sat, 31 Jan 2015 14:32:53 +0100
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
>
>>
>
>>
>
>>
>
>>
>
>>
>
>
>
>
>