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.

On 07/02/13 05:23, Marek Posolda wrote: > Hi Shane, > > I found today that I am unable to build idm/impl module due to commented > dependency on "config" module, which is coming from your commit > "e1494891b5f906fb5e54511141ee7d661e4941b9 minor dependency fix" . To fix > this, I partially reverted it and uncomment the config module again. See > commit > https://github.com/mposolda/picketlink/commit/4ff92be99e0ed9ed8898814bddd... > in PR https://github.com/picketlink/picketlink/pull/50 (It's also adding > sorting support in FileBasedIdentityStore). > > Wdyt? Are you able to build idm/impl without dependency on config > module? On my side, I am using "mvn clean install" to build whole > project and with commented config module, it's failing for me. > > Thanks, > Marek > _______________________________________________ > 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

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.

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?

> > Thanks, > Marek >> >> On 07/02/13 05:23, Marek Posolda wrote: >>> Hi Shane, >>> >>> I found today that I am unable to build idm/impl module due to >>> commented >>> dependency on "config" module, which is coming from your commit >>> "e1494891b5f906fb5e54511141ee7d661e4941b9 minor dependency fix" . >>> To fix >>> this, I partially reverted it and uncomment the config module >>> again. See >>> commit >>> https://github.com/mposolda/picketlink/commit/4ff92be99e0ed9ed8898814bddd... >>> >>> in PR https://github.com/picketlink/picketlink/pull/50 (It's also >>> adding >>> sorting support in FileBasedIdentityStore). >>> >>> Wdyt? Are you able to build idm/impl without dependency on config >>> module? On my side, I am using "mvn clean install" to build whole >>> project and with commented config module, it's failing for me. >>> >>> Thanks, >>> Marek >>> _______________________________________________ >>> 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 >

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?

> 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?

Marek

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.

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

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