Issue #601 : Introduce an optional unit in Number item, now that CQ h…

[clinique]

…as been approved.

Not sure I included the libraries in the right way (I suspect it should be pushed to the target platform definition), but well here it is at last.

Signed-off-by: Gaël L'hopital glhopital@gmail.com

[maggu2810]

Not sure I included the libraries in the right way

We have a CQ for

• unit-api Version: 0.8
• unit-ri Version: 0.8

You are using version 0.9 know.
Have there other CQs created that are not linked in #601?

Can you point me to the CQ for uom-lib-common-0.9?

[maggu2810]

After #1858 and #1859 are applied, you do not need to bundle the JARs (at least the two I seen the CQs for) anymore.

[kaikreuzer]

Applied ;-)

[clinique]

Sorry, but I do not get where are the merge conflicts...

[clinique]

I guess that once this is included, we'll have to impact it's capabilities in channel-type definitions.
If I take the example of (coming from yahooweather) :

<channel-type id="temperature">
    <item-type>Number</item-type>
    <label>Temperature</label>
    <description>Current temperature in degrees celsius</description>
    <category>Temperature</category>
    <state readOnly="true" pattern="%.1f °C">
    </state>
</channel-type>

should evolve to something like :

<channel-type id="temperature">
    <item-type>Quantity</item-type>
    <label>Temperature</label>
    <description>Current temperature</description>
    <category>Temperature</category>
    <state readOnly="true" pattern="%s">
    </state>
</channel-type>

so dimension of the item should be defined by the category and default representation of a Temperature be setup at system level.
I imagine that we then don't mind wether the binding gets the data in °C or °F, the representation will be adapted to end-user preference ?
But maybe it's not the place to discuss impacts of this PR on the whole system...?

[maggu2810]

Sorry, but I do not get where are the merge conflicts...

I assume the file targetplatform/smarthome.target should not be part of your PR.

[clinique]

Ok, removing it.

[maggu2810]

Ok, removing it.

Did not work, it is still part of the PR.

[clinique]

No, seems fine, no ?

[maggu2810]

Yes, seems fine, now. My browser missed perhaps a refresh.

[clinique]

@kaikreuzer : so, are we clear to merge this ?

[kaikreuzer]

Unfortunately not.
I just finished a discussion with the IP team - the unit-ri library isn't approved after a detailed analysis (it contains GPL/JDK code) and thus we will have to remove it from ESH again.

The new plan is now to use https://github.com/unitsofmeasurement/uom-se, which is more or less the same, but builds on Java8 (and thus does not need to include any JDK code as it can use it from the JDK8 itself). For this PR, this should not change much as the API stays the same.
Nonetheless, we have to wait for two things:

1. Have CQ12332 (for uom-se 1.0.2) and CQ12206 (for unit-api 1.0) approved
2. Have ESH moved to Java8 as a minimal requirement

I hope that both will happen within a few weeks from now, rather than months.
Sorry for having to ask for your patience again!

[clinique]

Ok, so when these CQ are approved and Java8 movement validated, I'll review the PR.

[maggu2810]

After the c3 of the resp. CQ the bundle has been added to the third-party p2 repo of ESH:
https://github.com/eclipse/smarthome/blob/gh-pages/third-party/pom.xml#L69

We should remove it now again...

[maggu2810]

... I should read to the end of the thread.

so I will make sure to remove unit-ri 0.8 from the Eclipse SmartHome repository in due time again.

Haven't realized that you already plan to do so.

[kaikreuzer]

Good news, CQ 12332 for unit-se has already been approved for check-in. Now only waiting for unit-api.

[clinique]

...in the starting blocks :)

[kaikreuzer]

Good news - unit-api 1.0 has also been approved for check-in.
I have just updated the smarthome.target to use it, see #2722.
Note that for the moment, the implementation (uom-se) is still missing on the target platform, so while you can compile your code against the API, you cannot test it. I'll look for a way to make uom-se also available.

[kaikreuzer]

FTR: unitsofmeasurement/uom-se#134

[watou]

uom-se claims to be for Java SE 8 and above, but doesn't ESH need to function on Java 7?

[kaikreuzer]

Yes, please see above

[watou]

Ah, thanks.

[kaikreuzer]

FTR: I have created CQ 12518 for uom-lib-common, which is a required dependency of uom-se.

[hakan42]

@kaikreuzer from your experience, do you expect this issue to be resolved in time for OH2 release? Or, would you wait with OH2 "final" for this to land?

[clinique]

My 2 cents is that including this and creation of the QuantityItem is only the begining of a whole bunch of modifications in ESH to take it in account fully. So I would not expect it fully deployed very quick...

[kaikreuzer]

I share @clinique's cents - this is going to be a major new feature, which will probably also require many bindings to be changed in order to support it, so I am not planning it for openHAB 2.0.0 (feature freeze tomorrow!), but rather some 2.x.

[kaikreuzer]

FTR, I have created CQ 12610 for uom-se 1.0.3, which we need for the target platform.

[htreu]

Hi @clinique please see https://github.com/clinique/smarthome/pull/6 for yet another final attempt to get this going ;-) Please review and merge.
I hope merging will be painless since I already rebased it on this PR. Rebasing onto master might be another issue.

again, thank you very much!

[htreu]

Hi @clinique, yet another PR to be merged. See https://github.com/clinique/smarthome/pull/7.
@kaikreuzer and me did schedule a review session for next week so this will hopefully come to an end soon(TM) ;-)

[clinique]

@htreu : you made an amazing work! Thanks a lot for pushing this, it was far beyond my knowledge to do it.

[kaikreuzer]

Superseded by #4818 (as I didn't have push rights to your branch @clinique to resolve the conflicts).