Hi, 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] - https://github.com/http-builder-ng/http-builder-ng 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. xxx.groovy.modules.external.httpbuilderng? 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? WDYT? Marcin 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. -- http://blog.solidsoft.info/ - Working code is not enough
