[uportal-dev] Jasig Newsletter - Call for Content
Hi Everyone, If you have any items of interest to the Jasig community and would like them to appear in the December edition of the Jasig Newsletter, please submit them via email to newsletter at jasig dot org (by Monday, December 20th). Your contributions would be greatly appreciated. Thanks, Mark Rogers (University of Manitoba) Editor, Jasig Newsletter mrogers at live dot ca -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
[uportal-dev] [Bamboo] uPortal - Trunk build 619 was SUCCESSFUL (with 295 tests). Change made by Jennifer Bourey
--- UP-TRUNK-619 was successful. --- Code has been updated by Jennifer Bourey. 295 tests in total. https://developer.jasig.org/bamboo/browse/UP-TRUNK-619/ -- Code Changes -- Jennifer Bourey (22654): >UP-2907 Transitioning the entity search AJAX target to a real REST service. >Also refactoring the entity registry javascript widget as a Fluid component. Jennifer Bourey (22655): >UP-2908 Adding group operations permissions checks and delegated group >administration features. -- JIRA Issues -- UP-2907: Transition entity selection AJAX target to a proper REST service UP-2908: Support delegated groups administration -- This message is automatically generated by Atlassian Bamboo
[uportal-dev] [Bamboo] uPortal - Trunk build 618 has FAILED (0 tests failed). Change made by Jennifer Bourey
--- UP-TRUNK-618 failed. --- Code has been updated by Jennifer Bourey. No failed tests found, a possible compilation error. https://developer.jasig.org/bamboo/browse/UP-TRUNK-618/ -- Code Changes -- Jennifer Bourey (22653): >UP-2907 Transitioning the entity search AJAX target to a real REST service. >Also refactoring the entity registry javascript widget as a Fluid component. -- JIRA Issues -- UP-2907: Transition entity selection AJAX target to a proper REST service -- This message is automatically generated by Atlassian Bamboo
Re: [uportal-dev] Recent filtering updates
Do we need uportal-user feedback on these questions too? -Jonathan On Mon, Dec 13, 2010 at 12:02 PM, Jen Bourey wrote: > On Dec 9, 2010, at 6:26 PM, Eric Dalquist wrote: > > > Our goal should be that you can cd to any module the project and run "mvn > clean install" and it will work with nothing in your local maven repository. > This may not always be true in code coming from trunk or a -patches branch > due to snapshot issues but for any release we cut that needs to be true. > Depending on something in a source directory works just fine with this goal, > depending on something in a target directory does not. > > I agree that we want a setup that is only dependent on source directory > resources. It should make the project easier to build, plus it prevents us > from breaking the boundaries between maven projects. It also seems to me > like we'd get more mileage out of using the shared filter file as the > filtering resource in the portlets, rather than using the rdbm.properties > file, since that gives us access to many more filter tokens. > > >> The "painful to merge" part is exactly why I was so keen to get it in. > The pom changes for many reasons and in many ways between releases; if > you've got home-grown filtering in place you already feel this pain (I do), > even without conflicting on those specific lines. > >> > >> I don't believe it makes the pain much worse at all to sort out > differences between the filtering that was added and whatever filtering you > had. But it certainly makes the pain much better going forward, considering > you only have to deal with sorting that out the one time. > > Right, but our stated release policy is as little pain as possible from > patches releases. If fixing a bad bug causes some pain to merge it is > unavoidable. Adding a new feature that causes pain during a merge is more > questionable since we don't need to do that to fix some other issue. > > I'm personally open to adding this patch to 3.2.x, and it would probably > make my life easier. However, I'd really love some community feedback > before we decide either way. I'm particularly worried about schools who may > have had their maven customization done by someone who's busy at the moment, > or perhaps done by a consultant (we've helped some institutions to set up > local maven filtering). I'd hate to get into a situation where schools > can't pick up some of the recent important bug fixes because they don't have > the time to work through all the subversion conflicts and redo their > deployment strategy. > > Given our general release policy, it seems to me like this might be too big > of a change, but I'd really like the community as a whole to weight the > benefits and costs of applying this patch to the maintenance branch and tell > us what they'd like to do. If this is going to cause significant trouble > upgrading for many people, we can always offer it as an optional patch > instead. > > My other concern about applying this patch to 3.2.x right now is that it > feels unfinished to me. I'd love more testing and community feedback before > we integrate it into 3.2.x. Do people feel this patch is sufficient? Do > they like the overall strategy? Do people like the filter token names, or > are they too long? (I actually personally picked them, so I'm not > complaining, but I can see how they might seem unwieldly). > > Personally I feel like for this strategy to be useful and to replace what > our adopters have already implemented locally, we likely need to go further. > We'd probably want to go ahead and apply the shared filter files to the CAS > context, and to the portlet overlays. I'd like to make sure that the > version that's integrated into 3.2.x is a mostly-final version of the > changes, so that 3.2.x adopters only have to integrate these changes once, > rather than resolving conflicts several times as we refine our filtering > strategy. > > - Jen > -- > You are currently subscribed to uportal-dev@lists.ja-sig.org as: > jjmar...@jasig.org > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
Re: [uportal-dev] Recent filtering updates
On Dec 9, 2010, at 6:26 PM, Eric Dalquist wrote: > Our goal should be that you can cd to any module the project and run "mvn > clean install" and it will work with nothing in your local maven repository. > This may not always be true in code coming from trunk or a -patches branch > due to snapshot issues but for any release we cut that needs to be true. > Depending on something in a source directory works just fine with this goal, > depending on something in a target directory does not. I agree that we want a setup that is only dependent on source directory resources. It should make the project easier to build, plus it prevents us from breaking the boundaries between maven projects. It also seems to me like we'd get more mileage out of using the shared filter file as the filtering resource in the portlets, rather than using the rdbm.properties file, since that gives us access to many more filter tokens. >> The "painful to merge" part is exactly why I was so keen to get it in. The >> pom changes for many reasons and in many ways between releases; if you've >> got home-grown filtering in place you already feel this pain (I do), even >> without conflicting on those specific lines. >> >> I don't believe it makes the pain much worse at all to sort out differences >> between the filtering that was added and whatever filtering you had. But it >> certainly makes the pain much better going forward, considering you only >> have to deal with sorting that out the one time. > Right, but our stated release policy is as little pain as possible from > patches releases. If fixing a bad bug causes some pain to merge it is > unavoidable. Adding a new feature that causes pain during a merge is more > questionable since we don't need to do that to fix some other issue. I'm personally open to adding this patch to 3.2.x, and it would probably make my life easier. However, I'd really love some community feedback before we decide either way. I'm particularly worried about schools who may have had their maven customization done by someone who's busy at the moment, or perhaps done by a consultant (we've helped some institutions to set up local maven filtering). I'd hate to get into a situation where schools can't pick up some of the recent important bug fixes because they don't have the time to work through all the subversion conflicts and redo their deployment strategy. Given our general release policy, it seems to me like this might be too big of a change, but I'd really like the community as a whole to weight the benefits and costs of applying this patch to the maintenance branch and tell us what they'd like to do. If this is going to cause significant trouble upgrading for many people, we can always offer it as an optional patch instead. My other concern about applying this patch to 3.2.x right now is that it feels unfinished to me. I'd love more testing and community feedback before we integrate it into 3.2.x. Do people feel this patch is sufficient? Do they like the overall strategy? Do people like the filter token names, or are they too long? (I actually personally picked them, so I'm not complaining, but I can see how they might seem unwieldly). Personally I feel like for this strategy to be useful and to replace what our adopters have already implemented locally, we likely need to go further. We'd probably want to go ahead and apply the shared filter files to the CAS context, and to the portlet overlays. I'd like to make sure that the version that's integrated into 3.2.x is a mostly-final version of the changes, so that 3.2.x adopters only have to integrate these changes once, rather than resolving conflicts several times as we refine our filtering strategy. - Jen -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
