Bug 1429803 - Review Request: unitsofmeasurement - Java APIs and services for handling units and quantities (JSR 363)
Summary: Review Request: unitsofmeasurement - Java APIs and services for handling unit...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1429804
TreeView+ depends on / blocked
 
Reported: 2017-03-07 06:07 UTC by Nathan Scott
Modified: 2017-03-24 19:11 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-03-22 10:05:29 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Nathan Scott 2017-03-07 06:07:36 UTC
Spec URL:
https://bintray.com/pcp/f25/unitsofmeasurement/latest#files

SRPM URL:
https://bintray.com/pcp/f25/unitsofmeasurement/latest#files

Description:
The "unitsofmeasurement" modules provide Java APIs and services for handling units and quantities.  These were formalized mid-late 2016 as JSR 363.  The upstream sources are at https://github.com/unitsofmeasurement

There are 6 core maven modules making up this package, all closely related although released in separate tarballs - so for simplicities sake I've opened a single review request.  All packages have been freshly released and built under Fedora 25 with no rpmlint warnings/errors.

There are 6 modules in total (spec, srpm, and binary rpms for each as above):
unitsofmeasurement-unit-api
unitsofmeasurement-uom-parent
unitsofmeasurement-uom-lib
unitsofmeasurement-uom-se
unitsofmeasurement-si-units
unitsofmeasurement-uom-systems

Fedora Account System Username: nathans, brolley, lberk

Comment 1 gil cattaneo 2017-03-11 04:02:45 UTC
unitsofmeasurement-unit-api package is already available in our repositories
https://admin.fedoraproject.org/pkgdb/package/rpms/unit-api
Please, simplifies the name of the packages without "unitsofmeasurement-" and
OPEN for each of your packages a new bug

Comment 2 Nathan Scott 2017-03-11 18:27:51 UTC
Hi Gil,

Oh we were literally working on this in parallel.  Wonderful news that unit-api exists - it sadly didn't when I started :( - and upstream are unaware of your efforts.  Sure, I will split this into multiple (closely related) package requests.  I'm traveling all this week with very little spare time, so will need to get back to you in a little while there.

I switched to using the upstream unitsofmeasurement project prefix because some of the package names are extremely cryptic otherwise (like "uom-se") - *shrug* - is this a concern you share, or think its OK with the short names?

Comment 3 gil cattaneo 2017-03-11 19:17:23 UTC
(In reply to Nathan Scott from comment #2)
> Hi Gil,
> 
> Oh we were literally working on this in parallel.  Wonderful news that
> unit-api exists - it sadly didn't when I started :( - and upstream are
> unaware of your efforts.

Is really necessary for upstream? I do not see a valid reason for boring ... those "people"
You should most WARNING rate to avoid to duplicate libraries
e.g. repoquery -f 'mvn(javax.measure:unit-api)'
or using http://java-deptools.fedorainfracloud.org/?qtype=classes&collection=f27&q=javax.measure

> Sure, I will split this into multiple (closely
> related) package requests.  I'm traveling all this week with very little
> spare time, so will need to get back to you in a little while there.

> I switched to using the upstream unitsofmeasurement project prefix because
> some of the package names are extremely cryptic otherwise (like "uom-se") -
> *shrug* - is this a concern you share, or think its OK with the short names?

Only if you do not plan or do not know this libraries could be cryptic
I do not see the reason to use your "formula". But this and your law ...

Comment 5 Nathan Scott 2017-03-22 01:23:26 UTC
(In reply to gil cattaneo from comment #3)
> (In reply to Nathan Scott from comment #2)
> > Hi Gil,
> > 
> > Oh we were literally working on this in parallel.  Wonderful news that
> > unit-api exists - it sadly didn't when I started :( - and upstream are
> > unaware of your efforts.
> 
> Is really necessary for upstream?

No, not necessary (unless you are feeding patches back there, as we have been) - but in this case upstream is very receptive and likes to hear from us packagers.

> > I switched to using the upstream unitsofmeasurement project prefix because
> > some of the package names are extremely cryptic otherwise (like "uom-se") -
> > *shrug* - is this a concern you share, or think its OK with the short names?
> 
> Only if you do not plan or do not know this libraries could be cryptic
> I do not see the reason to use your "formula". But this and your law ...

Since unit-api exists in pkgdb now, let's stick with the non-unitsofmeasurement-prefixed names everywhere.  I'll update the packages and create new bugzillas.

Thanks Gil.


Note You need to log in before you can comment on or make changes to this bug.