Option to avoid groupId = com.github.User in Maven (without a new DNS entry)

[marco-brandizi]

I've just discovered JP and I think it's very cool. However, I'm not going to use it, as long as I will be forced to change all my groupId(s) into 'com.github.User'. That's not practical at all when you have tens of projects already in place, with multiple internal and external teams and users depending on them. Plus, I don't like to replace stuff like com.myorganisation.myproject.mysubproject with identifiers that are much less clear, and are less appealing from the marketing point of view.

I've read there is already a workaround for this, but it requires that someone put hands in the organisation's DNS, which, in large organisations, can require weeks of interactions and makes it impossible to start new projects, before domains are DNS-registered.

I've been told this constraint prevents people from faking organisations they don't belong in, however: 1) this isn't a big deal in similar situations (e.g., Java package naming, XML namespaces), since people don't usually misbehave 2) it can be addressed with other easier-to-use means, e.g., a postfix like /user or /organisation in the URL to be used inside <repository>.

So, I really hope things will be changed on this.

[jitpack-io]

Hi @marco-brandizi Thank you for your suggestion! Overall its a good idea so will look into how we could add this feature

[marco-brandizi]

Thanks a lot, I'll keep notification on this ticket on :-)

[astubbs]

Also see related: Ability to retain original groupId & artifactId #1029

[marco-brandizi]

@astubbs , nah versions like com.github:* aren't common and risk to mess up with other CI systems or git tools. There is a cleaner solution for this, which is getting rid of this special group prefix requirement and possibly prefix the URL of the user's Maven repo with its github login. I proposed this five years ago, evidently, they're not interested in making it working and hence I had to give up and move to some alternative.

[astubbs]

@marco-brandizi I think you misunderstand me, I completely agree with you. I like the proposal in the linked issue:

<dependency>
    <groupId>org.jenkins-ci.plugins.workflow</groupId>
    <artifactId>workflow-api</artifactId>
    <version>2.9-com.github:jglick:workflow-api-plugin:ea218b9-SNAPSHOT</version>
</dependency>

I just discovered jitpack a few months ago. Stunned they haven't improved this aspect. Bizarre.

What's the alternative you moved to?

[marco-brandizi]

@astubbs if I got that right, they propose to change standard version value schemas and introduce a non standard and complicated pattern. Too much fuss, I don't like it. My alternative has been jFrog or Nexus hosted on my own servers. For a while, I've also tried to use github itself as a Maven repo, but that's not very efficient.