Publish artifact to Maven Central
electrum opened this issue · comments
Please publish this library to the Maven Central Repository. This allows anyone to use it simply by adding a dependency in his POM file.
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide
Sounds like a great idea, but I must say that this is a bit overwhelming. PGP signatures? Coordinates? JIRA tickets?
Can you help?
(1) Is the pom.xml file correct, or does it need fixing? Is there anything else in the project that requires fixing?
(2) Which repository should be used, there seems to be many of them?
Disclaimer: I am not a Maven user. The pom.xml file was contributed.
I agree, it is a lot to learn and setup, especially for your first project. It is less work for subsequent projects, and very little work for releases after you setup a project.
For your first project, you need to create a PGP key locally for signing artifacts. You also need to signup for JIRA and create a ticket for your project.
- The POM file will need some additions: adding oss-parent as the parent; adding a licenses, developers and scm sections.
- You want to use the OSS repository. It gets synced to the Central repository, which is the default repository for all Maven users.
You should change the groupId (the "coordinates") and the package name to follow the package name rules (it should start with a domain that you control). Some suggestions:
com.github.lemire.javaewah
com.googlecode.compressedbitset
me.lemire.javaewah
If you like, I can make the POM changes for you and help you make the first release.
Yes, please, do contribute some improvements.
Concerns:
(1) I certainly don't want to have to own private keys related to this project. This is an open source project and I want everyone to be able to take it and run with it. I manage it today, but maybe tomorrow, someone else could take over javaewah, so I don't want me, personally, to be tied to the project with a key that I, alone, owns. (This is not just theoretical. I have started projects before that have been adopted by others, and also the reverse... I have adopted projects started by others...)
(2) I understand the Sun package convention, but the current package name is unique. So there is no risk of a conflict. If someone feels strongly that this needs to have a different package name, and they push the change on github, I will integrate it, but I don't want something I control. This is something I started, but I would happily pass it on to other people. I don't want my name embedded in the package names. It seems very wrong to me.
To be clearer, a lot of people have contributed to javaewah. I did the bulk of the work. I am glad to keep on maintaining it, but this is not something I want to be the sole owner of. Any step that ties me, personally, to the software, feels wrong. For practical reasons, someone has to be responsible for it... but it should not necessarily always be the same person.
For example, if you told me: "he! Daniel... what would you say if I took over javaewah... I have great ideas for it and so on..." I'd say: "great, go ahead, you are now the maintainer".
(1) When releasing a project, whoever does the release typically uses his/her own PGP key. The key doesn't have to be tied to the project.
(2) I talked to some Maven experts and found I was wrong about needing to rename the package. Since it's unique, it's fine to have a non-qualified top-level name, and it doesn't have to match the groupId. However, it's best practice to qualify the groupId, mainly because the groupId is a global, browsable namespace. You can go to http://search.maven.org/#browse and see the size of the current list, then imagine how unmanageable it would be if every project used a unique top-level name.
I understand your concerns about not tying the name to you personally. How about one of the following:
com.googlecode.javaewah
com.github.javaewah <-- create a "javaewah" organization on GitHub for the project
An advantage of creating a GitHub organization for the project is that it's easy to add/remove members and transfer ownership. It does seem overkill for a small project that easily fits in a single repository, but that's a GitHub problem.
Ok. But what are the benefits of doingl this administrative work? For example, Apache Hive uses JavaEWAH, and they simply distribute a copy of the 15KB jar file. This is far more robust than this maven-driven approach. No?
It is not like I object to it... if someone wants to contribute it to the project, I will gladly support it, the same way I support the maven pom.xml file even though I don't use maven myself... But, for the time being, I don't see myself doing this work.
The main benefit is that the project is easily available to Maven users. Using a non-Mavenized dependency in a Maven project is a lot of work, and is basically impossible if you have multiple developers working on a project but don't have your own Maven repository (e.g. a typical open source project).
Actually, the reason I'm raising this issue is because I'm working on converting Hive to use Maven (HIVE-2229). Hive already uses Maven dependencies via Ivy. In fact, javaewah is the only dependency that is not available in Maven (HIVE-2448).
The "directory of jars" approach to dependency management doesn't scale. Suppose you start a new project that has 5 dependencies. Each of them has 3 dependencies, and in turn those dependencies each have 3 dependencies. Now you have 45 jars in your lib directory. Simply copying that many files is much more work than adding the 5 direct dependencies to the POM, and that's assuming you already know which files to copy and have them accessible. (This isn't a contrived example: I just checked our rather simple discovery service server and it contains ~90 dependencies.)
But how do you know what dependencies and versions a random jar requires? Dig around the project website or documentation? How do you know you have the right versions of the all the dependencies and that they are compatible? How do you upgrade a dependency and all of it's dependencies? Over time, the jar directory accumulates cruft. How do you know which dependencies are actually used?
When you're debugging in your IDE, how do you get source code for a jar? Manually download the source and tell your IDE about it? With Maven, your IDE will automatically download the source and documentation for all dependencies.
The benefits to using Maven over other systems are numerous. See HIVE-2229 for some examples. A huge benefit for me is you can use POM as a project file for your IDE: just checkout the source and open the POM in the IDE. No manual configuration of anything!
Maven definitely has a steep learning curve, and certainly has it's share of problems and frustrations, but it's far better than anything else I've used.
If you have no objections, I can set it up and perform a Maven release using the groupId com.googlecode.javaewah.
Ok, ok, maybe I'm way off on this.
Yes, yes, of course if you were to do a Maven release, I would love this. Don't hesitate to add your name as a contributor to the project if you do so... Want me to add you to the google code project?
Cheers!
Update: I have updated the project and I have opened a JIRA ticket. With some luck, there will be a central repository release in the next week or so.
Ok, I just pushed release 0.3.1. Hopefully it will make it to the maven central repository. I'll close your ticket when this happens.
You can download JavaEWAH from the Maven central repository: http://repo1.maven.org/maven2/com/googlecode/javaewah/JavaEWAH/
You can also specify the dependency in the Maven "pom.xml" file:
com.googlecode.javaewah JavaEWAH 0.3.1I'm closing this issue.
Daniel, thanks for doing this!
You were right, this needed to be done. Let me know if it works for you.
I would like to stress however that, just as I feared, it was hard work (surprisingly so).
Well, it won't be so much work in the future.
This is indeed very helpful. In the past, I had to put your excellent library into a local maven repository to share among the team, now I don't have to do that. Thank you for doing this.
@huahaiy Glad that this was useful work!
I'll keep releasing updates to maven central.
BTW version 0.3.2 should be out soon (in an hour or so).