-1 as well, as a user you only use ConfigurationBuilder and GlobalConfigurationBuilder directly, and moving them to a subpackage would make them less accessible.<br><br>If anything, I'd move these two classes to the parent package (org.infinispan.configuration), but like Sanne said there's no point in breaking the configuration again.<br>
<br><br><div class="gmail_quote">On Wed, Jun 26, 2013 at 10:02 AM, Mircea Markus <span dir="ltr"><<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 26 Jun 2013, at 09:54, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br>
<br>
> Please don't break the configuration API again :-(<br>
><br>
> On 26 June 2013 06:29, Navin Surtani <<a href="mailto:nsurtani@redhat.com">nsurtani@redhat.com</a>> wrote:<br>
>> While working through ISPN-2463, and the sub-tasks I was wondering about the<br>
>> organisation of the ConfigurationBuilder classes.<br>
>><br>
>> Currently, they are located in org.infinispan.configuration.cache.etc or<br>
>> org.infinispan.configuration.global.etc. The actual Configuration classes<br>
>> are within the same package already as well. To me, this sounds a little bit<br>
>> cluttered and perhaps not very intuitive and I was wondering if it might be<br>
>> a better idea to have something like:<br>
>><br>
>> org.infinispan.configuration.cache.builders.ConfigurationBuilder (and<br>
>> others)<br>
>> org.infinispan.configuration.global.builders.GlobalConfigurationBuilder (etc<br>
>> etc)<br>
>><br>
>> Another suggestion could be:<br>
>><br>
>> org.infinispan.configuration.builders.cache.etc<br>
>> org.infinispan.configuration.builders.glocal.etc<br>
>><br>
>> The only problem with that would be breaking backward compatibility, but<br>
>> from ISPN 6.x onwards I think that there are a fair few classes and packages<br>
>> being moved around anyway. It's just an idea that might make the API seem a<br>
>> little bit cleaner as to where it's located.<br>
>><br>
>> Thoughts?<br>
<br>
</div>Indeed sounds is a good suggestion but as Sanne mentioned this would break the backward compatibility which is something we want to avoid.<br>
<br>
Cheers,<br>
<span class="HOEnZb"><font color="#888888">--<br>
Mircea Markus<br>
Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br>