[security-dev] PicketLink Version and "Core" Module name

[Jason Porter]

On Oct 18, 2012, at 14:09, Shane Bryzak <sbryzak at 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).