Split into multiple, renamed artifacts

[FokkeZB]

We decided we'll rename our libraries to SDKs and extend them beyond wrapping MQTT (#25).

• [x] Rename repo from java-app-lib to java-app-sdk.
• [x] Update docs to talk about SDK rather than Library or Client.
• [x] Rename package from org.thethingsnetwork.java.app.lib to org.thethingsnetwork.app
• [x] Rename org.thethingsnetwork.java.app.lib.Client to org.thethingsnetwork.app.handler.MQTT

@cambierr any suggestions and implications? Let's look at the big picture here and see if the above is future proof. For example; imagine we'd also have a device SDK at some point for IoT running Java. Then we'd add a repo java-device-sdk and use package name org.thethingsnetwork.device?

[cambierr]

First thought about this:

Well, I think that we should separate this project into different artifacts depending of the features, since maven has a multi-component project system.

1. I don't think that keeping .java in the groupId is really needed ? We probably should stay with org.thethingsnetwork as groupId to make inclusions shorter and easier
2. We can keep org.thethingsnetwork as groupId and separate artifacts as follow: 2.1. org.thethingsnetwork.handler.sdk for the http sdk 2.2. org.thethingsnetwork.handler.mqtt for the mqtt wrapper 2.3. (future) org.thethingsnetwork.handler.amqp for amqp wrapper 2.4. (future) org.thethingsnetwork.device.sdk for something related to devices running java

Also, for the http sdk we should consider providing both sync and async apis: org.thethingsnetwork.sdk and org.thethingsnetwork.sdk.async using any popular async framework like https://github.com/ReactiveX/RxJava/)

[FokkeZB]

I suggested org.thethingsnetwork.app because atm I think if a language can be used on both devices and applications (like Node.js or Java) we might want to have separate SDKs (org.thethingsnetwork.device) because you don't want to have the app-side stuff taking up space on your device.

But maybe it doesn't work like that with Java and we can have one project (SDK) with multiple artificats and you can just decide which ones to actually use (and compile). In that case we'd have:

• org.thethingsnetwork.handler.message which is what we have now, wrapping MQTT but might be replaced with AMQP later or we choose to later split into org.thethingsnetwork.handler.message.mqtt and org.thethingsnetwork.handler.message.amqp.
• org.thethingsnetwork.handler.manage which would implement #25 either through the HTTP or (better) gRPC API, or both if it makes sense (like MQTT and AMQP).
• org.thethingsnetwork.account which would wrap the Account Server HTTP API for getting a session token to use with org.thethingsnetwork.handler.manage

Also see the draft at https://www.thethingsnetwork.org/docs/draft/platforms/

What do you think?

[cambierr]

You're right, java supports multiple artifacts in the same project, meaning that you can build & deploy all of them at the same time using the same group id (org.ttn) but keeping them as different files separately embeddable.

I agree with everything you said. I'll try to get some time to start this week :)

[FokkeZB]

Awesmome. Thx a lot @cambierr, for pioneering with the SDK. For Node.js I'll probably create multiple NPM packages under the same repo with the current one simply depending on and exposing all of them. That's how it'll be for most interpreted languages then.

[FokkeZB]

After further discussion on Slack we proposed @johanstokking to go with data instead of message and use management instead of manage since that works better in a sentence like: To use the Handler Management API you need an access token.

[FokkeZB]

OK, data and management it is. Also, we will keep device and app SDKs separate. So this repo will be renamed (#27) to java-app-sdk not java-sdk.

[cambierr]

So, account SDK is done. Both MQTT and AMQP data sdk are also done. I'll start management sdk by the week-end ;-)

[FokkeZB]

Whaaaat?! You rock! 🚀