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

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(a)redhat.com&gt; 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 >> _______________________________________________ >> 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

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(a)redhat.com&gt; 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(a)redhat.com&gt; 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 >>>> _______________________________________________ >>>> 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 >

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

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

PicketEgo On 30 Jul 2012, at 17: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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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 >>>>>>>>>> >>>>>>>>>>

I think he pulled your leg ;-) But yeah, the primary association of the word picket in Britain is a "picket line", which is what people who are striking create, in order to stop others entering the place of work. I don't think it's offensive. On 30 Jul 2012, at 17:39, Anil Saldhana wrote: > Mark Proctor told me once that Picket* is kind of offensive or such in Britain, for the use of Pickets mostly in riots or uprising associations. Not sure how true. :) > > On 07/30/2012 11:33 AM, Pete Muir wrote: >> PicketEgo >> >> On 30 Jul 2012, at 17: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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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(a)redhat.com (mailto:Anil.Saldhana@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(a)redhat.com (mailto:pmuir@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(a)redhat.com (mailto:sbryzak@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 > > _______________________________________________ > > security-dev mailing list > > security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) > > https://lists.jboss.org/mailman/listinfo/security-dev > > > > > _______________________________________________ > security-dev mailing list > security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) > https://lists.jboss.org/mailman/listinfo/security-dev > _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org (mailto:security-dev@lists.jboss.org) https://lists.jboss.org/mailman/listinfo/security-dev