Re: [infinispan-dev] Jenkins migration

Thanks Sebastian! Looks like we can remove the claim plugin, too, because it doesn't work with pipelines: https://issues.jenkins-ci.org/browse/JENKINS-33969 Cheers Dan PS: I'm the one who installed the Blue Ocean plugin, but I thought it was opt-in for every user. Sorry about that! On Mon,

Re: [infinispan-dev] Jenkins migration

Personally I've always used Jenkins and for that reason I didn't like Infinispan to use TeamCity - mainly as I'm not used to its UI - but I'll admit that its capability to focus on the test history, highlighting the first failure in time and its "stability" over time on a per-test focus rather

Re: [infinispan-dev] Jenkins migration

Radim, it's not like the default UI became much better since we evaluated it against TeamCity, it's just that we no longer have a choice :) And I'm sure in the Blue Ocean UI will get more development effort than the default UI in the future, but at this time it's clearly unfinished. Cheers Dan

[infinispan-dev] Weekly IRC meeting logs 2017-04-24

Hello all, here are the logs for our meeting this week: http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2017/infinispan.2017-04-24-14.03.html Gustavo ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

Re: [infinispan-dev] Jenkins migration

On 24 April 2017 at 13:08, Tristan Tarrant wrote: > You mean exactly like the current CI is being handled? :-) > ​Cool, that other statement sounded like it could have misled you. > > On 24 Apr 2017 13:33, "Sanne Grinovero" wrote: > >> >> >> On 24

Re: [infinispan-dev] Jenkins migration

You mean exactly like the current CI is being handled? :-) On 24 Apr 2017 13:33, "Sanne Grinovero" wrote: > > > On 24 April 2017 at 12:19, Sebastian Laskawiec > wrote: > >> Hey! >> >> I uninstalled Blue Ocean plugin. I think it's worth to have another

[infinispan-dev] Weekly IRC meeting

I will be unable to make it to the meeting today. Last week: ISPN-7479 Add Failover and Execution Policy to ClusterExecutor This has been completed and integrated. I also was looking at CI to find some stuff that could be fixed, I submitted ISPN-7743 DistributedStreamIteratorTest.testNode*

Re: [infinispan-dev] Jenkins migration

On 24 April 2017 at 12:19, Sebastian Laskawiec wrote: > Hey! > > I uninstalled Blue Ocean plugin. I think it's worth to have another look > at it as soon as 1.1.0 is released [1]. > > I also plan to migrate 2 TeamCity Agents into Jenkins very shortly (in 30 > mins). > >

Re: [infinispan-dev] Jenkins migration

Tristan is on PTO. He'll fix DNS on Wednesday :-) On 24 Apr 2017 13:26, "Sebastian Laskawiec" wrote: > Hey! > > I uninstalled Blue Ocean plugin. I think it's worth to have another look > at it as soon as 1.1.0 is released [1]. > > I also plan to migrate 2 TeamCity Agents

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

On 24 April 2017 at 12:14, Sebastian Laskawiec wrote: > The reason the SLF4J api was shaded was that some of our dependencies used > it directly. Therefore client apps could experience > ClassNotFoundExceptions. > ​But frameworks like SLF4J don't work when shaded?​ It's

Re: [infinispan-dev] Jenkins migration

Hey! I uninstalled Blue Ocean plugin. I think it's worth to have another look at it as soon as 1.1.0 is released [1]. I also plan to migrate 2 TeamCity Agents into Jenkins very shortly (in 30 mins). @Tristan - may I ask you to redirect ci.infinispan.org to our new installation:

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

The reason the SLF4J api was shaded was that some of our dependencies used it directly. Therefore client apps could experience ClassNotFoundExceptions. As the time passed we migrated many of them to JBoss Logging so that the problem naturally went away and Ryan removed it completely. On Mon, Apr

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

Just to add, I see now that JBoss Logging is included as well. On 24 April 2017 at 11:43, Sanne Grinovero wrote: > Thanks Ryan. Beyond removing the relocation, I also doubt if it should > be included at all? I'm sincerely puzzled so I think we really need to > hear from

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

Thanks Ryan. Beyond removing the relocation, I also doubt if it should be included at all? I'm sincerely puzzled so I think we really need to hear from the others if this was intentional, or what the plan is. On 24 April 2017 at 11:40, Ryan Emerson wrote: > Previously slf4j

Re: [infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

Previously slf4j was included as a dependency in infinispan-parent, so I assume this relocation was related to that. However, [1] removed slf4j from the parent so we should be to remove this relocation as well. Unless anybody else can provide more insight, I will issue a PR removing the

[infinispan-dev] SLF4J shaded into infinispan-query-embedded ?

When inspecting the stuff included in the "shaded" jar infinispan-query-embedded, I even found a copy of SLF4J in there. It's being relocated to the package "/infinispan/org/slf4j/" Is that intentional? Does it even work in this way? I doubt it would be able to bind to the right appenders, or be

Re: [infinispan-dev] REST server, dealing with Serializable

On 24 April 2017 at 09:27, Sebastian Laskawiec wrote: > Hey Guys! > > I'm currently reworking REST interface and I'm scratching my head looking > how we deal with Serializable [1][2]. > > The scenario assumes that server knows that cache stores a Serializable > instance and

Re: [infinispan-dev] REST server, dealing with Serializable

With the upcoming transcoding support [1], each cache will have a MimeType configured for key and value. This will allow, for example, to differentiate from a byte[] that is a JPEG image, a gzipped text, some UTF-8 bytes, Jboss marshalled object, protostream marshalled message and so on. At

[infinispan-dev] REST server, dealing with Serializable

Hey Guys! I'm currently reworking REST interface and I'm scratching my head looking how we deal with Serializable [1][2]. The scenario assumes that server knows that cache stores a Serializable instance and moreover, it knows how to deserialize it (and convert it to XML/JSON, but that's the

Re: [infinispan-dev] Jenkins migration

I've heard that the default UI in Jenkins was the reason why we went with TC, and Blue Ocean was supposed to be the cure. Why was the default UI dismissed in the first place? R. On 04/23/2017 07:14 PM, Adrian Nistor wrote: > I also do not see much value in the current state of Blue Ocean. >