David E Jones wrote:
That said, I still haven't seen how you resolved the dependency issue,
even on the security side of things. If we have an execution context
that depends on the service engine, which depends on the entity engine,
and the entity engine contains or depends on the execution context, then
we have a circular dependency. Short of combining those components onto
a single classpath we have a problem.
What I meant was I solved the cross-dependency problem in the
ExecutionContext interface itself. Anyone who tries out the branch can
see that, and they can see that the execution path aspect of it works.
That is a prerequisite to getting the new security design implemented.
With that problem instead of going in the direction of making MORE
dependencies between the framework components, I decided on a direction
to go for LESS dependencies between the framework components by using a
set of interfaces that represent the main tools in the framework and
provide the most common API elements that people might need/want.
I agree, and I'm willing to help in that effort. Again, it's not a
show-stopper for getting the security redesign implemented.
I'll continue developing the security redesign in the branch I created.
On the issue of reducing cross dependencies, why can't that be done in
the trunk? We could do it one component at a time. Doing it that way
would be fairly simple and it would be easy to test.
I saw in your commit log that you were mulling over which methods should
be kept in the interfaces, and that some methods are unnecessary. Let's
focus on the goal of eliminating cross dependencies and just allow
Eclipse to extract interfaces. Leave the decision of which methods
should or shouldn't be kept for another time.
Let's say we're working on the entity component. Just extract interfaces
from the commonly used classes, move them to framework/api, update
import statements, compile, test, commit. It seems pretty
straightforward to me.
-Adrian
