groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcin Zajączkowski <msz...@wp.pl>
Subject Re: Recommended groupId for external Groovy modules
Date Wed, 28 Dec 2016 22:58:35 GMT
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ączkowski <mszpak@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


Mime
View raw message