This message was deleted.

Hey @Ivan CLOVIS Canet! 👋 The only official recommendations we have on project naming are here: https://docs.gradle.org/current/userguide/multi_project_builds.html#naming_recommendations They do not address your specific concern, however. For that, my personal recommendation would be to use the

projectName-x

convention as you described. In fact, we can look at a few open source projects that demonstrate the same convention: • https://github.com/spring-projects/spring-framework • https://github.com/junit-team/junit5 But there are also many projects that do not follow that convention. It should be noted that you can always override the convention of using the project name only as the published artifactId. For example, you could override the convention to be

{rootProjectName}-{projectName}

. See the Gradle documentation for more info on configuring the publishing plugin: https://docs.gradle.org/current/userguide/publishing_maven.html

But that would then make problem if the project is consumed in a composite build, wouldn't it? 😕 An alternative would be, that you do not publish at

<my-group>:...

but at

<my-group>.projectName:...

.

But that would then make problem if the project is consumed in a composite build, wouldn't it?

Could you describe a scenario in which it would cause a problem? 🤔

An alternative would be, that you do not publish at

<my-group>:...

but at

<my-group>.projectName:....

.

Yeah, that would work too!

Could you describe a scenario in which it would cause a problem?

With "problem" I mean you cannot simply include it, but need to use manual dependency substitution, which I personally see as work-around for badly configure builds. 😄

Ah, yes. I understand now. 👍 Indeed if you need to use composite builds it would not be a good option to deviate from Gradle's artifactId convention for published artifacts.

Even if you don't, someone else using your library might want to use latests code to test or fix something, so just don't mess with it. 😄 (it being changing artifact coordinates on publishing)

Yes. It's usually not a good idea to deviate from Gradle conventions. 😅

…I might have to add the project name to the group then. At least that makes some semantic sense. Would that cause issues with Central? With their group verification policies?

No, if you own

foo.bar

you also own all

foo.bar.baz

,

foo.bar.baz.bam

and so on.

Thanks, that's reassuring. Sounds like it's the best solution, then. Thanks.

To clarify, in case the discussion on changing the published

artifactId

introduced any confusion, you could still use

<my-group>:projectName-x:<version>

if for some reason a consistent group is important to you. If not, then Vampire's suggestion is certainly less verbose.

I don't really care about the group as long as it doesn't cause problems with Central. Included builds are important for me though.