directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <>
Subject Re: [Fortress] Sonar...
Date Sun, 31 May 2015 16:20:57 GMT

> On May 21, 2015, at 7:09 AM, Emmanuel Lécharny <> wrote:
> Le 21/05/15 13:32, Shawn McKinney a écrit :
>>> On May 20, 2015, at 8:52 AM, Emmanuel Lécharny <> 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:

and rearranging some internally used utilities.  

Yes, it will break backward compatibility but easy to fix on client side by just changing
a few folder names.  

Because of this fact, and that we’re still early in the adoption curve of this product suite,
I recommend we go ahead and make the change now.  We can have instructions for client upgrade
in the release notes.  Perhaps we just go ahead and cut that 1.0.0 release at same time?



View raw message