Re: [uportal-dev] not equal in pags
Thanks, Eric. We already have the AttributeExists and NoValues testers. I will include the NegatedStringTester. Dan Eric Dalquist wrote: https://mywebspace.wisc.edu/dalquist/web/JA-SIG/patches/pags/ There are some custom testers we wrote here @ UW. I believe the NegatedStringTester is what you want. Dan, Feel free to include these in the stand-alone GAPS package. -Eric Dan Ellentuck wrote: Hi Tim, I played around a little and came up with this ugly thing, which I'm sure can be improved by someone who knows what they're doing with regular expressions. ^guest.+$|^.+guest$|^[^g].*$|^g[^u].*$|^gu[^e].*$|^gue[^s].*$|^gues[^t].*$|^g$|^gu$|^gue$|^gues$ But you've made your point. No one should have to code something like this to do String NOT EQUALS. I will add a string not equals tester to the pags tester package and also post the code in jira. Give me a day or two. Dan Timothy Carroll wrote: I'm no REGEX guru, but I enlisted one locally. Neither of us could figure out a way to resolve the example case I documented. Would you mind sharing how you would accomplish this using the example? Thanks, Tim On Apr 14, 2008, at 1:04 PM, Dan Ellentuck wrote: Hi Tim, You can do most anything with Strings out of the box with the RegexTester, including testing an attribute for NOT EQUALS. Dan Timothy Carroll wrote: Hi All. Is anyone aware of an easy way to accomplish a NOT EQUAL operation in PAGS. Basically, we have a personDirectory attribute setup, and we want to create a PAGS group that evaluates membership based on that attribute being NOT EQUAL to a specific string. An example would be: A user is a member of "Authenticated Users" when attribute "username" is not equal to "guest" So far as I can tell, this is not really possible with PAGS out of the box. However, it seems like a perfectly reasonable thing to do, so I'm hoping someone has overcome this hurdle already. Thanks in advance, Tim -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html Subscribe to the conference blog, The Community Source Way http://jasig2008.blogspot.com, for news and updates about the event. Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] not equal in pags
Hi Tim, I played around a little and came up with this ugly thing, which I'm sure can be improved by someone who knows what they're doing with regular expressions. ^guest.+$|^.+guest$|^[^g].*$|^g[^u].*$|^gu[^e].*$|^gue[^s].*$|^gues[^t].*$|^g$|^gu$|^gue$|^gues$ But you've made your point. No one should have to code something like this to do String NOT EQUALS. I will add a string not equals tester to the pags tester package and also post the code in jira. Give me a day or two. Dan Timothy Carroll wrote: I'm no REGEX guru, but I enlisted one locally. Neither of us could figure out a way to resolve the example case I documented. Would you mind sharing how you would accomplish this using the example? Thanks, Tim On Apr 14, 2008, at 1:04 PM, Dan Ellentuck wrote: Hi Tim, You can do most anything with Strings out of the box with the RegexTester, including testing an attribute for NOT EQUALS. Dan Timothy Carroll wrote: Hi All. Is anyone aware of an easy way to accomplish a NOT EQUAL operation in PAGS. Basically, we have a personDirectory attribute setup, and we want to create a PAGS group that evaluates membership based on that attribute being NOT EQUAL to a specific string. An example would be: A user is a member of "Authenticated Users" when attribute "username" is not equal to "guest" So far as I can tell, this is not really possible with PAGS out of the box. However, it seems like a perfectly reasonable thing to do, so I'm hoping someone has overcome this hurdle already. Thanks in advance, Tim -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html Subscribe to the conference blog, The Community Source Way http://jasig2008.blogspot.com, for news and updates about the event. Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] not equal in pags
Hi Tim, You can do most anything with Strings out of the box with the RegexTester, including testing an attribute for NOT EQUALS. Dan Timothy Carroll wrote: Hi All. Is anyone aware of an easy way to accomplish a NOT EQUAL operation in PAGS. Basically, we have a personDirectory attribute setup, and we want to create a PAGS group that evaluates membership based on that attribute being NOT EQUAL to a specific string. An example would be: A user is a member of "Authenticated Users" when attribute "username" is not equal to "guest" So far as I can tell, this is not really possible with PAGS out of the box. However, it seems like a perfectly reasonable thing to do, so I'm hoping someone has overcome this hurdle already. Thanks in advance, Tim -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html Subscribe to the conference blog, The Community Source Way http://jasig2008.blogspot.com, for news and updates about the event. Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] data.xml & entity cleanup
Hi Eric, et. al., I also think #1 is the better option, but the heart of the matter is what is meant by, "...just using well known names." This question boils down to what's the best way to enforce a single namespace for group aliases. You can search for a group by name, but as we know, unique names are not required or enforced. Or you can declaratively alias a group or groups to a particular symbolic name. In the composite group service bean in spun-off gap there is a Map of symbolic names and their related group keys: local.0 local.0 local.1 These symbolic (or "DISTINGUISHED") names are different from the names returned by IEntityGroup.getName(). Eric Dalquist wrote: Thanks for the update. I have a few ideas for getting rid of the explicit configuration tie to the synthetic group IDs. 1. Switch to just using well known names. An example would be "All uPortal Users" for everyone, "All uPortal Channels" for all channels and "uPortal Administrators" for admins. Some effort would need to be done in the composite group store to prevent these groups from being created by users for security reasons which may be a bit of a road block. 2. Move the config into the database. A table could contain a known real id and the corresponding synthetic id of the designated group. This information could more easily be exported and would reduce the configuration tie to specific group keys. Thoughts from any devs out there? -Eric Drew Wills wrote: Eric, I updated dbunload,crn per our discussion on IRC: http://developer.ja-sig.org/source/changelog/jasigsvn/?cs=43464 It still needs some attention, though... There are 3 rows defined in the UP_GROUP.default-data.xml file, each of which refers to an EntityType by Id: IPerson or IChannel. We either need to include a .default-data.xml file that defines these dependencies, or remove the need for 'Everyone', 'Portal Administrators', and 'All Channels' to have specific Ids. drew -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html Subscribe to the conference blog, The Community Source Way http://jasig2008.blogspot.com, for news and updates about the event. Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] data.xml & entity cleanup
Sorry, I hit send by accident before I was done. Hi Eric, et. al., I think this question boils down to what's the best way to enforce a single namespace for group aliases. You can search for a group by name, but as we know, unique names are not required or enforced. Or you can declaratively alias a group or groups to a particular symbolic name. In the composite group service bean in spun-off gap there is a Map of symbolic names and their related group keys: local.0 local.0 local.1 These symbolic (or "DISTINGUISHED") names are different from the names returned by IEntityGroup.getName(). If it makes sense, we could backport something like this to earlier versions of GaP in uPortal. Dan Eric Dalquist wrote: Thanks for the update. I have a few ideas for getting rid of the explicit configuration tie to the synthetic group IDs. 1. Switch to just using well known names. An example would be "All uPortal Users" for everyone, "All uPortal Channels" for all channels and "uPortal Administrators" for admins. Some effort would need to be done in the composite group store to prevent these groups from being created by users for security reasons which may be a bit of a road block. 2. Move the config into the database. A table could contain a known real id and the corresponding synthetic id of the designated group. This information could more easily be exported and would reduce the configuration tie to specific group keys. Thoughts from any devs out there? -Eric Drew Wills wrote: Eric, I updated dbunload,crn per our discussion on IRC: http://developer.ja-sig.org/source/changelog/jasigsvn/?cs=43464 It still needs some attention, though... There are 3 rows defined in the UP_GROUP.default-data.xml file, each of which refers to an EntityType by Id: IPerson or IChannel. We either need to include a .default-data.xml file that defines these dependencies, or remove the need for 'Everyone', 'Portal Administrators', and 'All Channels' to have specific Ids. drew -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html Subscribe to the conference blog, The Community Source Way http://jasig2008.blogspot.com, for news and updates about the event. Join the Conference networking site at http://ja-sigspring08.crowdvine.com/ You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [gaps-dev] [uportal-dev] maven project structure for GAP
Hi Eric, Thanks for doing those changes. I think you're right about org.jasig.gap.db not being appropriate for the gap api, and I'll move it to the impl module. I'm less sure about the org.jasig.gap.services.sequence package and the other non-core interfaces. I've thought of the api module as not merely being for GAP clients but also for developers who may want to write alternate implementations of the impl packages. Let me think on it a bit. We could certainly move the gap-uportal2 code back into the uPortal project, though I was thinking of it as a temporary expedient rather than something that we want to maintain long-term. The custom jar packaging in the gap-impl module was just a stab I took at coming up with substitutable units of code that someone might want to re-implement. I'm not really sure if creating more modules is helpful or just complicating. I'd rather hold off on it for now. I think creating a branch for the gap integration work is a good idea. Dan Eric Dalquist wrote: Dan, I just committed my changes to the GAP poms. I updated them to follow more what other JASIG projects are doing by declaring artifact versions in a block in the parent pom and then referring to those in the child poms when declaring dependencies. I also removed a bunch of meta-data that was duplicated from the jasig-parent pom and between the poms in the project which should help make maintenance easier. I did have a few questions about other ideas for the project. -Do the org.jasig.gap.db and org.jasig.gap.services.sequence packages need to be in the gap-api module? I'm not sure these (and there may be some others) are things that would want to be exposed to some code that is a client of GAP. -When we actually start integrating this code back into uPortal perhaps we should look at moving the gap-uportal2-impl code into the uPortal project. It seems that this is a bit out of the scope of GAP and could be nice for GAP development to not have to worry about it where as it is under the scope of uPortal especially in the view of adopting the stand-alone GAP project. -What is the intent of doing the custom jar packaging with Ant in the gap-impl module? If the goal is to split those into further sub-modules that shouldn't be too difficult (as long as there aren't any cycles in the code). -Eric PS: Note that this is to gaps-dev and uportal-dev is just CCd on it. Perhaps those interested in following the conversation can subcribe on gaps-dev. Eric Dalquist wrote: Sounds good, I'll let you know when I get it in. As for the uPortal integration work, should we create a branch for you? We aren't going to want to commit any GAP related changes until after the 3.0 GA release. -Eric Dan Ellentuck wrote: Hi Eric, That sounds fine. Why don't you just commit those changes. I'm starting now on the actual integration work and will keep you posted. As much as possible, the first round will involve subtracting gap classes from uportal-impl and using instead the gap-uportal2 api. This will not be possible in all cases, so I will have to change some code in uportal-impl that refers to gap classes other than those in o.j.p.services. Dan Eric Dalquist wrote: Dan, I just pulled the code and the restructuring looks good. I have a few suggestions around the organization of the POMs, namely moving the dependency declarations to the child POMs and just declaring dependency versions in the parent pom. Is it ok if I just make the changes and commit or would you like me to post a patch to run by you first? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've committed the restructured, mavenized gap project, divided into modules for gap-api, gap-impl and gap-uPortal2-api. The next step is integration with up3. If you want to build it in eclipse with the maven plugin, I've found the quickest way is to check out the gap project from the trunk, and from the project context menu: Maven -> Enable Nested Modules Maven -> Update Source Folders It should now be possible to build via maven from within eclipse, as well as compile and debug individual classes. Dan Eric Dalquist wrote: Sounds good! I hope I can find time to take a peak soon :) -Eric Dan Ellentuck wrote: Hi Eric, Thanks, the builds are working fine now. I figured I would tag the current gap_trunk "pre-divide-into-modules-20080305" or something like that, since I'm the only one working presently in this project, and then commit the changes on the trunk. Dan Eric Dalquist wrote: When you're working on the project locally maven should automatically resolve that dependency to the other gap-api project module. If you're trying to run mvn commands on the specific modules you may have to run 'mvn install' on the gap-api module first. This will move th
Re: [uportal-dev] maven project structure for GAP
Hi Eric, That sounds fine. Why don't you just commit those changes. I'm starting now on the actual integration work and will keep you posted. As much as possible, the first round will involve subtracting gap classes from uportal-impl and using instead the gap-uportal2 api. This will not be possible in all cases, so I will have to change some code in uportal-impl that refers to gap classes other than those in o.j.p.services. Dan Eric Dalquist wrote: Dan, I just pulled the code and the restructuring looks good. I have a few suggestions around the organization of the POMs, namely moving the dependency declarations to the child POMs and just declaring dependency versions in the parent pom. Is it ok if I just make the changes and commit or would you like me to post a patch to run by you first? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've committed the restructured, mavenized gap project, divided into modules for gap-api, gap-impl and gap-uPortal2-api. The next step is integration with up3. If you want to build it in eclipse with the maven plugin, I've found the quickest way is to check out the gap project from the trunk, and from the project context menu: Maven -> Enable Nested Modules Maven -> Update Source Folders It should now be possible to build via maven from within eclipse, as well as compile and debug individual classes. Dan Eric Dalquist wrote: Sounds good! I hope I can find time to take a peak soon :) -Eric Dan Ellentuck wrote: Hi Eric, Thanks, the builds are working fine now. I figured I would tag the current gap_trunk "pre-divide-into-modules-20080305" or something like that, since I'm the only one working presently in this project, and then commit the changes on the trunk. Dan Eric Dalquist wrote: When you're working on the project locally maven should automatically resolve that dependency to the other gap-api project module. If you're trying to run mvn commands on the specific modules you may have to run 'mvn install' on the gap-api module first. This will move that artifact into your local repository on your machine. Any mvn commands you run from the root of the project should work without any of the gap artifacts in your local repository. -Eric Dan Ellentuck wrote: Hi Eric, Both the gap-impl and gap-uportal2-api projects need the gap-api. Should this just be handled locally in all cases? Dan Eric Dalquist wrote: This sounds great, I'll see if I can find some time this week to take a look at it. The GAP project should be locally build-able without adding anything to a central repository. -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've divided the gap project into the structure Eric describes in his email. This turned out to be good for reasons beyond just following convention, since it forced a code cleanup that I think better emphasizes the difference between api and impl. Eric, I'm looking now at what you've done with person-directory and thinking I should go ahead and follow this model, i.e., alter the trunk so that it contains a parent and 3 child projects, and declare a module in the parent pom for each one. In order to make the projects build-able, I have to install the gap-api jar into the jasig maven repository. How do I go about doing this? Thanks, Dan Eric Dalquist wrote: Any thoughts on these suggestions Dan? -Eric Eric Dalquist wrote: I'd actually like to suggest a 3rd arrangement. The maven project structure I think would work best initially would be: gap-parent +-gap-api +-gap-impl +-gap-uPortal2-api I'm actually working on doing the api/impl split on person directory right now and I think that will open up some more options for making these services available to portlets and other applications. For GAP the -api module would contain all of the public APIs a GAPs client would need to use to access the system. Hopefully it would completely or mostly be interfaces and all of the implementation code and group service code ends up in -impl. I can provide some direct help doing this via the IRC channel, do you have a branch in SVN where this work is happening? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-proje
Re: [uportal-dev] maven project structure for GAP
Hi Eric, et. al., I've committed the restructured, mavenized gap project, divided into modules for gap-api, gap-impl and gap-uPortal2-api. The next step is integration with up3. If you want to build it in eclipse with the maven plugin, I've found the quickest way is to check out the gap project from the trunk, and from the project context menu: Maven -> Enable Nested Modules Maven -> Update Source Folders It should now be possible to build via maven from within eclipse, as well as compile and debug individual classes. Dan Eric Dalquist wrote: Sounds good! I hope I can find time to take a peak soon :) -Eric Dan Ellentuck wrote: Hi Eric, Thanks, the builds are working fine now. I figured I would tag the current gap_trunk "pre-divide-into-modules-20080305" or something like that, since I'm the only one working presently in this project, and then commit the changes on the trunk. Dan Eric Dalquist wrote: When you're working on the project locally maven should automatically resolve that dependency to the other gap-api project module. If you're trying to run mvn commands on the specific modules you may have to run 'mvn install' on the gap-api module first. This will move that artifact into your local repository on your machine. Any mvn commands you run from the root of the project should work without any of the gap artifacts in your local repository. -Eric Dan Ellentuck wrote: Hi Eric, Both the gap-impl and gap-uportal2-api projects need the gap-api. Should this just be handled locally in all cases? Dan Eric Dalquist wrote: This sounds great, I'll see if I can find some time this week to take a look at it. The GAP project should be locally build-able without adding anything to a central repository. -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've divided the gap project into the structure Eric describes in his email. This turned out to be good for reasons beyond just following convention, since it forced a code cleanup that I think better emphasizes the difference between api and impl. Eric, I'm looking now at what you've done with person-directory and thinking I should go ahead and follow this model, i.e., alter the trunk so that it contains a parent and 3 child projects, and declare a module in the parent pom for each one. In order to make the projects build-able, I have to install the gap-api jar into the jasig maven repository. How do I go about doing this? Thanks, Dan Eric Dalquist wrote: Any thoughts on these suggestions Dan? -Eric Eric Dalquist wrote: I'd actually like to suggest a 3rd arrangement. The maven project structure I think would work best initially would be: gap-parent +-gap-api +-gap-impl +-gap-uPortal2-api I'm actually working on doing the api/impl split on person directory right now and I think that will open up some more options for making these services available to portlets and other applications. For GAP the -api module would contain all of the public APIs a GAPs client would need to use to access the system. Hopefully it would completely or mostly be interfaces and all of the implementation code and group service code ends up in -impl. I can provide some direct help doing this via the IRC channel, do you have a branch in SVN where this work is happening? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-projects removes the uPortal2 dependency from GAP, and this seems desirable. Thanks for your help, Dan -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] maven project structure for GAP
Hi Eric, Thanks, the builds are working fine now. I figured I would tag the current gap_trunk "pre-divide-into-modules-20080305" or something like that, since I'm the only one working presently in this project, and then commit the changes on the trunk. Dan Eric Dalquist wrote: When you're working on the project locally maven should automatically resolve that dependency to the other gap-api project module. If you're trying to run mvn commands on the specific modules you may have to run 'mvn install' on the gap-api module first. This will move that artifact into your local repository on your machine. Any mvn commands you run from the root of the project should work without any of the gap artifacts in your local repository. -Eric Dan Ellentuck wrote: Hi Eric, Both the gap-impl and gap-uportal2-api projects need the gap-api. Should this just be handled locally in all cases? Dan Eric Dalquist wrote: This sounds great, I'll see if I can find some time this week to take a look at it. The GAP project should be locally build-able without adding anything to a central repository. -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've divided the gap project into the structure Eric describes in his email. This turned out to be good for reasons beyond just following convention, since it forced a code cleanup that I think better emphasizes the difference between api and impl. Eric, I'm looking now at what you've done with person-directory and thinking I should go ahead and follow this model, i.e., alter the trunk so that it contains a parent and 3 child projects, and declare a module in the parent pom for each one. In order to make the projects build-able, I have to install the gap-api jar into the jasig maven repository. How do I go about doing this? Thanks, Dan Eric Dalquist wrote: Any thoughts on these suggestions Dan? -Eric Eric Dalquist wrote: I'd actually like to suggest a 3rd arrangement. The maven project structure I think would work best initially would be: gap-parent +-gap-api +-gap-impl +-gap-uPortal2-api I'm actually working on doing the api/impl split on person directory right now and I think that will open up some more options for making these services available to portlets and other applications. For GAP the -api module would contain all of the public APIs a GAPs client would need to use to access the system. Hopefully it would completely or mostly be interfaces and all of the implementation code and group service code ends up in -impl. I can provide some direct help doing this via the IRC channel, do you have a branch in SVN where this work is happening? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-projects removes the uPortal2 dependency from GAP, and this seems desirable. Thanks for your help, Dan -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] maven project structure for GAP
Yes, that was the question I was asking, whether we want to have local developers do a mvn install when they are working on a specific module. I'll document this. Dan Eric Dalquist wrote: When you're working on the project locally maven should automatically resolve that dependency to the other gap-api project module. If you're trying to run mvn commands on the specific modules you may have to run 'mvn install' on the gap-api module first. This will move that artifact into your local repository on your machine. Any mvn commands you run from the root of the project should work without any of the gap artifacts in your local repository. -Eric Dan Ellentuck wrote: Hi Eric, Both the gap-impl and gap-uportal2-api projects need the gap-api. Should this just be handled locally in all cases? Dan Eric Dalquist wrote: This sounds great, I'll see if I can find some time this week to take a look at it. The GAP project should be locally build-able without adding anything to a central repository. -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've divided the gap project into the structure Eric describes in his email. This turned out to be good for reasons beyond just following convention, since it forced a code cleanup that I think better emphasizes the difference between api and impl. Eric, I'm looking now at what you've done with person-directory and thinking I should go ahead and follow this model, i.e., alter the trunk so that it contains a parent and 3 child projects, and declare a module in the parent pom for each one. In order to make the projects build-able, I have to install the gap-api jar into the jasig maven repository. How do I go about doing this? Thanks, Dan Eric Dalquist wrote: Any thoughts on these suggestions Dan? -Eric Eric Dalquist wrote: I'd actually like to suggest a 3rd arrangement. The maven project structure I think would work best initially would be: gap-parent +-gap-api +-gap-impl +-gap-uPortal2-api I'm actually working on doing the api/impl split on person directory right now and I think that will open up some more options for making these services available to portlets and other applications. For GAP the -api module would contain all of the public APIs a GAPs client would need to use to access the system. Hopefully it would completely or mostly be interfaces and all of the implementation code and group service code ends up in -impl. I can provide some direct help doing this via the IRC channel, do you have a branch in SVN where this work is happening? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-projects removes the uPortal2 dependency from GAP, and this seems desirable. Thanks for your help, Dan -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] maven project structure for GAP
Hi Eric, Both the gap-impl and gap-uportal2-api projects need the gap-api. Should this just be handled locally in all cases? Dan Eric Dalquist wrote: This sounds great, I'll see if I can find some time this week to take a look at it. The GAP project should be locally build-able without adding anything to a central repository. -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've divided the gap project into the structure Eric describes in his email. This turned out to be good for reasons beyond just following convention, since it forced a code cleanup that I think better emphasizes the difference between api and impl. Eric, I'm looking now at what you've done with person-directory and thinking I should go ahead and follow this model, i.e., alter the trunk so that it contains a parent and 3 child projects, and declare a module in the parent pom for each one. In order to make the projects build-able, I have to install the gap-api jar into the jasig maven repository. How do I go about doing this? Thanks, Dan Eric Dalquist wrote: Any thoughts on these suggestions Dan? -Eric Eric Dalquist wrote: I'd actually like to suggest a 3rd arrangement. The maven project structure I think would work best initially would be: gap-parent +-gap-api +-gap-impl +-gap-uPortal2-api I'm actually working on doing the api/impl split on person directory right now and I think that will open up some more options for making these services available to portlets and other applications. For GAP the -api module would contain all of the public APIs a GAPs client would need to use to access the system. Hopefully it would completely or mostly be interfaces and all of the implementation code and group service code ends up in -impl. I can provide some direct help doing this via the IRC channel, do you have a branch in SVN where this work is happening? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-projects removes the uPortal2 dependency from GAP, and this seems desirable. Thanks for your help, Dan -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] maven project structure for GAP
Hi Eric, et. al., I've divided the gap project into the structure Eric describes in his email. This turned out to be good for reasons beyond just following convention, since it forced a code cleanup that I think better emphasizes the difference between api and impl. Eric, I'm looking now at what you've done with person-directory and thinking I should go ahead and follow this model, i.e., alter the trunk so that it contains a parent and 3 child projects, and declare a module in the parent pom for each one. In order to make the projects build-able, I have to install the gap-api jar into the jasig maven repository. How do I go about doing this? Thanks, Dan Eric Dalquist wrote: Any thoughts on these suggestions Dan? -Eric Eric Dalquist wrote: I'd actually like to suggest a 3rd arrangement. The maven project structure I think would work best initially would be: gap-parent +-gap-api +-gap-impl +-gap-uPortal2-api I'm actually working on doing the api/impl split on person directory right now and I think that will open up some more options for making these services available to portlets and other applications. For GAP the -api module would contain all of the public APIs a GAPs client would need to use to access the system. Hopefully it would completely or mostly be interfaces and all of the implementation code and group service code ends up in -impl. I can provide some direct help doing this via the IRC channel, do you have a branch in SVN where this work is happening? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-projects removes the uPortal2 dependency from GAP, and this seems desirable. Thanks for your help, Dan -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] maven project structure for GAP
Hi Eric, I like your idea and will be working with it the next few days. Up to this point, I've just been working locally. Dan Eric Dalquist wrote: Any thoughts on these suggestions Dan? -Eric Eric Dalquist wrote: I'd actually like to suggest a 3rd arrangement. The maven project structure I think would work best initially would be: gap-parent +-gap-api +-gap-impl +-gap-uPortal2-api I'm actually working on doing the api/impl split on person directory right now and I think that will open up some more options for making these services available to portlets and other applications. For GAP the -api module would contain all of the public APIs a GAPs client would need to use to access the system. Hopefully it would completely or mostly be interfaces and all of the implementation code and group service code ends up in -impl. I can provide some direct help doing this via the IRC channel, do you have a branch in SVN where this work is happening? -Eric Dan Ellentuck wrote: Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-projects removes the uPortal2 dependency from GAP, and this seems desirable. Thanks for your help, Dan -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] maven project structure for GAP
Hi Eric, et. al., I've spent quite a few hours experimenting with various maven project structures for GAP and have come up with 2 options: . a single project containing all the code, with a custom packaging phase to create the individual jars we want: gap-full.jar (does not contain uportal2 api) gap-common.jar gap-groupsCore.jar gap-groupServices.jar gap-permissions.jar gap-uportal2-api.jar . a parent project with 2 sub-projects, one for all of the org.jasig.gap code (with a custom packaging phase) and one for the uPortal2 api: gap gap-core gap-uPortal2-api I'd like your opinion. I suspect that a single project is clearest and easiest to work with, but using a parent project with 2 sub-projects removes the uPortal2 dependency from GAP, and this seems desirable. Thanks for your help, Dan -- Join your friends and colleagues at JA-SIG 2008 - "Higher Education Solutions: The Community Source Way!" April 27th - 30th, 2008 in St. Paul, Minnesota USA Featuring CAS, DSpace, Fedora, Fluid, Internet2, Kuali, Sakai, uPortal, and more! Information/Registration at: http://www.ja-sig.org/conferences/08spring/index.html You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] GaP & uP3
Hi Eric, The initial work involved is: 1. doing a maven build process that creates .jars for the various sub-projects that we want to divide GaP into; 2. making the jars available to uPortal3; 3. removing the GaP packages and service facades from uPortal3. 4. building uPortal3 with the GaP libraries, including the gap_uPortal2_api and working out configuration issues. And then, 5. over time, removing references to the uPortal GaP classes and replacing them with references to the standalone GaP classes. I'd like to put in time this week and next on I've put in some time on the maven build on this, since it should be pretty slow around here. I don't think this is a great deal of work. Dan Eric Dalquist wrote: Dan, At the unconference we had talked about about moving to the stand-alone GaP code for uPortal 3. I can't remember much beyond that, is this something you have looked into at all and what are your views on the amount of work involved? -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Deprecated code removal (IMultithreaded*)
Hi Eric, I'd rather see the multithreaded code deprecated, since whatever the advantages of removing it, it raises the cost of migration for quite a few current implementors. I've written a couple of multithreaded channels for local use at Columbia, at least one of which is still running. If I remember correctly, some of the Announcements channel variants are IMultithreadedChannels. Dan Eric Dalquist wrote: With the basic Spring re-org done the next task on the block is reviewing and removing deprecated code from the framework. There is a Jira issue http://www.ja-sig.org/issues/browse/UP-1832 of course and you can peak at the Fisheye tab to see what has been done so far. One large set of files that is deprecated is everything related to multithreaded channels. I would like to get opinions of people on if this code should be out-right removed for a uPortal 3.0 release or is it ok to remain in the codebase but be deprecated? Thank you, -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] uPortal Project Steering Committee
+1 Eric and Andrew -- the best. Dan Ellentuck -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Custom group store question
Hi Eric,
The default IEntityGroup implementation,
o.j.p.groups.EntityGroupImpl, caches its member keys. As a
result, once an EntityGroupImpl leaks out of an
externally-managed service, it is vulnerable to becoming out
of sync with its store. I think the easiest approach is to
extend EntityGroupImpl to delegate member queries
(contains(), getMemberEntities() and getMemberGroups()) to
the local group service and have your group store
instantiate instances of this class. I'm attaching an
example of this approach.
Dan
Eric Dalquist wrote:
> I'm writing a JDBC based group store to go against a set of tables with
> group information maintained by another group. I have everything working
> but can't figure out some of the caching issues. Data will be added and
> removed from the tables by an external process. The service is
> configured as externally managed and has caching disabled. Even so I get
> failures (null pointers) in groups manager if groups or members are
> removed from the DB and groups/members that are added don't show up
> until the portal is restarted.
>
> Any help configuring this would be much appreciated.
>
> -Eric
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev/* Copyright 2004 The JA-SIG Collaborative. All rights reserved.
* See license distributed with this file and
* available online at http://www.uportal.org/license.html
*/
package edu.columbia.ais.portal.groups;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;
import org.jasig.portal.groups.EntityGroupImpl;
import org.jasig.portal.groups.GroupsException;
import org.jasig.portal.groups.IEntityGroup;
import org.jasig.portal.groups.IGroupMember;
/**
* @author Dan Ellentuck
* @version $Revision$
* @see org.jasig.portal.groups.IEntityGroup
*
* An [EMAIL PROTECTED] IEntityGroup} that delegates member queries
(contains(),
* getMemberEntities() and getMemberGroups()) to the local group store.
*/
public class SqlGroupImpl extends EntityGroupImpl implements IEntityGroup {
/**
* @param groupKey
* @param entityType
* @throws GroupsException
*/
public SqlGroupImpl(String groupKey, Class entityType) throws
GroupsException {
super(groupKey, entityType);
}
/**
* Checks if GroupMember gm is a member of this.
* @return boolean
* @param gm org.jasig.portal.groups.IGroupMember
*/
public boolean contains(IGroupMember gm) throws GroupsException
{
return getLocalGroupService().contains(this,gm);
}
/**
* Returns an Iterator over the entities in our member
* Collection.
* @return java.util.Iterator
*/
protected java.util.Iterator getMemberEntities() throws GroupsException
{
List memberEntities = new ArrayList();
for ( Iterator itr=getMembers(); itr.hasNext(); )
{
IGroupMember member = (IGroupMember) itr.next();
if ( member.isEntity() )
{ memberEntities.add(member); }
}
return memberEntities.iterator();
}
/**
* Returns an Iterator over the entities in our member
* Collection.
* @return java.util.Iterator
*/
protected java.util.Iterator getMemberGroups() throws GroupsException
{
List memberGroups = new ArrayList();
for ( Iterator itr=getMembers(); itr.hasNext(); )
{
IGroupMember member = (IGroupMember) itr.next();
if ( member.isGroup() )
{ memberGroups.add(member); }
}
return memberGroups.iterator();
}
/**
* Returns an Iterator over the GroupMembers in
our
* member Collection.
* @return java.util.Iterator
*/
public java.util.Iterator getMembers() throws GroupsException
{
return getLocalGroupService().findMembers(this);
}
}
