[security-dev] Moving DeltaSpike security to PicketLink

Anil Saldhana Anil.Saldhana at redhat.com
Wed Aug 1 10:31:15 EDT 2012

We can have a separate jira space if you desire.

Currently we have the master space for PicketLink (PLINK) and one for 
federation (PLFED).

On 08/01/2012 08:33 AM, Bruno Oliveira wrote:
> +1 picketlink-cdi would be good.
> Are you planning to create a new JIRA space? Or make use of PicketLink 
> When can we get started?
> -- 
> "The measure of a man is what he does with power" - Plato
> -
> @abstractj
> -
> Volenti Nihil Difficile
> On Monday, July 30, 2012 at 7:12 PM, Shane Bryzak wrote:
>> Except that we would have to come up with two names, one for IDM and one
>> for the CDI module (which has an equivalent amount of functionality as
>> IDM - all the ACL and permission management stuff is there). I
>> personally am starting to find all these "cool" names a bit confusing
>> and would prefer to see the project name just qualified with "IDM" or
>> "CDI", however that may just be me getting old.
>> On 31/07/12 02:31, Pete Muir wrote:
>>> Actually, I think it might add less confusion.
>>> We already saw Andy M think that "PicketLink" was in EAP, when in 
>>> fact PicketLink Federation is in EAP, and PicketLink IDM isn't.
>>> What about calling it Picket<Something>, like we have PicketLink, 
>>> PicketBox?
>>> Makes it clear it's the same family, but doesn't confuse people.
>>> On 30 Jul 2012, at 17:25, Anil Saldhana wrote:
>>>> We have had precedence in naming releases/projects with developer 
>>>> names.
>>>> (an early implementation of JBoss Mail was called Kabir).
>>>> I propose we call it "PicketLink Bolek". :)
>>>> On 07/30/2012 11:22 AM, Boleslaw Dawidowicz wrote:
>>>>> Some amount of coolness always help :) I would do he rename only 
>>>>> if we find something really fancy though.
>>>>> On Jul 30, 2012, at 6:18 PM, Anil Saldhana 
>>>>> <Anil.Saldhana at redhat.com <mailto:Anil.Saldhana at redhat.com>> wrote:
>>>>>> We should just keep it as IDM in PL github workspace and make it the
>>>>>> trunk. With new names, we will add more confusion to deciphering
>>>>>> security. ;)
>>>>>> On 07/30/2012 05:32 AM, Pete Muir wrote:
>>>>>>> Yes, however I suspect that if we ask for PicketLink XXX we 
>>>>>>> should get it through legal, as it "qualifies" the name.
>>>>>>> On 30 Jul 2012, at 11:31, Boleslaw Dawidowicz wrote:
>>>>>>>> Not a bad idea IMO. Naming will take a bit of time though as we 
>>>>>>>> first would need to vote and go via legal.
>>>>>>>> On Jul 30, 2012, at 12:23 PM, Pete Muir <pmuir at redhat.com 
>>>>>>>> <mailto:pmuir at redhat.com>> wrote:
>>>>>>>>> Or we could give this a new name entirely, unrelated to IDM 
>>>>>>>>> (like Arquillian does with Drone, Graphene etc.)
>>>>>>>>> e.g. PicketLink Atom
>>>>>>>>> Or something like that.
>>>>>>>>> This then get's around the legacy problem, the version problem 
>>>>>>>>> etc etc.
>>>>>>>>> On 30 Jul 2012, at 09:54, Shane Bryzak wrote:
>>>>>>>>>> On 30/07/12 17:18, Boleslaw Dawidowicz wrote:
>>>>>>>>>>> Hmm... What is the benefit over just starting working on 2.x 
>>>>>>>>>>> in current picketlink-idm master and leave previous 
>>>>>>>>>>> branches? I think you still have two issues:
>>>>>>>>>>> - A lot of artefacts released to maven repo. You will need 
>>>>>>>>>>> to define different artefact names to avoid collisions but 
>>>>>>>>>>> then it will still be very difficult to avoid confusion. 
>>>>>>>>>>> People already have a problem with understanding that 
>>>>>>>>>>> "PicketLink" is an umbrella project and very often refer to 
>>>>>>>>>>> either "PicketLink Federation" or "PicketLink IDM" as just 
>>>>>>>>>>> "PicketLink. If they now find both 
>>>>>>>>>>> "org.picketlink.idm:picketlink-idm-api" and 
>>>>>>>>>>> "org.picketlink.idm:api: or org:picketlink.idm:api jars with 
>>>>>>>>>>> same version it will create confusion. Then if we start from 
>>>>>>>>>>> 2.x version - I'm not sure what does it bring to rename old 
>>>>>>>>>>> repo to legacy in such scenario. you just get rid of few old 
>>>>>>>>>>> branches and tags. Btw. I branched what need to be branched 
>>>>>>>>>>> so picketlink-idm master is ready to be nuked.
>>>>>>>>>> I'm happy to do it that way, my only concern was that there 
>>>>>>>>>> will be major API breakage between the two versions hence the 
>>>>>>>>>> separation. If the current picketlink-idm is already branched 
>>>>>>>>>> and there's no problem nuking master, then we can place the 
>>>>>>>>>> new project in the same repo.
>>>>>>>>>>> - You would need to do the same with JIRA or you need to 
>>>>>>>>>>> deal with same problem. Because PicketLink IDM was only 
>>>>>>>>>>> really consumed by GateIn JIRA is a bit left behind - so 
>>>>>>>>>>> quite easy to cleanup.
>>>>>>>>>> Good point, I hadn't considered JIRA.
>>>>>>>>>>> Could you write more how would you deal with those as part 
>>>>>>>>>>> of repo renaming?
>>>>>>>>>>> Btw. I'm still holding the official "PicketLink IDM 
>>>>>>>>>>> Component Lead". Because of my GateIn/EPP duties I don't 
>>>>>>>>>>> think I will be able to spent as much time as Shane on 
>>>>>>>>>>> development - even though me and Marek Posolda will try to 
>>>>>>>>>>> help as much as possible. Therefore I think it may be better 
>>>>>>>>>>> for Shane to take over the official title as this will be 
>>>>>>>>>>> reflecting current reality anyway - no issue on my side :) I 
>>>>>>>>>>> just need to keep control of existing 1.x branches of 
>>>>>>>>>>> PicketLink IDM as this is what we still rely on in GateIn 
>>>>>>>>>>> Portal and what we ship in EPP.
>>>>>>>>>>> Bolek
>>>>>>>>>>> On Jul 30, 2012, at 4:32 AM, Shane Bryzak 
>>>>>>>>>>> <sbryzak at redhat.com <mailto:sbryzak at redhat.com>> wrote:
>>>>>>>>>>>> Hey guys,
>>>>>>>>>>>> I'm just looking at the infrastructure we have for doing 
>>>>>>>>>>>> this, currently in the PicketLink github repo [1] we have 
>>>>>>>>>>>> picketlink-idm and cdi repositories set up. I propose that 
>>>>>>>>>>>> we rename picketlink-idm to picketlink-idm-legacy to make 
>>>>>>>>>>>> way for the new picketlink-idm, and rename cdi to 
>>>>>>>>>>>> picketlink-cdi (this module will then contain all the CDI 
>>>>>>>>>>>> and DeltaSpike integration for PicketLink IDM, plus some 
>>>>>>>>>>>> authorization features such as ACLs and permission 
>>>>>>>>>>>> management). Are there any objections to this?
>>>>>>>>>>>> Shane
>>>>>>>>>>>> [1] https://github.com/picketlink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20120801/fcf7a27b/attachment-0001.html 

More information about the security-dev mailing list