[sakai2-tcc] Thoughts on indieness of TinyUrl

[csev]

I don't know why but I woke up this morning thinking about TinyURL and how it should come into the release source.

Initially, I was anti-indie, suggesting the tool be in /sakai and the service be in common.

Upon further contemplation, I think that the TinyURL service should be in common but the tool can be as indie as it likes.

The key comes down to expanding the dependencies on tools that want to use the TinyUrl service (api + impl) - what I don't want to see is yet another separately tracked dependency in 40-50 poms that will skew.   So that part of TInyUrl that other tools will use needs to be placed in some existing spot - such as common - but the rest of the tool/UI for TinyURL can be anywhere it likes - indie would be fine.

In thinking about this logic, I would apply the same to Basic LTI which is currently happily indie.  If (and this might happen) other tools such as resources were to start depending on the Basic LTI service, it would be really bad to add a Basiclti-1.3.1 dependency to resources and then chase that around.  So at the moment that other tools start depending on something like BasicLTI or TinyURL service - it should be hoisted into common and tool dependencies for TinyURL should be to common.

Separately thinking about versioning of common.  It occurs to me that when we look at kernel and common, the difference is the speed at which they move - kernel should move slower and common could move faster.    But really, kernel and common are not very independent at all.   So one possible way to fix this is to align the kernel and common versions by making the kernel version a prefix of the common version.   So common versions

1.2.1.1, 1.2.1.2, 1.2.1.3

Would all be compatible with kernel

1.2.1

That way it is really clear.   And if we could do some POM magic, perhaps the kernel dependency could be simply expressed inside the common pom so tools could simply express their common dependency (1.2.1.4) and get their implied kernel dependency (1.2.1) without an explicit kernel dependency.

I would just in general like to move toward a world where a newly built tool needs fewer, not more dependencies.

/Chuck