12:34 a.m.
a) I am presuming we have agreement that the PicketLink version for the
consolidated workspace should be v3.x
b) Regarding the module name "core" that most of us want renamed to
"cdi".
I do not see issues with it called "core" as long as PL 2.x federation
users on non-ee environments upgrading to PL3 do not have a requirement
to have CDI/Weld jars. Ideally we cannot force users to require Weld
jars to run SAML on tomcat, for example.
12:43 a.m.
--
"The measure of a man is what he does with power" - Plato
-
@abstractj
-
Volenti Nihil Difficile
On Thursday, October 18, 2012 at 12:34 PM, Anil Saldhana wrote:
a) I am presuming we have agreement that the PicketLink version for
the
consolidated workspace should be v3.x
+1 We're using picketlink-idm-restored now and I'm not comfortable with it.
We should get it merged sooner than later against the main picketlink repository.
b) Regarding the module name "core" that most of us want
renamed to "cdi".
I do not see issues with it called "core" as long as PL 2.x federation
users on non-ee environments upgrading to PL3 do not have a requirement
to have CDI/Weld jars. Ideally we cannot force users to require Weld
jars to run SAML on tomcat, for example.
I'm fine with either, we're building software, we can change if it doesn't
work.
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org)
https://lists.jboss.org/mailman/listinfo/security-dev
5:09 a.m.
On 19/10/12 01:34, Anil Saldhana wrote:
a) I am presuming we have agreement that the PicketLink version for
the
consolidated workspace should be v3.x
+1, I've gone ahead and updated the version number. On a site note,
some of the LDAPIdentityStore tests have started failing and I'm not
sure why. Anil, if you have time could you please take a look at this?
Otherwise I can delve deeper into it later today.
b) Regarding the module name "core" that most of us want
renamed to "cdi".
I do not see issues with it called "core" as long as PL 2.x federation
users on non-ee environments upgrading to PL3 do not have a requirement
to have CDI/Weld jars. Ideally we cannot force users to require Weld
jars to run SAML on tomcat, for example.
I'm -1 on renaming core to cdi. To me this seems like a ridiculous
idea, akin to Spring Security calling their core module "spring", or
Hibernate calling their core module "db". If we're going to be pushing
PicketLink as being a complete security integration framework for EE6
then it would be redundant and non-intuitive to name the core module
cdi. As for PicketLink Federation, if there is an SE requirement for it
then we can just implement it as a submodule like we've done for IDM,
and make a note in the documentation that it is possible to use it
standalone in an SE environment.
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
5:43 a.m.
On Oct 18, 2012, at 14:09, Shane Bryzak <sbryzak(a)redhat.com> wrote:
On 19/10/12 01:34, Anil Saldhana wrote:
> a) I am presuming we have agreement that the PicketLink version for the
> consolidated workspace should be v3.x
+1, I've gone ahead and updated the version number. On a site note,
some of the LDAPIdentityStore tests have started failing and I'm not
sure why. Anil, if you have time could you please take a look at this?
Otherwise I can delve deeper into it later today.
> b) Regarding the module name "core" that most of us want renamed to
"cdi".
> I do not see issues with it called "core" as long as PL 2.x federation
> users on non-ee environments upgrading to PL3 do not have a requirement
> to have CDI/Weld jars. Ideally we cannot force users to require Weld
> jars to run SAML on tomcat, for example.
I'm -1 on renaming core to cdi. To me this seems like a ridiculous
idea, akin to Spring Security calling their core module "spring", or
Hibernate calling their core module "db". If we're going to be pushing
PicketLink as being a complete security integration framework for EE6
then it would be redundant and non-intuitive to name the core module
cdi. As for PicketLink Federation, if there is an SE requirement for it
then we can just implement it as a submodule like we've done for IDM,
and make a note in the documentation that it is possible to use it
standalone in an SE environment.
+1. I think naming it cdi would be a mistake. I'm not sure how the cdi module is going
to be done, but it seems to me if things are done in an injection friendly way (minimal
usage of new being a big one) the cdi module could simply add metadata needed for cdi to
pick things up (creating annotated types, injection points, etc) and just be a cdi
extension (of course I'm not sure exactly how feasible this really is, but recoding
what's in core just to add some annotations is ridiculous).
10:39 p.m.
On 10/18/2012 03:09 PM, Shane Bryzak wrote:
On 19/10/12 01:34, Anil Saldhana wrote:
> a) I am presuming we have agreement that the PicketLink version for the
> consolidated workspace should be v3.x
+1, I've gone ahead and updated the version number. On a site note,
some of the LDAPIdentityStore tests have started failing and I'm not
sure why. Anil, if you have time could you please take a look at this?
Otherwise I can delve deeper into it later today.
Shane, can you add @Ignore to the
ldapim tests for now? I will take a
look on Mon.
> b) Regarding the module name "core" that most of us
want renamed to "cdi".
> I do not see issues with it called "core" as long as PL 2.x federation
> users on non-ee environments upgrading to PL3 do not have a requirement
> to have CDI/Weld jars. Ideally we cannot force users to require Weld
> jars to run SAML on tomcat, for example.
I'm -1 on renaming core to cdi. To me this seems like a ridiculous
idea, akin to Spring Security calling their core module "spring", or
Hibernate calling their core module "db". If we're going to be pushing
PicketLink as being a complete security integration framework for EE6
then it would be redundant and non-intuitive to name the core module
cdi. As for PicketLink Federation, if there is an SE requirement for it
then we can just implement it as a submodule like we've done for IDM,
and make a note in the documentation that it is possible to use it
standalone in an SE environment.
10:51 p.m.
Anil,
Just fixed that. Sending a PR.
Regards.
Pedro Igor
----- Original Message -----
From: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
To: security-dev(a)lists.jboss.org
Sent: Friday, October 19, 2012 10:39:28 AM
Subject: Re: [security-dev] PicketLink Version and "Core" Module name
On 10/18/2012 03:09 PM, Shane Bryzak wrote:
On 19/10/12 01:34, Anil Saldhana wrote:
> a) I am presuming we have agreement that the PicketLink version for the
> consolidated workspace should be v3.x
+1, I've gone ahead and updated the version number. On a site note,
some of the LDAPIdentityStore tests have started failing and I'm not
sure why. Anil, if you have time could you please take a look at this?
Otherwise I can delve deeper into it later today.
Shane, can you add @Ignore to the
ldapim tests for now? I will take a
look on Mon.
> b) Regarding the module name "core" that most of us
want renamed to "cdi".
> I do not see issues with it called "core" as long as PL 2.x federation
> users on non-ee environments upgrading to PL3 do not have a requirement
> to have CDI/Weld jars. Ideally we cannot force users to require Weld
> jars to run SAML on tomcat, for example.
I'm -1 on renaming core to cdi. To me this seems like a ridiculous
idea, akin to Spring Security calling their core module "spring", or
Hibernate calling their core module "db". If we're going to be pushing
PicketLink as being a complete security integration framework for EE6
then it would be redundant and non-intuitive to name the core module
cdi. As for PicketLink Federation, if there is an SE requirement for it
then we can just implement it as a submodule like we've done for IDM,
and make a note in the documentation that it is possible to use it
standalone in an SE environment.
_______________________________________________
security-dev mailing list
security-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/security-dev
11:03 p.m.
Hi Shane,
Regarding the tests failure. We have a FOSS account on CloudBees with a CI environment
for PicketLink.
Please, let me know if you want to have access.
https://picketlink.ci.cloudbees.com/
Regards.
Pedro Igor
----- Original Message -----
From: "Shane Bryzak" <sbryzak(a)redhat.com>
To: "Anil Saldhana" <Anil.Saldhana(a)redhat.com>
Cc: security-dev(a)lists.jboss.org
Sent: Thursday, October 18, 2012 5:09:15 PM
Subject: Re: [security-dev] PicketLink Version and "Core" Module name
On 19/10/12 01:34, Anil Saldhana wrote:
a) I am presuming we have agreement that the PicketLink version for
the
consolidated workspace should be v3.x
+1, I've gone ahead and updated the version number. On a site note,
some of the LDAPIdentityStore tests have started failing and I'm not
sure why. Anil, if you have time could you please take a look at this?
Otherwise I can delve deeper into it later today.
b) Regarding the module name "core" that most of us want
renamed to "cdi".
I do not see issues with it called "core" as long as PL 2.x federation
users on non-ee environments upgrading to PL3 do not have a requirement
to have CDI/Weld jars. Ideally we cannot force users to require Weld
jars to run SAML on tomcat, for example.
I'm -1 on renaming core to cdi. To me this seems like a ridiculous
idea, akin to Spring Security calling their core module "spring", or
Hibernate calling their core module "db". If we're going to be pushing
PicketLink as being a complete security integration framework for EE6
then it would be redundant and non-intuitive to name the core module
cdi. As for PicketLink Federation, if there is an SE requirement for it
then we can just implement it as a submodule like we've done for IDM,
and make a note in the documentation that it is possible to use it
standalone in an SE environment.
_______________________________________________
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
4224
days inactive
4225
days old
6 comments
5 participants
participants (5)
-
Anil Saldhana -
Bruno Oliveira -
Jason Porter -
Pedro Igor Silva -
Shane Bryzak