Fine with me.
On 01/24/2018 11:23 AM, Guillaume Smet wrote:
> Sure you can get rid of it.
>
> The only versions of OGM there is a very old one people shouldn't use.
>
> Thanks!
>
> On Wed, Jan 24, 2018 at 4:58 PM, andrea boriero
> wrote:
>
>> no objection
>>
>> On 24 January 2018 at 15:51, Steve
Sure you can get rid of it.
The only versions of OGM there is a very old one people shouldn't use.
Thanks!
On Wed, Jan 24, 2018 at 4:58 PM, andrea boriero
wrote:
> no objection
>
> On 24 January 2018 at 15:51, Steve Ebersole wrote:
>
>> Do y'all mind then if I get rid of the hibernate/bundles
no objection
On 24 January 2018 at 15:51, Steve Ebersole wrote:
> Do y'all mind then if I get rid of the hibernate/bundles[1] repo? It's a
> "generic" Artifactory repo meant to hold release bundles. ORM[2] and
> OGM[3] both have played with it, as we both have versions published there.
> But f
Do y'all mind then if I get rid of the hibernate/bundles[1] repo? It's a
"generic" Artifactory repo meant to hold release bundles. ORM[2] and
OGM[3] both have played with it, as we both have versions published there.
But for ORM at least those are also on SourceForge and its not important
that I
On Fri, Jan 19, 2018 at 5:33 PM, Steve Ebersole wrote:
> yessir
>
Nice, thanks for confirming.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
yessir
On Fri, Jan 19, 2018 at 10:28 AM Guillaume Smet
wrote:
> On Fri, Jan 19, 2018 at 5:15 PM, Steve Ebersole
> wrote:
>
>> Agreed. So unless someone has an argument against, I will plan on
>> switching over to Bintray publishing for the next 5.3 release.
>>
>
> Not an argument against but j
On Fri, Jan 19, 2018 at 5:15 PM, Steve Ebersole wrote:
> Agreed. So unless someone has an argument against, I will plan on
> switching over to Bintray publishing for the next 5.3 release.
>
Not an argument against but just to be sure, you will be able to
synchronize artifacts from the org.hiber
Agreed. So unless someone has an argument against, I will plan on
switching over to Bintray publishing for the next 5.3 release.
This means we will need to update the older versions we still want to
release to publish to Bintray. Gail, that's just which versions?
On Fri, Jan 19, 2018 at 9:35 A
On 19 January 2018 at 14:56, Steve Ebersole 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 le
I think it is reasonable to only publish the maven artifacts to Bintray and
continue to publish the bundles to SourceForge.
On Fri, Jan 19, 2018 at 7:19 AM Sanne Grinovero wrote:
> On 19 January 2018 at 13:05, Steve Ebersole wrote:
> > I sat down and did some calculations to get a better idea
On 19 January 2018 at 13:05, Steve Ebersole 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
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.)
So if only ORM is going t
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 t
2018-01-12 12:59 GMT+01:00 Sanne Grinovero :
> 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
> bet
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
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 s
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 believ
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
18 matches
Mail list logo
