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

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?

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