Hi, Would it cause any problems if FluentTypes class in FluentConfiguration was separated into a separate file? i.e. backward compatibility issues. Remember that FluentTypes is not a public interface per se, and it's not something clients would reference directly. The reason I want to change this is cos it causes all sorts of access issues when you try to use fluent configuration from Scala. If it can be problematic, no probs, I'll wait for 6.0 to separate this class into a separate file and Scala can carry on with old configuration. Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 12 October 2011 17:14, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: > Making a non-public type public preserves binary compatibility, > according to http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Achieving_API_Binary_C... I don't think that's related with Galder's question is it? Why do we need binary compatibility? I think he's referring to APIs. Anyway the classname is changing as well as it was a nested class so I don't think it's preserving binary compatibility.

Thx guys. I'll get it sorted for CR1 at the latest: https://issues.jboss.org/browse/ISPN-1452 On Oct 12, 2011, at 6:27 PM, Dan Berindei wrote: >> On 12 October 2011 17:14, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >>> Making a non-public type public preserves binary compatibility, >>> according to http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Achieving_API_Binary_C... >> >> I don't think that's related with Galder's question is it? Why do we >> need binary compatibility? I think he's referring to APIs. Anyway the >> classname is changing as well as it was a nested class so I don't >> think it's preserving binary compatibility. >> > > The FluentTypes interface is already top-level, it's just defined in > FluentConfiguration.java so it can't be public. > So making it public won't break compatibility, it won't even require > the recompilation of client classes. > > Cheers > Dan > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Even the programmatic configuration? I thought your changes were only related to XML-parsed config On Oct 12, 2011, at 9:12 PM, Pete Muir wrote: > Remember this stuff is totally redesigned in my config patch changes, so all the existing config stuff will be deprecated. > > On 12 Oct 2011, at 10:20, Galder Zamarreño wrote: > >> Thx guys. I'll get it sorted for CR1 at the latest: https://issues.jboss.org/browse/ISPN-1452 >> >> On Oct 12, 2011, at 6:27 PM, Dan Berindei wrote: >> >>>> On 12 October 2011 17:14, Dan Berindei <dan.berindei(a)gmail.com&gt; wrote: >>>>> Making a non-public type public preserves binary compatibility, >>>>> according to http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Achieving_API_Binary_C... >>>> >>>> I don't think that's related with Galder's question is it? Why do we >>>> need binary compatibility? I think he's referring to APIs. Anyway the >>>> classname is changing as well as it was a nested class so I don't >>>> think it's preserving binary compatibility. >>>> >>> >>> The FluentTypes interface is already top-level, it's just defined in >>> FluentConfiguration.java so it can't be public. >>> So making it public won't break compatibility, it won't even require >>> the recompilation of client classes. >>> >>> Cheers >>> Dan >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> >> >> _______________________________________________ >> 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 -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 14 Oct 2011, at 17:51, Pete Muir wrote: > In doing so I moved all the of the interfaces and classes to be top level. That is the stuff within FluentConfiguration? I wish Configuration would have the same fate as well: is always a PITA to browse/update subclasses in that monster.