Le 31/05/15 18:20, Shawn McKinney a écrit : > >> On May 21, 2015, at 7:09 AM, Emmanuel Lécharny <[email protected]> wrote: >> >> Le 21/05/15 13:32, Shawn McKinney a écrit : >>>> On May 20, 2015, at 8:52 AM, Emmanuel Lécharny <[email protected]> wrote: >>>> >>>> I would say : fix whatever seems simple to fix. Low hanging fruits >>>> first, after of course critical and blocking issues. >>>> >>>> I have asked some creds to log on the tool to be able to tune some of >>>> the rules. >>>> >>>> We can discuss specific rules that seems a bit too strict, if needed. >>>> >>>> >>>> The value I see in such a tool is mainly about reviewing the code, which >>>> allows us to find some real and hidden issues, like the one on roles... >>> Most of the dependency cycles are fixed by moving the core's entities to >>> separate package. Easy to do, but breaks backward compatibility with >>> existing clients. >> Don't do that. This warning is not really useful, considering that all >> the classes are in the same project. >> >> From a OSGi PoV, this is not a problem either. > Back to the topic of package cycles in fortress core… > > Nearly every (other) issue has been fixed. All that remains are these > package cycles in the core. Agreed they aren’t really a problem. But, I can > eliminate most of the problems by moving the fortress entities to the base > package level: > > org.apache.directory.fortress.core
That would make this package containing many many classes... Not very convenient. Such cyclic dependencies are only problematic when the project is not already split in a modular way. for Fortress-core, which is an API, I don't see that as a pb.
