You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Marcin Zajączkowski <ms...@wp.pl> on 2016/12/27 22:31:50 UTC
Recommended groupId for external Groovy modules
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
Re: Recommended groupId for external Groovy modules
Posted by Marcin Zajączkowski <ms...@wp.pl>.
On 2016-12-28 11:49, Guillaume Laforge wrote:
> Hi Marcin,
>
> Some modules have used the groovyx.* namespace in the past.
> It's somewhat semi-standard, in the sense that it's already in use, at
> least.
> It's not dependent upon Apache or the defunct Codehaus foundation, and
> there's no constraint from Sonatype on those.
> If using groovyx, it'd be good to continue using some kind of consensual
> sub-namespace, like groovyx.net.* for network related modules.
Thanks Guillaume for your answer. It seems rationally.
Marcin
> On Tue, Dec 27, 2016 at 11:31 PM, Marcin Zaj\u0105czkowski <ms...@wp.pl> wrote:
>
>> 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
>>
>
>
>
--
http://blog.solidsoft.info/ - Working code is not enough
Re: Recommended groupId for external Groovy modules
Posted by Guillaume Laforge <gl...@gmail.com>.
Hi Marcin,
Some modules have used the groovyx.* namespace in the past.
It's somewhat semi-standard, in the sense that it's already in use, at
least.
It's not dependent upon Apache or the defunct Codehaus foundation, and
there's no constraint from Sonatype on those.
If using groovyx, it'd be good to continue using some kind of consensual
sub-namespace, like groovyx.net.* for network related modules.
Guillaume
On Tue, Dec 27, 2016 at 11:31 PM, Marcin Zajączkowski <ms...@wp.pl> wrote:
> 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
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>