maven central requirements #6
Conversation
|
Hey Alexander, sorry for the delay. I won't be able to have a look today, but I'll try to do at least a first pass early next week. |
There was a problem hiding this comment.
A few nits, but LGTM.
Re Javadoc warnings: yes, let's address those separately. (#7)
Re OSSRH account: would you mind raising an issue asking for it? Meanwhile I'll double check it with the team; people may want a few changes before it.
Many thanks for the contribution, Alexander!
pom.xml
Outdated
|
|
||
| <name>${project.groupId}:${project.artifactId}</name> | ||
| <description>A application used to communicate with certificate transparency log servers.</description> | ||
| <url>http://certificate-transparency.org/</url> |
pom.xml
Outdated
| <licenses> | ||
| <license> | ||
| <name>The Apache License, Version 2.0</name> | ||
| <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url> |
|
I can submit a request to OSSRH, it will be the first time I do this myself, so it will be a good learning experience. |
|
Thanks for the changes, Alexander. About OSSRH, I think one of the open source owners should do it. I'd also like to run it by our tech lead before signing in, have a look at the T&C, etc. Unfortunately a few people are on vacation this week, including our TL, so I'll ask you to wait for about a week on it. Raised #9. |
|
I agree that it's better if one of the owners do it. I would recommend some sort of system so that the same gpg key is used to sign all builds going forward. That makes it easier for people to verify the integrity of the builds. |
I went over these guides http://central.sonatype.org/pages/requirements.html and http://central.sonatype.org/pages/apache-maven.html and added what was required getting the project accepted into maven central.
Someone also needs to apply for an account at OSSRH as described here: http://central.sonatype.org/pages/ossrh-guide.html .
I also added a -SNAPSHOT to the version, this is a magic word for maven that tells it that it's not a release that is being built. My thought was that when we want to release a new version, we branch the repo, remove the -SNAPSHOT and upload that.
The javadoc step adds some warnings about javadoc problems, I think those can be cleaned up in a separate commit?