Use normal filesystem-based Gradle paths.

[anuraaga]

I recently found that I had to rely on a sneaky ordering constraint to handle our name mangling

https://github.com/open-telemetry/opentelemetry-java/blob/master/settings.gradle#L73

And in #2295 I found replace(logging- to be causing problems too. I think in general using the filesystem for Gradle paths is more intuitive (just type what's on the path) and it brings more consistency with the java instrumentation repo. So finally have replaced the project name mangling with group-scoped archivesBaseName mangling instead.

Also fixed an issue where our BOM contains non-published artifacts too - not super-harmful but a bit weird.

[trask]

it brings more consistency with the java instrumentation repo

nice

[Oberon00]

Whoa, this is an annoying bug. And an old one 😃

How about we rename the directories instead?

[Oberon00]

I would be happy to get rid of this, but the archiveFilename workaround does not look much better all-in-all IMHO. Maybe we can rename the directories so we can get rid of that workaround too?

[anuraaga]

Ah my comment might have been confusing, the workaround is only setting the group so group + name are unique.

The rest is applying our convention for archive names in a generic way. Another alternative is to not apply rules and just set archivesBaseName in each Gradle file. It's what I do for my own projects. Don't have a particular preference for either though.

I do like the current folder names since the gradle commands are much shorter and easier to execute. Gradle zsh completion has never worked well for me so always have to type everything out.

[Oberon00]

Oh, I see. So basically we are doing the same with the archiveBasenames now that we used to to with the project directory names before, but distributed over multiple files.

I think I would prefer either having everything in one place (maybe the top-level build.gradle) or, like you said, have each project's build.gradle just set it's own name. As it is now in this PR, it's kind of a mixture of the two.

[jkwatson]

I have no strong opinion one way or another on whether we specify the published names in one place, or individually. Just happy someone else is wrangling the gradle. 😜

[anuraaga]

I'd like to avoid the top-level, I think it does end up with some ordering constraints like we already have (https://github.com/open-telemetry/opentelemetry-java/blob/master/settings.gradle#L73 deeper projects must be configured before non-deep projects). This approach takes advantage of normal Gradle ordering rather than having to worry about it ourselves.

I don't think we add groups often enough for this approach to be too weird, so I'm thinking of sticking with it unless there's a stronger push towards per-build-file setting of the archive name :)

[jkwatson]

Thanks for being the #1 gradle-wrangler!