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

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.