I don't particularly mind that it doesn't get cleaned up. Theoretically if it was once reasonable for one class/package to be referenced within another, it will continue to be reasonable, even if the code no longer makes the reference.
That said, import control has been a pain every time we add or move classes/packages and I think that manual whitelisting step is more of a pain than it's worth. In its place, I say we be diligent in code reviews to check imports. tl;dr +1 On Mon, Jul 11, 2016 at 4:26 PM, Yi Pan <nickpa...@gmail.com> wrote: > +1 on removing the import control. The original idea to include the > checkstyle.xml is to enforce some coding style guidelines, not to strictly > control the imports. W/ the outdated import control list, it practically > does not serve the purpose... > > On Mon, Jul 11, 2016 at 4:02 PM, Navina Ramesh > <nram...@linkedin.com.invalid > > wrote: > > > Hi Samza devs, > > > > Lately, with the major re-works such as standalone, multithreading etc, > it > > is getting harder to keep track of the package/class dependencies in > > import-control.xml. > > > > What I have noticed is that we don't bother removing the class/package > > dependencies when it is no longer valid. This is not raised as a fault by > > the checkstyle plugin. However, this means that import-control.xml is > going > > to continuously grow without adding much value. > > > > Does anyone find this particularly useful? Should we consider removing > the > > import-control verification from checkstyle? > > > > Thanks! > > -- > > Navina R. > > >
