[hibernate-dev] HHH-12172 - Bintray v. OSSRH

Steve Ebersole steve at hibernate.org
Fri Jan 12 07:54:07 EST 2018


Firstly, if anyone looked at the Jira, you would see that Bintray simply
won't work.  They have a 10G storage limit.  That's something we would hit
pretty soon, depending on which projects moved there.  Also, getting in
touch with them for any kind of support has be a pretty big pain; its
generally been multiple days until I here a reply - most recently I last
asked a question on Monday or Tuesday that I still have not had a reply
about.

That's a shame because the UI is IMO significantly better than Nexus.  Yes,
JBoss has a particularly bad Nexus set up - but let's not lose sight of the
fact that its still Nexus and we all still very much dislike that UI.


On Fri, Jan 12, 2018 at 6:32 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Artifactory looks better, OSSRH has the benefit of possibly having
> better integration with Maven.
>

Simply not true, but not really relevant since we wont be using Bintray.



> There are some benefits on staying to JBoss's nexus though; not
> expressing a strong opinion but let's clarify these.
>
> # Stats
> We need download statistics, which I understand they all offer, but an
> absolute number is not as useful as being able to compare the numbers
> in one dashboard across various others of our projects.
> Also not looking forward to have to login to multiple systems to gather it
> all.
>

You have to already.  Nexus and SourceForge at the least.



> # Quality control of artifacts
> I'm understanding that JBoss Nexus does several strict validations on
> our poms; sure they have been in the way as it's not nice to see such
> failures *during* a release but there's an upside to them as well.
> AFAIK OSSRH also has similar rules, but the JBoss team one has
> different ones, plus a deal with Sonatype to deem our stuff good
> "pre-approved" so we don't have to satisfy the Sonatype rules too.
>

They both validate pretty much the same exact information.  I'm not at all
sure what you mean as a point here.



> # Signing
> Also I'm understanding that to release on OSSRH we need to sign all
> artifacts; not a bad idea but it's quite more papework and key
> management. Such paperwork is handled for us by the JBoss Nexus team.
> We'd need to install GPG on our release servers, get a organization
> RSA key signed, and people stubbornly releasing manually will have to
> create a key each, and have it approved by Sonatype.
>

This was another key benefit of Bintray.  It actually has the capability of
signing your artifacts as you publish them, meaning you do not have to do
do any of these steps that concern you - you *can* set up signing to use
your own key, but you can also just let Bintray handle it for you.




> On 12 January 2018 at 02:47, Brett Meyer <brett at hibernate.org> wrote:
> > Sorry for the late and probably irrelevant response...
> >
> > We're using an in-house Artifactory instance at a gig and it's been
> > trash.  I can't speak to the UI or management end, nor Bintray, but
> > Artifactory's platform doesn't seem as polished (can't believe I just
> > said that) or stable (can't believe I said that either) as Nexus (what
> > is happening).
>

We are only considering things we don't have to host.  So one platform
being harder to set up, maintain, etc is not at all a concern.


> > I use OSSRH for some minor projects and have generally had decent luck
> > -- including a few interactions with the support team that went well.
> > OSSRH != JBoss Nexus, although I definitely understand the wounds...
>

I have also had very good experiences with Sonatype regarding OSSRH
support  as well.

As far as "OSSRH != JBoss Nexus" that is certainly true to an extent.  But
really our troubles with JBoss Nexus break down into 2 categories:

   1. Infrastructure - JBoss Nexus has often been slow, unstable.  This is
   the one point I definitely agree with, in that I would assume OSSRH will be
   much better.
   2. UI - ts still Nexus.  The UI is not going to be any better, let alone
   significantly better.


More information about the hibernate-dev mailing list