Hey all, Nearly finished up with cleaning up the compile errors - should be able to run the test-suite by this afternoon in order to make sure that there aren't any failures. I was wondering, though, whether the tests in the package org.infinispan.config.* should still be making use of the deprecated configuration API? I understand that the point of this migration is to eliminate the use of org.infinispan.config.Configuration within the test-suite, but should just these specific tests still be testing the old method? My personal opinion is that we should still have tests making use of the old API as long as it does exist in the code-base. Speaking with Tristan on IRC last week, he mentioned that the org.infinispan.config.* package is likely to be totally removed in due course. I think that until that does actually happen, we ought to have tests for that code - deprecated or not. Thoughts?

I think we should only keep the tests for the conversion between the new config and the legacy config (and the other way around), eventually add more of those. În data de 20.11.2012 09:57, "Tristan Tarrant" <ttarrant(a)redhat.com&gt; a scris: > On 11/20/2012 03:47 AM, Navin Surtani wrote: > > Hey all, > > > > Nearly finished up with cleaning up the compile errors - should be able > > to run the test-suite by this afternoon in order to make sure that there > > aren't any failures. I was wondering, though, whether the tests in the > > package org.infinispan.config.* should still be making use of the deprecated > > configuration API? I understand that the point of this migration is to > > eliminate the use of org.infinispan.config.Configuration within the > > test-suite, but should just these specific tests still be testing the old > > method? > > > > My personal opinion is that we should still have tests making use of the > > old API as long as it does exist in the code-base. Speaking with Tristan on > > IRC last week, he mentioned that the org.infinispan.config.* package is > > likely to be totally removed in due course. I think that until that does > > actually happen, we ought to have tests for that code - deprecated or not. > > > > Thoughts? > Yes, we need to keep a sufficiently diverse set of "retro" tests so that > we don't risk breaking backwards compatibility. > > Tristan > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Which would bring us to a point that Tristan made earlier. If for v 6.0, the whole org.infinispan.config.* package is going to be removed, should the code for this JIRA just be pushed on to a 6.0 branch and then I can just take my chainsaw to it directly? This way we finding the usages of the old API become a lot easier to find since there will be a lot more compilation errors. ------------------------ Navin Surtani Software Engineer JBoss SET JBoss EAP Twitter: @navssurtani ----- Original Message ----- From: "Sanne Grinovero" <sanne(a)infinispan.org&gt; To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; Sent: Wednesday, November 21, 2012 6:42:57 PM Subject: Re: [infinispan-dev] ISPN-2463: Hopefully one final question Ideally one would need tests for both versions, but that sounds like a lot of work to maintain something which is going to be removed soon. In this case I think you should avoid rewriting many tests but take advantage of the versioning system: since "old style" tests already exists no point in recoding them. Maybe it would be easier to already branch 5.2 vs. 6.0, so you can apply testsuite changes only to 6.0 while packporting as much as possible of code cleanup changes to 5.2: we'll have CI verify both on each progress step so you inherently will keep tests around for both 5.2 and 6.0, verifying the same configuration. The catch is that if you fail to backport some configuration change from master to 5.2 we might not notice introducing a backwards compatibility issue. On 21 November 2012 10:26, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > I think we should only keep the tests for the conversion between the new > config and the legacy config (and the other way around), eventually add more > of those. > > > În data de 20.11.2012 09:57, "Tristan Tarrant" <ttarrant(a)redhat.com&gt; a > scris: > >> On 11/20/2012 03:47 AM, Navin Surtani wrote: >>> Hey all, >>> >>> Nearly finished up with cleaning up the compile errors - should be able >>> to run the test-suite by this afternoon in order to make sure that there >>> aren't any failures. I was wondering, though, whether the tests in the >>> package org.infinispan.config.* should still be making use of the deprecated >>> configuration API? I understand that the point of this migration is to >>> eliminate the use of org.infinispan.config.Configuration within the >>> test-suite, but should just these specific tests still be testing the old >>> method? >>> >>> My personal opinion is that we should still have tests making use of the >>> old API as long as it does exist in the code-base. Speaking with Tristan on >>> IRC last week, he mentioned that the org.infinispan.config.* package is >>> likely to be totally removed in due course. I think that until that does >>> actually happen, we ought to have tests for that code - deprecated or not. >>> >>> Thoughts? >> Yes, we need to keep a sufficiently diverse set of "retro" tests so that >> we don't risk breaking backwards compatibility. >> >> Tristan >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Could you elaborate on what other refactoring has to be done please? I mean, specifically on the configuration side, if there's a 1-for-1 replacement in terms of the configuration that's already available then shouldn't we just be directly swapping in the other API? I get that there are some changes to the way that things would be configured, and some defaults have been changed - but there are still ways to do the same thing correct? ------------------------ Navin Surtani Software Engineer JBoss SET JBoss EAP Twitter: @navssurtani ----- Original Message ----- From: "Tristan Tarrant" <ttarrant(a)redhat.com&gt; To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; Cc: "Navin Surtani" <nsurtani(a)redhat.com&gt; Sent: Wednesday, November 21, 2012 8:56:20 PM Subject: Re: [infinispan-dev] ISPN-2463: Hopefully one final question Before applying the chainsaw, we must first decide if we're going to have a 5.3. Also 6.0 will have much more refactoring than just dropping org.infinispan.config.* so I think that should be handled first. Tristan _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev