[hibernate-dev] HHH-12172 - Bintray v. OSSRH
Sanne Grinovero
sanne at hibernate.org
Fri Jan 19 10:35:16 EST 2018
On 19 January 2018 at 14:56, Steve Ebersole <steve at hibernate.org> wrote:
> I think it is reasonable to only publish the maven artifacts to Bintray and
> continue to publish the bundles to SourceForge.
Great, so that means we can have about a thousand releases on Bintray;
should be enough for all our projects for at least 10 years.
Thanks,
Sanne
>
>
> On Fri, Jan 19, 2018 at 7:19 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> On 19 January 2018 at 13:05, Steve Ebersole <steve at hibernate.org> wrote:
>> > I sat down and did some calculations to get a better idea of whether
>> > this is
>> > feasible. 5.3.0.Beta1 had a total size of 135M (31M in "maven
>> > artifacts",
>> > 104 in release bundles). At 30G limit, we'd be able to do ~222 releases
>> > before we hit that limit (30 / .135 = 222.2222)
>> >
>> > So if only ORM is going to move to Bintray, I think the 30G limit is not
>> > a
>> > hindrance. Do we see other projects moving away from publishing to
>> > JBoss
>> > Nexus, and if so what publishing repo do y'all plan to use?
>>
>> Yes, as I said before I'm neutral on which one we use, but I was
>> somewhat expecting us to all eventually use the same solution.
>> Seems important to be consistent for sake of end user's experience,
>> but also for us to share tooling, scripts, practices, lessons
>> learned..
>>
>> That said we didn't start looking at that in other Hibernate projects
>> so there would certainly be a lag.
>>
>> The work we're doing on feature-packs might significantly reduce the
>> size of each release, but I think it will only have an impact on the
>> "maven artifacts", which according to your estimates are not the main
>> issue.
>>
>> Maybe we could stick to sourceforge for the release bundles? We all
>> seems to agree that "release bundles" are meant for the more "old
>> school" devs; I'd say they won't be swayed away from Sourceforge
>> anyway, and we should probably keep some continuity there.
>> That would also happen to solve the storage limit problem?
>>
>> Thanks,
>> Sanne
>>
>>
>>
>>
>> >
>> >
>> > On Thu, Jan 18, 2018 at 2:21 PM Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >>
>> >> Bintray said they would increase the storage limit to 30G for
>> >> Hibernate.
>> >> However that limit is per organization, which is the top-level thing
>> >> (https://bintray.com/hibernate). I think we'd eat that up in no time,
>> >> especially if other projects plan on moving to Bintray at any time.
>> >>
>> >> One way around that would be to have each project be its own Bintray
>> >> organization.
>> >>
>> >>
>> >> On Fri, Jan 12, 2018 at 7:33 AM Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >>>
>> >>> 2018-01-12 12:59 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>>
>> >>> > Personally I'm neutral. I surely wouldn't want to manage our own
>> >>> > Artifactory, but since JFrog will do that I'm not concerned about
>> >>> > the
>> >>> > platform management being horrible.
>> >>> >
>> >>> > Artifactory looks better, OSSRH has the benefit of possibly having
>> >>> > better integration with Maven.
>> >>> >
>> >>> > 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.
>> >>> >
>> >>> > # 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.
>> >>> >
>> >>> > # 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.
>> >>> >
>> >>>
>> >>> Debezium already is released to OSSRH from our CI server. May be worth
>> >>> chatting to Jiri (added him to CC) about the details of setup. Note
>> >>> there's
>> >>> no need for key approval by Sonatype (at least last time I did it),
>> >>> you
>> >>> only need to publish them to some key server which you can do all by
>> >>> yourself.
>> >>>
>> >>>
>> >>> >
>> >>> > Not against migrating if this is what you all want - just making
>> >>> > sure
>> >>> > we're keeping these into account.
>> >>> >
>> >>> > Thanks,
>> >>> > Sanne
>> >>> >
>> >>> >
>> >>> > 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).
>> >>> > >
>> >>> > > 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...
>> >>> > >
>> >>> > >
>> >>> > > On 12/19/17 8:34 AM, Steve Ebersole wrote:
>> >>> > >> HHH-12172 is about moving away from the JBoss Nexus repo for
>> >>> > >> publishing
>> >>> > our
>> >>> > >> artifacts. There is an open question about which service to use
>> >>> > instead -
>> >>> > >> Sonatype's OSSRH (Nexus) or JFrog's Bintray (Artifactory).
>> >>> > >>
>> >>> > >> Personally I think Artifactory is far superior of a UI/platform.
>> >>> > >> We
>> >>> > >> all
>> >>> > >> know Nexus from the JBoss deployment of it, and we have all
>> >>> > >> generally
>> >>> > had
>> >>> > >> nothing good to say about it.
>> >>> > >>
>> >>> > >> But I am wondering if anyone has practical experience with
>> >>> > >> either,
>> >>> > >> or
>> >>> > knows
>> >>> > >> persons/projects tyay do and could share their experiences.
>> >>> > >> E.g.,
>> >>> > >> even
>> >>> > >> though I prefer Bintray in almost every regard, I am very nervous
>> >>> > >> that
>> >>> > it
>> >>> > >> seems next to impossible to get help/support with it. The same
>> >>> > >> may
>> >>> > >> be
>> >>> > true
>> >>> > >> with OSSRH - I don't know, hence why I am asking ;)
>> >>> > >> _______________________________________________
>> >>> > >> hibernate-dev mailing list
>> >>> > >> hibernate-dev at lists.jboss.org
>> >>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> > >
>> >>> > >
>> >>> > > _______________________________________________
>> >>> > > hibernate-dev mailing list
>> >>> > > hibernate-dev at lists.jboss.org
>> >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev at lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
More information about the hibernate-dev
mailing list