Naming artifacts in public repositories

[Werner Keil]

Hi,

We recently saw some momentum in the community following the EDR.

The Melbourne Java & JVM Users Group just held a Hack Night and suggested a Howto or Tutorial for future events like it.

And JUG Hyderabad added an Adopt-a-JSR project for Astronomy https://github.com/jughyd/uom-astronomy

Both that, earlier health and fitness related artifacts or the Farm project we heard about form Melbourne raise the question of some naming standards for new artifacts, should their creators wish to contribute them under "tec.uom", the domain shortcut we got for the project.

As of now the following Maven groupIds already exist or are proposed for the last 2

• tec.uom.impl  For implementations, at the moment there's only one using enums.
• tec.uom.se       The Java SE 8+ forward-port of the Reference Implementation
• tec.uom.demo  For everything that is purely a demo. Usually no reuse by other modules or applications intended.
• tec.uom.lib   Reusable libraries
  
• tec.uom.domain (proposed for Domain Specific libraries in areas like healthcare, energy, automotive, etc.)
• tec.uom.modules a possible alternative? See projects like DeltaSpike,... the upcoming Java 9 "module system" could also benefit from this namespace

Would you prefer a Domain Specific group for DSLs (also not necessarily Java alone, could be other JVM languages) and similar purposes, or keep everything under "tec.uom.lib" or "tec.uom.modules" or something else (please suggest below if you have another idea)

Especially Sonatype/MavenCentral usually asks the owner/registrar of a particular project for permission before publishing to a certain namespace. It helps if these components are used in the Internet of Things to tell them apart, not just via Maven or Gradle.

Ideally you should try to call a Java package like your group ID, especially where Java 9/Jigsaw or other similar techniques like OSGi come into play it is important to have these two in sync.

Thanks,

Werner

[Werner Keil]

Dear All,

There are 2 more top level UOM bundles for specific purposes

• tec.uom.client  For clients on Rich desktop or Embedded devices
• tec.uom.tools   For tools primarily those introduced by https://github.com/unitsofmeasurement/uom-tools

Regards,

Werner

[Werner Keil]

Hi,

 

As an addition to the mentioned bundles in order to provide a modular, reusable type system, there are 2 recent top level domains for units and quantities

• si.uom       A unique top level domain and groupId dedicated to the SI System
• systems.uom  A top level domain and groupId for any other Unit System (e.g. US, Imperial, UCUM, etc.)

I hope, nobody feels overwhelmed or confused by different top level domains for special purposes? While many projects also for their Maven/Gradle/OSGi artifact naming jump the "io" bandwagon, a new ".systems" TLD as well as the the national domain of Slowenia ".si" both seem far more compelling than an also more expensive "io.uom" which is practically meaningless in this context.

 

Both got their own module repositories:

• https://github.com/unitsofmeasurement/si-units (to avoid confusion with especially the "SE" implementation we didn't call it "uom-si"
• https://github.com/unitsofmeasurement/uom-systems (stay tuned for more, but expect to see at least major unit systems like US or Imperial other than SI and reusable quantities unique to these systems)

Regards,

Werner

[Werner Keil]

Hi,

A little update on this topic as we now got more and more libraries deployed to JFRog OSS.

uom-domain

https://oss.jfrog.org/oss-snapshot-local/tec/uom/domain/

shows what's proposed for all modules and libraries on top of Unit-API and its implementations.

Since over time there might be further platform-specific implementation modules (e.g. "-arm" or similar) these modules don't distinguish between "ri" or "se" but rather mark a special platform or version they support.

In most cases a Parent POM is named "-parent", e.g. "uom-health-parent".

API definitions are always platform- and implementation-neutral, they work from the minimal (JVM) version required which is usually Java 6 now (5 is long past End of Support, but especially Java 6 is still very common in Embedded or other closed environments)

API Modules are named "-api", e.g. "uom-health-api".
Quantity type definitions are also platform- and implementation-neutral. 

Unless part of an API module (see "unit-api" or "uom-health-api") they are contained in a dedicated artifact named "-quantity", e.g. "si-quantity".

"impl" modules in most cases use the parent module's name e.g. "uom-health" which means, they are compatible with all supported environments and usually based on the RI unless otherwise noted.

If there's a special technology involved, e.g. "CDI", "Spring", etc. you may find this as a post-fix, similar to common practice by the Agorava Project (www.agorava.org)

Implementing modules that require a particular environment or (JVM) version are named like "-java8", e.g. "uom-health-java8". 

The term "java8" stands for "Java SE 8", or "JDK8" if you want. If an implementing module was specific to Java ME 8 Embedded, it would use "-cldc8" which is the ME 8 specific environment (JSR 360)

I hope this helps find the right artifact for the right environment.

If you have any questions or additional suggestions, please share them here.

Regards,

Werner

[Werner Keil]

Hi,

As an incubator or "Open Spaces" a bit similar to "javamoney-shelter", I decided to offer the domain

space.uom  
for "Units of Measurement Spaces". 

The JUG Hyderabad added an Adopt-a-JSR project for Astronomy https://github.com/jughyd/uom-astronomy shares this under "space.uom.astronomy" while other projects and Hacker Spaces or Hackathons are free to use it as well.

Enjoy,

Werner