Sort out names and directories

[amedranogil]

Primary objective is that new developers are able to navigate and understand the sample code.

Use this thread to comment & discuss possiblibilities.

@universAAL/platform-developers should coordinate the effort.

[Alfiva]

I was going to suggest to have all projects in the root... but lighting example has its own folder...
In any case, we should first review what is outdated and remove it.

[amedranogil]

outdated candidates :

• Bluetooth_HDP_Manager_v6 2 years
• Runner-Folder-TEMPLATE 2 years + part of Maven repo
• deploy-lifecycle 2 years
• simple.logging 2 years
• smp.ri.exportComponent 2 years
• usrv.infoframe 2 years
• simple.ui.run 1 year
• smp.ri.gateway.communicator 10 months

[cstockloew]

+1 means remove..

Bluetooth_HDP_Manager_v6 2 years

seems to be BT on Android. Not sure if it still works, but an example of how to use BT. Maybe keeping it in gitlab is enough.
+1

Runner-Folder-TEMPLATE 2 years + part of Maven repo

move to distro.pax

deploy-lifecycle 2 years

Maybe keeping it in gitlab is enough.
+1

simple.logging 2 years

wrong way of logging; does not use the container functions.
+1

smp.ri.exportComponent 2 years

should still work
-1

usrv.infoframe 2 years

for the old/unavailable uStore. Maybe keeping it in gitlab is enough.
+1

simple.ui.run 1 year

+1

smp.ri.gateway.communicator 10 months

it's for the old GW; does it still work?
+1

Additionally, we can remove:
smp.mw.runner
-> move to distro.pax
smp.mw.broker.client
-> shows how to create a new broker/bus - who needs this? Keep in gitlab?
karaf\mw.karaf.feature.ping-pong.osgi

[Alfiva]

Bluetooth_HDP_Manager_v6 is, if I am not mistaken, a sample app for the Continua-based bluetooth blood pressure device (the same demoed in the review). However, with 2 years of inactivity, I doubt it is as useful... I have other source code locally that would look better. But I would vote for putting it on Android repo - if at all.

[amedranogil]

smp.mw.broker.client

might still be useful, maybe the configuration framework can be refactor as a bus, based on this example.
maybe someone comes up with a new bus-like feature. 👎 to remove. for sure readme should advice it is an example for deep mw development (high expertise).

smp.mw.runner
-> move to distro.pax

we must be careful, ditro.pax should be a "unique" (one per branch) template for creating pax based run configurations.

karaf\mw.karaf.feature.ping-pong.osgi

maybe this concrete example is the wrong way to put it, but I think we should have a tutorial on how to create your own karaf features.

[cstockloew]

This issue is open for a long time and some samples have been removed already. Is it done? Can the issue be closed, or should anything else be done?

[amedranogil]

I beliebe samples still need some sorting.
Maybe a good idea is to create folders for less usefull samples, for example there are many LDDI samples (¿?) which can be organised into a folder (out of view out of mind).
probably we don't need karaf samples any more.

[cstockloew]

I'm not so sure about this: what would be a "less" useful sample? How can you define "useful"? I guess, everyone has a certain interest and wants to realize a certain functionality. So, everything can be useful for someone...

When we talk about IoT, then this is often referred to as working with devices, so why should the lddi samples be less useful?

Removing the karaf samples seem to be OK. But how do you start the lighting sample in Karaf? Is is integrated somewhere else? Just asking because of
https://github.com/universAAL/platform/wiki/Running-the-lighting-sample

[amedranogil]

sorry, definition of useful: interesting for newcomers.
Some samples are a bit more advanced, for example dose I mention. I'm not proposing to get rid of them just better organise the content.

For karaf examples we might can use gists, creating Docker-like scripts that build the runenvironmet from scratch (or othre repos).

[cstockloew]

Not sure if this definition of useful is really useful. From my point of view, the only sample that is really "useful" for newcomers is the lighting sample (maybe utils/aapi). All the other samples may be for someone who takes the "second step"..

What about this: we leave the "flat" structure, but improve the wiki page, e.g. to group them according to mw, lddi, etc..

The lighting karaf feature can also be moved to lighting folder and ping-pong can be removed. I prefer to keep the lighting karaf on Nexus for the platform wiki (having this as simple as possible).

At the beginning, I also wanted to have more clear names, e.g. according to the repos they reflect, e.g.:

• smp.ri.exportComponent (with "ri")
• smp.ctxt.situation.reasoner.client (with "ctxt")
• smp.mw.deploymanager.client (with "mw")

This is a possibility, but it was, unfortunately, never fully applied. Although they are also "all" samples for the use of the busses..