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

[Marek Posolda]

On 18/02/13 20:41, Shane Bryzak wrote:
> On 18/02/13 23:41, Marek Posolda wrote:
>> On 12/02/13 15:34, 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
>> yes, cyclic dependency is what I expected. Variant with idm/tests should
>> work, but this means that "idm/impl" and "idm/api" modules will be
>> dependencies of "config" module, which will be dependency of "federation
>> module. So in the end, "idm" will be transitive dependency of
>> "federation" module, even if "idm" and "federation" are different
>> things. Is it really what we want? Or am I missing something?
> I think the idm module is always necessary, it defines the core identity
> model which the federation module *should* eventually consume anyway
> once we work some more on integration.  Any other dependencies of the
> config module (like the federation module) should be defined as optional
> in the pom.
>> My opinion is, that both "common" and "config" could be part of same AS7
>> module (like org.picketlink.commons) and other modules like "idm" and
>> "federation" could simply require only this AS7 module as their dependency.
> So are you suggesting we merge common and config?
Not full merge. I only suggested to have both common and config jars in 
same AS7 module. But I guess it's too late now as refactoring is already 
done.


Marek
>> Marek
>>
>>> 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.
>>> _______________________________________________
>>> security-dev mailing list
>>> security-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/security-dev
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev