anyway I need this for another project and it's something we're continually reinventing so putting it someplace reusable seems prudent
the only issue is that “common” ends up being the thing where everything goes :)
I’m ok with that. if you think it is small enough to just be a module there
or if it merits its own repo
the issue with commons is having too many multi modules that you have to release and burn versions
usually each SR repo is related to a project that implements a spec or provides an implementation of a particular space
So, if that is the case, then I thing we got the answer
I was generally only going by complexity but that's not a great measure (especially since it's not really quantifiable)
for example, the JBoss Modules one pretends to support ~/.m2/settings.xml, but in fact only reads some parts of it
(IIRC)
being complete isn't exactly very difficult though
but it doesn't seem maintained
and has quirks too, though I no longer remember exactly what bugged me about it
it doesn't look like it follows Maven rules for transitivity
I think having a one- or two-JAR Maven resolver solution is useful... especially one that isn't likely to be stuck on the test classpath
From the parent, it looks like that should only happen with JDK 9 or higher
Did I not grok it?
hence it being there
just me not checking everything first
