[security-dev] Dependency of idm/impl on config module

[Anil Saldhana]

I have git moved IDM tests from idm/impl and idm/schema to idm/tests.
Also now IDM impl module does not have any config module dependency.
config module depends on idm impl.

On 02/12/2013 08:34 AM, Anil Saldhana wrote:
> Unfortunately, there is a cyclic dependency between config and IDM
>
> Compile:  config depends on IDM
> Tests:  IDM depends on config
>
> Maven does not have scope (compile/test) level dependency graphs.
>
> This can be solved by pulling all the IDM tests into a subproject
> "tests"  which will be idm/tests
>
>
> On 02/11/2013 10:05 AM, Anil Saldhana wrote:
>> On 02/08/2013 03:04 PM, Shane Bryzak wrote:
>>> On 08/02/13 13:00, Marek Posolda wrote:
>>>> On 08/02/13 14:31, Shane Bryzak wrote:
>>>>> On 08/02/13 02:00, Marek Posolda wrote:
>>>>>> On 07/02/13 17:01, Shane Bryzak wrote:
>>>>>>> Oops, I didn't mean to commit that before discussing with you, it must
>>>>>>> have snuck in with some other changes that I had to make to help out
>>>>>>> Bruno with one of the Aerogear examples.  In any case, we do need to
>>>>>>> remove the dependency on the config module from idm - I'm ok with a
>>>>>>> dependency going the other way though.
>>>>>> Ok, but why we need to remove it? Is it some xml related conflict? I
>>>>>> have same problem today again. I fixed it locally in my env, but i
>>>>>> won't commit it until we sort this out.
>>>>> The most immediate problem is that it's breaking deployments - the
>>>>> config module is pulling in the federation module, which causes a
>>>>> deployment error in AS just from having the jar file present.
>>>> Hmm... actually the "config" module shouldn't be dependent on
>>>> "federation" module. Few weeks ago it was the case (and maybe you are
>>>> using older version of picketlink in aerogear), but in latest
>>>> picketlink master it's not the case anymore. Currently it should be
>>>> opposite. In other words, "config" module is currently dependent only
>>>> on "common" module and
>>>> both "federation" and "idm" modules are dependent on config module. Or
>>>> am I missing something?
>>> You're right, rebuilding the module fixed the dependency issue.
>>>
>>>>> Besides that though, the only dependency we should have in idm is on
>>>>> the common module.  Also, configuration should be able to be written
>>>>> as a totally separate concern from IDM - is there a reason that
>>>>> XMLBasedIdentityManagerProvider and all the resolver/* classes can't
>>>>> go in the config module?
>>>> I think that if we want to use XML configuration in IDM unit tests, we
>>>> need to have those XML configuration classes and classes like
>>>> XMLBasedIdentityManagerProvider accessible from idm module. Those XML
>>>> type classes also needs to be accessible from "federation" module.
>>>>
>>>> I think that deployment structure with:
>>>> - "common" module as the base module
>>>> - "config" module dependent only on "common" module
>>>> -  "federation" module dependent on "config" module (and "common" module)
>>>> - "idm" module dependent on "config" module (and "common" module)
>>>>
>>>> seems to me like most natural.
>>>>
>>>> wdyt?
>>> -1, if we want to use the config module in the tests then just make it a
>>> test-scoped dependency.  In many if not most deployments PicketLink will
>>> be used within an EE environment and the config module will be unnecessary.
>>>
>> Shane - that is even better. Marek is on PTO this week. I am going to
>> make the dependency a test scoped dep and see
>> the challenges.
>