groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin ZajÄ…czkowski <>
Subject Recommended groupId for external Groovy modules
Date Tue, 27 Dec 2016 22:31:50 GMT

Recently I've been taking to Christopher J. Stehno - the author of
http-builder-ng [2] to push the artifacts also to Maven Central. The
problem seems to be the groupId - org.codehaus.groovy.modules. Codehaus
is defunct together with the forge allowing to sync artifacts with Maven
Central. I wanted to talk to Sonatype guys about that, however, writing
the email I realized this issue is more generic and it would be good to
have an consistent position of Groovy developers in that case.

[1] -

The main question that came to mind is: should external Groovy modules
use the same groupId than internal (bundled) ones?

Maven Central guys are in general quite restrictive in a topic of group
id. Every module author would need to have access to the whole
org.codehaus.groovy.modules namespace and publish artifacts there. It
could be potentially dangerous assuming broken artifact configuration.
Not to mention that org.codehaus can disappear one day.

Maybe it would be better (easier to proceed with Soantype's guys) to
request a separate subgroup for xxx.groovy.modules.external,
xxx.groovy.modules.ext or xxx.groovy.extmodules with permissions set
only for that level or even in more restricted way, e.g.

Another related question is about "xxx". When/if migrated to
org.apache.* namespace one day it could be not possible to freely
publish artifacts to org.apache.groovy.modules.ext by external
developers. Maybe there should be another namespace for external
modules? Or maybe they should be kept in their own namespaces?



P.S. I don't propose a revolution. I would like to have http-builder-ng
in Maven Central and with org.codehaus.groovy.modules is seems to be
problematic right now.

-- - Working code is not enough

View raw message