Publish to Maven Central
stevespringett opened this issue · comments
Once the PR is merged, lets see if this is ready to be published to Maven Central.
Currently, there are two projects using this:
In the near future, the OWASP Dependency-Check project will also likely adopt it.
I'd like to have the artifact in Central so we don't have to have a local copy of the code in our own repositories.
@stevespringett Sorry for missing this ticket earlier. ...
I made you a repo admin and I create a ticket to make you an org co-admin: package-url/purl-spec#45
I assume that you know everything to publish to Maven central ... and can handle it alright!
Thanks much @pombredanne. I'm going to review what's here and publish to Central in the next week or two.
@pombredanne I don't think the repo admin permissions tool effect. I don't see the 'settings' button for example and I tried pushing to the repo and was denied.
@stevespringett there is an invite that I can see having been sent... and not yet accepted
@stevespringett also I reckon that the Java convention is to use deeply nested directories for packages and a reverse domain name.... yet I do not like it ... and in particular we are in no way associated with Github... so a com.github namespace feels really weird.
Would it be possible to have a simpler, single level package such as packageurl instead?
@pombredanne publishing artifacts to Maven Central requires proof-of-ownership for the groupId being registered. This is usually one of two things: 1) a reverse domain name of the projects domain/website, or 2) a reverse domain name+repo of the projects source code repository. There are examples of this pattern not applying - for example, many legacy apache projects have non-standard groupIds which do not show ownership. A perfect example of this is: https://mvnrepository.com/artifact/axis/axis. However, those projects are grandfathered in and do not have the proof-of-ownership requirement.
So for a groupId, the only thing I can register is com.github.package-url because it's the only thing I can show that proves ownership. If we register the packageurl.org domain for example, I'll be able to register the org.packageurl groupId as well - and that's something we should consider.
When Sonatype approves groupIds, they do check to ensure the package structure matches (or is close to) the groupId being registered and will give us a hard time if its not, even though it's not against policy. But there's no oversight/governance for this that I'm aware of, so now that the groupId is registered, we can change the package structure to org.packageurl if we want, although the groupId will have to stay the same, at least for now.
Regarding domain names / website... I'd be more than happy to register packageurl.org so that we have it. I personally use Media Temple for all my hosting, of which I host dependencytrack.org and cyclonedx.org, among a few others. I also have this tied into Cloudflare so those sites get the performance and security benefits from the service automatically. None of this costs me any money other than the domain name - which I checked and it's available for $12.99.
so its pretty common for folks publishing from github that otherwise do not have a domain, to use com.github., good or bad as that may be:
http://repo1.maven.org/maven2/com/github/
Use of shorter groupIds like pacakgeurl is a legacy artifact of maven1 days and should be avoided. Axis is a good example of legacy, non-preferred groupId scheme.
You could also consider io.github.package-url; which correlates to any potential github-pages sites that are created for the 'package-url' organization, which is also quite common:
First release published to Central