Artifact group id for java gelf library


(Sami Korhonen) #1

I took liberty of modifying gelfj library quite heavily. Now that I’m somewhat satisfied with my modifications (didn’t really dare to run original gelfj in production on application servers), I’m planning to release plugin in maven central. However, in order to release, I need to have proper group id for artifact.

My problem is well described in answer that I got from sonatype: “Our current policies require that a groupId reflect a domain you own or control. So, if you don’t want your name or organization reflected in the groupId, you can look into purchasing a domain that you prefer.”

I don’t really see myself getting a domain for publishing such a smallish utility library. Which leads to my question, would it be possible to publish artifact under org.graylog.gelf?


(Jochen) #2

No, that’s intentionally not possible.

You can use your GitHub page URL as group ID, if you want to publish your modified version of gelfj, i. e. io.github.skorhone or io.github.skorhone.gelf.

This being said, have you tried simply proposing your changes to the original project as a pull request?


(Sami Korhonen) #3

I have proposed few of feature requests as pull requests - some got through, some are still pending. I have not made effort of creating new requests anymore, because I could not get any feedback on earlier requests

Also, considering project has deviated quite a bit from original project, I do not consider it as same project.

Background: Gelfj was good enough for testing graylog and learning gelf protocol. Missing features, such as no network fault tolerancy, made it impossible for us to consider use on production application servers. We were left with two options. First option was to parse log from files and try to manage hundreds of parsing rules. Second was to improve library to handle network error conditions better and add support for sending structured entries using common logging frameworks. Considering how hard it would be to manage parsing rules over time (in our environment), we picked the second choice. Having no parsing also means that our developers have fewer things to test and learn :slight_smile:

While I could see benefits of having library published on maven central, I really don’t want to publish it with my name on group id. I guess I’ll leave this problem to others and keep using internal artifact repositories :slight_smile:


(Jochen) #4

Why not? It’s reasonably simple to do so and it was the purpose of your original post, wasn’t it?