Re: [uportal-dev] Inactive committers
You could remove my committer-ship if you want, and that makes the list somehow cleaner for you. I have not committed anything recently. However, I do believe I am still an active member of the community. Cris J H On 11/07/2014 07:08 AM, Andrew Petro wrote: uPortal committers, These committers are members of the uportal-developers GitHub team ( https://github.com/orgs/Jasig/teams/uportal-developers ) but have zero commits in Jasig/uPortal/master in the last year ( https://github.com/Jasig/uPortal/graphs/contributors?from=2013-11-07to=2014-11-07type=c ). * Are you active in other GitHub projects that complectedly grant their committership through the uportal-developers Team rather than via a portlet-specific Team (if so, sorry for the bother!)? * Are you active in merging Pull Requests rather than by writing new code (if so, sorry for the bother, the naive GitHub reporting doesn't credit merge commits.) * Is there something active developers can do to help you to again become active in contributing code to uPortal? * Are you on hiatus but expect to return to activity? * Or, sadly, is it time to retire your uportal-developers Team membership, no doubt with leave to joyously be re-welcomed in a happily more active future? Inactive: agherna agrabovskis bourey dmccallum holdorph jeffbcross steveswinsburg timit tuyly waymirec wgthom Kind regards, Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: holdo...@unicon.net 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] Moving away from Ant/Maven to Gradle
One thing I think is important to look at with the 'build' system in uPortal, is there has long been parts of the system that have nothing to do with 'building'. Take a simple example, like adding a new fragment to uPortal from a fragment definition file. This does not need to be tied to the build system. Here's another... Loading the initial database. That's an installation step, not a build step. uPortal's build system is complicated because it's trying to be 3 things in one. It's trying to 1) build uPortal, 2) install uPortal, 3) system administer uPortal. If I was to put time towards working on this problem, my first goal would be to get 2 and 3 out of the build altogether and handled in some other way. If you did that, I believe you'd have a simpler build system then you have right now. Going with Gradle to handle the 'scripting' that is currently done in Ant, tells me that we're just going to keep the problem of having all three of these things mixed together in one system. I think that's a mistake. And even if you get to something that feels like an improvement over the current ant+maven, it will still be more complicated then it needs to be. Cris J H On 11/07/2014 09:01 AM, Misagh Moayyed wrote: uPortal Devs, I have set aside some time to take a look at the uPortal build system and see if we can move away from the ant/maven hybrid setup and either to a pure maven-based build or perhaps even use Gradle. I am leaning more and more towards Gradle as that would take care of a lot of scripting ant-like tasks that exist today and certainly is easier to write and configure the build with. The downside is there aren’t too many plugins available for Gradle like they are with Maven so depending on the pluginset uPortal uses today we might run into a few roadblocks. So questions are: 1. How do others feel about this build tool and the approach? 2. Has anybody begun working on the same proposal locally perhaps? 3. What uPortal release should this be targeted to? I’d assume 5.0 as this would be a pretty big change both in scope and the effort/time required to implement this. Misagh -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: holdo...@unicon.net 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] Moving away from Ant/Maven to Gradle
That's exactly, or well very close anyway, to my original point. What people in this thread have been referring to 2. I strongly believe that the installation and the system admin tasks need to come out of the build scripts completely. They simply do not need to be part of them, and it causes problems as you are saying. Cris J H On 11/07/2014 11:05 AM, James Wennmacher wrote: This is a bit tangential, but one thing I'd like to see is uPortal move away from needing to do a build in order to deploy to an environment. Having a built artifact (ear, war, etc.) that can be deployed to any environment (local, dev, test, etc.) and having all environment-specific configuration be pulled from external configuration/property files IMHO is desirable. It wouldn't eliminate the need for the overlays, but it would reduce it a bit and would eliminate the need for the filtering process and would simplify the build process a bit, but make the deploy process perhaps a bit more complicated. It might also make it easier to use Docker, Chef, or similar with uPortal. Not now ... baby steps ... but worth mentioning/considering in case you have to jump through hoops to get Gradle to accommodate uPortal's current approach. James Wennmacher - Unicon 480.558.2420 On 11/07/2014 10:09 AM, Misagh Moayyed wrote: Agreed on all counts. I suppose my first objective was to first do a pure-conversion first and the tackle what can be moved out of the build script and into separate tasks. In terms of the refactoring effort, that seems like it would allow us to first remove a few trees in the way and get a clearer picture of what actually exists. (2) and (3) do not so much belong in the build script for sure, but nonetheless we'd have to provide some mechanism for the functionality they provide and Gradle seems like a good approach for those 2 as well. We can certainly move them out of the mother build script and have adopters simply call upon them when they need them. Part of the reason (2) and (3) are complected in the build I suppose is because the scripting nature of Ant sort of paved the pathway for those ops and it must have seemed convenient to use the tool for both the build and post-build functionaries. We surely need to break these out, so options are: 1. Break the ant tasks out into a separate configuration. Have the uPortal build only be based on Maven and let Ant handle post-build ops like initializing the db, etc. While effort-wise, this might seem simpler, it would be very much confusing for adopters to try to learn the tricks of each tool and what commands are available. 2. Break the ant tasks out into a separate configuration but let both the build as well as (2) and (3) to be based on Gradle. This should provide a seamless syntax and would reduce technical dependencies. Plus, it seems like for some of the gymnastics ant build right now is doing to carry out x-y-z, Gradle would surely be a better fit since you can actually code the script rather than declare much of it. P.S1: If I remember correctly, the build we have even today creates and executes custom groovy scripts so in fact, we are using 3 things for a wholesome UP build :) P.S2: I am not prejudiced towards Gradle at all. Any other tool that would do the job with less noise would be most welcome. -Original Message- From: bounce-37554527-57692...@lists.wisc.edu [mailto:bounce-37554527- 57692...@lists.wisc.edu] On Behalf Of Cris J Holdorph Sent: Friday, November 7, 2014 9:11 AM To: uportal-dev@lists.ja-sig.org Subject: Re: [uportal-dev] Moving away from Ant/Maven to Gradle One thing I think is important to look at with the 'build' system in uPortal, is there has long been parts of the system that have nothing to do with 'building'. Take a simple example, like adding a new fragment to uPortal from a fragment definition file. This does not need to be tied to the build system. Here's another... Loading the initial database. That's an installation step, not a build step. uPortal's build system is complicated because it's trying to be 3 things in one. It's trying to 1) build uPortal, 2) install uPortal, 3) system administer uPortal. If I was to put time towards working on this problem, my first goal would be to get 2 and 3 out of the build altogether and handled in some other way. If you did that, I believe you'd have a simpler build system then you have right now. Going with Gradle to handle the 'scripting' that is currently done in Ant, tells me that we're just going to keep the problem of having all three of these things mixed together in one system. I think that's a mistake. And even if you get to something that feels like an improvement over the current ant+maven, it will still be more complicated then it needs to be. Cris J H On 11/07/2014 09:01 AM, Misagh Moayyed wrote: uPortal Devs, I have set aside some time to take a look at the uPortal build system and see if we can move away from the ant/maven
Re: [uportal-dev] Adopting Google Style for next major release
One other 'con' I'd like to bring up, besides Josh's (which I agree 100% with), is the following. I find inconsistent style frustrating, true. But what I find even more frustrating is when I'm trying to debug and I want to know why a line of code was last changed. If you reformat the entire codebase, even for something like uPortal 5.0. Then the history of trying to determine why a line of code is what it is, will be difficult, to potentially impossible (depends on how the change is made). It's not enough of a reason to say don't do this. But for me, it would actually be more annoying then the style problems are themselves. Cris J H On 11/06/2014 03:32 PM, James Wennmacher wrote: 100 (or worse yet 80) characters on a line! Oh man! I'm going to have to use shorter variable and method names. At least I only need to indent 2 spaces now. That will help. :-) +1 on a 'common' standard, especially if we can get it enforced in the build (as annoying as I find that is sometimes). Google's is great. James Wennmacher - Unicon 480.558.2420 On 11/06/2014 08:04 AM, Andrew Petro wrote: uPortal developers, I think it would be wise for uPortal to adopt tighter code style conventions (and to enforce these in the release process via build automation, since without automation style conventions will not be adhered to.) I think those code conventions should be Google's. https://google-styleguide.googlecode.com/svn/trunk/javaguide.html https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml etc. The product has a heap of code of varying style. I'd see a changeset to pervasively adjust style to the convention as only appropriate for a MAJOR release. As in, uPortal 5. So. This is the initial conversation-starting email expressing intention to advocate for this improvement for uPortal 5. Andrew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jwennmac...@unicon.net 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] master unit tests broken
Personally I think spending more time on getting rid of all the 'Ant' related parts would be a lot better then trying to break up uPortal into even smaller pieces. I understand the aspect you mention about disabling tests because they take so long, and if the tests took less time, then maybe you'd be less inclined to skip them. However, it's the 'build' in general that's taking a long time. And the ant parts of this build cause a LOT of problems. Speed is one them. Your recent mac/forking problem is an example of a second one. If you break the uPortal build into smaller chunks you will potentially address one small problem, but you will create new ones. One problem I see a LOT when a project is broken down into too small chunks, is that people then compile at too low of a level. Say you modify the groups api project. But you don't bother to rebuild the permissions project. And then something is broken. You never noticed, because you didn't rebuild everything. And if you DO rebuild everything, well then breaking the project apart, didn't really save you any time. It just introduced build time overhead. Cris J H On 10/28/2014 10:20 AM, Andrew Petro wrote: JW my uportal build script disables running the tests. A natural reaction to a build process that is way, way too expensive and punishing of running the unit tests. Part of where I want to get with Semantic Versioning is being able to separate what’s currently a monolith in uportal-war/src/java into components small enough that it’s not too painful to run the unit tests on the one component I'm touching right at the moment, that are loosely coupled enough that I don’t have to whack all of the components all at once to get anything done, and that thus are in pieces small enough to build and test in the generous but not huge resource allocation that travis-ci affords. How do we get traction on doing that detangling, and calling the result uPortal 5? :) Kind regards, Andrew On Oct 28, 2014, at 12:14 PM, James Wennmacher jwennmac...@unicon.net wrote: Hi Andrew, Josh brought this to my attention late yesterday and I started looking into it. I hope to have a fix pushed shortly. I apologize, I forgot my uportal build script disables running the tests. James Wennmacher - Unicon 480.558.2420 On 10/28/2014 08:52 AM, Andrew Petro wrote: Devs, Looks to me like this changeset https://github.com/Jasig/uPortal/pull/438 causes this unit test to fail: http://goo.gl/KS6a6p in this way: https://gist.github.com/apetro/2ad26a798d6b33e87c49 . Locally reverting the change: https://github.com/apetro/uPortal/tree/try_reverting_UP-4264 locally fixes the problem. Therefore I propose reverting this commit in master. Shall I press the Revert button here, or should we handle this in another way? https://github.com/Jasig/uPortal/pull/438 Andrew PS: Reminds me of the need to circle back and detangle this codebase and build so that Travis-CI can reliably build and run the unit tests, to help catch this kind of thing before Pull Request merge. :) -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jwennmac...@unicon.net 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: andrew.pe...@wisc.edu 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] master unit tests broken
It's the forking of ant from maven that is the slowness I'm referring to in the current uPortal build. If everything was run from just maven, instead of forking off ant (or using antrun), it would be faster. However, speed is not the primary reason. It's all of the other ugly side effects the ant parts cause, that would be why I'd recommend spending time on this. Just ask James W. how much fun he's had over the last few months debugging problems related to this. Cris J H On 10/28/2014 11:14 AM, Misagh Moayyed wrote: So this gets me curious; before I spin to research mode I am wondering: are there any advantages to switch from ant over to a pure maven/gradle build that would help with performance? Or, are you saying if the build was to convert over to say a pure maven/gradle build there are features (like parallel builds and such) that uPortal could use to speed up build time? I have converted projects from maven to gradle and have not noticed any significant performance improvements. No parallel builds or any other changes were made of course to the build scripts. Same old config, just written a different way executed on the same machine. One thing however that I noticed tremendously sped up the build was generation of log data as part of tests. Huge difference there. Of course, changing tests to less rely on external resources did help to a degree as well. Builds that used to take beyond 50 minutes (and thereby timing out on Travis because Travis has a 50-minute mark set for public projects on their free plan) now complete in less than 20 minutes, give or take. -Original Message- From: bounce-37470921-57692...@lists.wisc.edu [mailto:bounce-37470921-57692...@lists.wisc.edu] On Behalf Of Cris J Holdorph Sent: Tuesday, October 28, 2014 10:49 AM To: uportal-dev@lists.ja-sig.org Subject: Re: [uportal-dev] master unit tests broken Personally I think spending more time on getting rid of all the 'Ant' related parts would be a lot better then trying to break up uPortal into even smaller pieces. I understand the aspect you mention about disabling tests because they take so long, and if the tests took less time, then maybe you'd be less inclined to skip them. However, it's the 'build' in general that's taking a long time. And the ant parts of this build cause a LOT of problems. Speed is one them. Your recent mac/forking problem is an example of a second one. If you break the uPortal build into smaller chunks you will potentially address one small problem, but you will create new ones. One problem I see a LOT when a project is broken down into too small chunks, is that people then compile at too low of a level. Say you modify the groups api project. But you don't bother to rebuild the permissions project. And then something is broken. You never noticed, because you didn't rebuild everything. And if you DO rebuild everything, well then breaking the project apart, didn't really save you any time. It just introduced build time overhead. Cris J H On 10/28/2014 10:20 AM, Andrew Petro wrote: JW my uportal build script disables running the tests. A natural reaction to a build process that is way, way too expensive and punishing of running the unit tests. Part of where I want to get with Semantic Versioning is being able to separate what’s currently a monolith in uportal-war/src/java into components small enough that it’s not too painful to run the unit tests on the one component I'm touching right at the moment, that are loosely coupled enough that I don’t have to whack all of the components all at once to get anything done, and that thus are in pieces small enough to build and test in the generous but not huge resource allocation that travis-ci affords. How do we get traction on doing that detangling, and calling the result uPortal 5? :) Kind regards, Andrew On Oct 28, 2014, at 12:14 PM, James Wennmacher jwennmac...@unicon.net wrote: Hi Andrew, Josh brought this to my attention late yesterday and I started looking into it. I hope to have a fix pushed shortly. I apologize, I forgot my uportal build script disables running the tests. James Wennmacher - Unicon 480.558.2420 On 10/28/2014 08:52 AM, Andrew Petro wrote: Devs, Looks to me like this changeset https://github.com/Jasig/uPortal/pull/438 causes this unit test to fail: http://goo.gl/KS6a6p in this way: https://gist.github.com/apetro/2ad26a798d6b33e87c49 . Locally reverting the change: https://github.com/apetro/uPortal/tree/try_reverting_UP-4264 locally fixes the problem. Therefore I propose reverting this commit in master. Shall I press the Revert button here, or should we handle this in another way? https://github.com/Jasig/uPortal/pull/438 Andrew PS: Reminds me of the need to circle back and detangle this codebase and build so that Travis-CI can reliably build and run the unit tests, to help catch this kind of thing before Pull Request merge. :) -- You are currently subscribed
Re: [uportal-dev] FW: Moving jasig-parent to Github
Why is it needed at all? What settings exist in the jasig parent pom that uPortal and cas truly need to share? I just took at look at it, and I don't see very much, if anything in that file that both CAS and uPortal need to be on the same version with, except for one item, which is wrong as it is. For example. You might say that organization should be shared. However, the organization is no longer jasig it's Apereo. You might say well, it's convenient to define some of the plugins, maybe, but do we have to have two projects on the same version of those plugins? For example, the maven-compiler-plugin is set at building for JDK 1.6. I could see a real need for projects to have that set to different values. And if they override it, then they are not gaining value by it being defined in the parent. I bring this up, because as we've seen dependency management and maven are sometimes (often?) painful. And unless it's absolutely required, reducing the number of dependencies a project has can be beneficial. I suggest, that this jasig-parent-pom dependency is one that neither project really needs. Cris J H On 09/01/2014 11:35 PM, Misagh Moayyed wrote: uPortal/CAS developers, I am wondering if it makes sense for us to move the jasig-parent project off of SVN and over to Github. Since both CAS and uPortal (and possibly plenty of other projects) inherit from the parent pom, it seems reasonable to move the project off of SVN and over to Github to allow more visibility for the changes that go into it. Specifically, I would like to attempt to tweak the maven site plugin configuration, update some dependencies and see if we can get a better performance out of the plugin, and it would be better if I could do that in context of the pull request. Objections? Suggestions? Misagh -- 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] Semantic Versioning : we should do it
2. Semantic versioning says you add functionality UP-4146 says no new features. those seem in disagreement to me. Maybe it's just an interpretation of the word functionality and the word feature, but to me those seem like direct opposite statements. One is saying you do something and the other is saying you don't do something. As a specific example, lets invent some new toggle that appears in the footer. When you press this toggle is does cool thing. Now, this new toggle in the bottom has no backward compatibility problem, it's just a new cool toggle. According to the point 2 in semantic versioning, that seems like it is allowed, because it is new functionality that is backward compatible. According to UP-4146, it says no new features, so it would not be allowed. Cris J H On 06/19/2014 10:40 AM, Andrew Petro wrote: Cris, Hmm. I'm not seeing the disagreement. Can you give an example of a change between kinds of versions that Semantic Versioning would allow but the description in UP-4146 would forbid, or vice versa? Andrew On 6/19/14, 12:10 PM, Cris J Holdorph wrote: There seems to be a difference in the Semantic Versioning you quoted and what you put into the Jira UP-4146. Specifically in this point. Semantic Versioning quote: 2. MINOR version when you add functionality in a backwards-compatible manner In UP-4146 starting with the uPortal 4.2 release, *no new features* in the 4.2 maintenance branch. Emphatically backwards-compatible bugfixes only. Those don't seem to be in agreement to me. Cris J H On 06/18/2014 09:35 AM, Andrew Petro wrote: Now tracked in JIRA and tagged for uPortal 4.2. https://issues.jasig.org/browse/UP-4146 On Wed, Jun 11, 2014 at 9:23 AM, Andrew Petro ape...@wisc.edu mailto:ape...@wisc.edu wrote: uPortal folks, I would like to start floating the Semantic Versioning balloon and see if it can earn mindshare. Currently our practice is to add both minor new features / enhancements and bugfixes in patch releases. I think our practice should change to bugfixes-only in patch releases, and do more frequent minor releases to get new features out. Cf. Semantic Versioning: http://semver.org/ Here's the summary: [ Summary Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. ] I expect that this change in practice would be all upside. It would make patch releases less risky and less complex, and so would make it more feasible to cut them more often and for adopters to upgrade along the patches branch to later patch releases more often. No new features to figure out how they relate to what you're doing, just bugfixes. Easier to understand, easier to accept, clearer what you're getting. It would make clearer what a minor release vs a patch release is and why it becomes time to cut a minor release and what you get for your minor release. It would move uPortal to align with Semantic Versioning, which is a thing. Even a good thing. I'm in-progress cutting the 4.0.14 release, and that's still a non-semantic-versioning patch release with some new stuff in it. Fine. I expect we ought not to change strategies for what the 4.1.x patches line looks like, since 4.1.0 is scoped and being released under the expectation that it can be patched with enhancements to backfill gaps. Also fine. So, if this balloon flies, perhaps the version to adopt Semantic Versioning in would be uPortal 4.2, and with that in mind we work towards a 4.2.0 suitable for treating in this way post-4.1.0-release, and this all fits into the broader theme of evolving uPortal to be and to be treated more like a product. Note that adopting Semantic Versioning says absolutely nothing about the timeline on which bugfix and new feature releases are released. It's just about what we call them and how we set adopter expectations about what kind of changes happen where. There's no rule that we couldn't cut minor releases even monthly to promptly get those new features out to adopters if there's that kind of progress being made in the codebase; calling those minor releases is just a clearer way to communicate about what they are. This also fits into a story arc of working towards defining and exposing versioned APIs. When the codebase is mostly a monolithic bucket containing both APIs and implementations, nudging them forward all together in a patches branch, well, it's mostly worked for us. But if the product begins to get
Re: [uportal-dev] Semantic Versioning : we should do it
Sure, that makes more sense. Perhaps it's the lack of an example of a three part version number in the UP-4146 description that had me confused. Right now, UP-4146 only mentiones 4.2, 4.3 and 5 in the description. Your description below is more concrete to me and talks about 4.2.1 and so on. Cris J H On 06/19/2014 11:06 AM, Andrew Petro wrote: Cris, Ah. I think our miscommunication is coming from keeping track of how the labels minor and patch apply to different release numbers and to maintenance branches. Semantic versioning says you add functionality Add (backwards-compatible) functionality for MINOR releases, like 4.3 will add functionality beyond 4.2. UP-4146 says no new features. No new features in maintenance branches leading to PATCH releases, so no new functionality in 4.2.1 beyond the functionality in 4.2.0. To take the example of a new backwards-compatible footer toggle adding GumGum integration, after 4.2.0 is released, that new feature could come into master towards 4.3.0, but it could not come into 4.2-patches towards 4.2.1. Clarifying? Andrew On 6/19/14, 12:46 PM, Cris J Holdorph wrote: 2. Semantic versioning says you add functionality UP-4146 says no new features. those seem in disagreement to me. Maybe it's just an interpretation of the word functionality and the word feature, but to me those seem like direct opposite statements. One is saying you do something and the other is saying you don't do something. As a specific example, lets invent some new toggle that appears in the footer. When you press this toggle is does cool thing. Now, this new toggle in the bottom has no backward compatibility problem, it's just a new cool toggle. According to the point 2 in semantic versioning, that seems like it is allowed, because it is new functionality that is backward compatible. According to UP-4146, it says no new features, so it would not be allowed. Cris J H On 06/19/2014 10:40 AM, Andrew Petro wrote: Cris, Hmm. I'm not seeing the disagreement. Can you give an example of a change between kinds of versions that Semantic Versioning would allow but the description in UP-4146 would forbid, or vice versa? Andrew On 6/19/14, 12:10 PM, Cris J Holdorph wrote: There seems to be a difference in the Semantic Versioning you quoted and what you put into the Jira UP-4146. Specifically in this point. Semantic Versioning quote: 2. MINOR version when you add functionality in a backwards-compatible manner In UP-4146 starting with the uPortal 4.2 release, *no new features* in the 4.2 maintenance branch. Emphatically backwards-compatible bugfixes only. Those don't seem to be in agreement to me. Cris J H On 06/18/2014 09:35 AM, Andrew Petro wrote: Now tracked in JIRA and tagged for uPortal 4.2. https://issues.jasig.org/browse/UP-4146 On Wed, Jun 11, 2014 at 9:23 AM, Andrew Petro ape...@wisc.edu mailto:ape...@wisc.edu wrote: uPortal folks, I would like to start floating the Semantic Versioning balloon and see if it can earn mindshare. Currently our practice is to add both minor new features / enhancements and bugfixes in patch releases. I think our practice should change to bugfixes-only in patch releases, and do more frequent minor releases to get new features out. Cf. Semantic Versioning: http://semver.org/ Here's the summary: [ Summary Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards-compatible bug fixes. Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format. ] I expect that this change in practice would be all upside. It would make patch releases less risky and less complex, and so would make it more feasible to cut them more often and for adopters to upgrade along the patches branch to later patch releases more often. No new features to figure out how they relate to what you're doing, just bugfixes. Easier to understand, easier to accept, clearer what you're getting. It would make clearer what a minor release vs a patch release is and why it becomes time to cut a minor release and what you get for your minor release. It would move uPortal to align with Semantic Versioning, which is a thing. Even a good thing. I'm in-progress cutting the 4.0.14 release, and that's still a non-semantic-versioning patch release with some new stuff in it. Fine. I expect we ought not to change strategies for what the 4.1.x patches line looks like, since 4.1.0 is scoped and being released under the expectation that it can be patched with enhancements to backfill gaps. Also fine. So, if this balloon flies, perhaps the version
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
This is probably not your problem, but I thought I would share some recent experience with maven, repositories and dependency debugging. I was trying to set up a local artifact repository to do mirroring of maven dependencies. This is useful for dependencies that are not in central, that might disappear. Anyway, to fully test my 'mirror' I started with an empty repository and would try to build my projects. I discovered a really interesting situation. Take a look at these two pom files from two different maven repos. http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.2.2/commons-dbcp-1.2.2.pom http://jcenter.bintray.com/commons-dbcp/commons-dbcp/1.2.2/#commons-dbcp-1.2.2.pom Notice how the second one is different then the first. I suspect the second one must have been autogenerated. In any case though, it causes a really big problem if that is where the dependency gets pulled down from. So, my overall point is, when you're starting from an empty maven repo, you can definitely get really weird and odd things happening. It can be really hard to debug. (in the above problem, it 'manifested' as a junit test failure about a missing class!) Cris J H On 06/13/2014 09:37 AM, Drew Wills wrote: Folks, I'm encountering a new Maven dependency issue with echcache. It seems to happen always (small sample size) on a machine that doesn't have these artifacts cached in the local repo. These items do seem to be in m2 central. I'm not sure how Maven is getting the 'null:ehcache-web:jar:null' (see below) but I suspect it's a factor in the issue. drew --- BUILD FAILED /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:635: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1437: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1372: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1315: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1318: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1375: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/portal/uPortal/build.xml:1227: Unable to resolve artifact: Unable to get dependency information: Unable to read the metadata file for artifact 'net.sf.ehcache:ehcache-web:jar': Cannot find parent: net.sf.ehcache:ehcache-web-parent for project: null:ehcache-web:jar:null for project null:ehcache-web:jar:null net.sf.ehcache:ehcache-web:jar:2.0.4 from the specified remote repositories: central (http://repo1.maven.org/maven2), sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots), apache-snapshots (http://repository.apache.org/snapshots) Path to dependency: 1) org.jasig.portal:uportal-war:war:4.1.0-SNAPSHOT 2) org.jasig.resourceserver:resource-server-utils:jar:1.0.38 -- 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] Trouble with net.sf.ehcache:ehcache-web-parent dependency
It's not just a simple matter of putting YOUR dependencies into central and not putting repositories into YOUR pom files. With transitive dependencies, ESPECIALLY specific versions, this can happen through a dependency that came in from a transitive dependency. Example: I specify I want to use Foo version 1.1. At the time of my using it, it is in central, so I don't think anything more of it. I do not notice, but Foo version 1.1, uses bar 2.0. Bar 2.0 uses crud 3.0. crud 3.0 specifies a respository in it's pom.xml file to go get blah version 1.2.3 from some weird repo. Final result, my project is now dependent on some weird repo for version 1.2.3 of blah. Cris J H On 06/13/2014 09:57 AM, Eric Dalquist wrote: This highlights the very real danger of adding extra repositories. It may be more work up front to get all the deps you need into central but it is very much worth it long term to avoid this sort of dependency hell pain. On Fri, Jun 13, 2014 at 9:49 AM, Cris J Holdorph holdo...@unicon.net mailto:holdo...@unicon.net wrote: This is probably not your problem, but I thought I would share some recent experience with maven, repositories and dependency debugging. I was trying to set up a local artifact repository to do mirroring of maven dependencies. This is useful for dependencies that are not in central, that might disappear. Anyway, to fully test my 'mirror' I started with an empty repository and would try to build my projects. I discovered a really interesting situation. Take a look at these two pom files from two different maven repos. http://repo1.maven.org/maven2/__commons-dbcp/commons-dbcp/1.2.__2/commons-dbcp-1.2.2.pom http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.2.2/commons-dbcp-1.2.2.pom http://jcenter.bintray.com/__commons-dbcp/commons-dbcp/1.2.__2/#commons-dbcp-1.2.2.pom http://jcenter.bintray.com/commons-dbcp/commons-dbcp/1.2.2/#commons-dbcp-1.2.2.pom Notice how the second one is different then the first. I suspect the second one must have been autogenerated. In any case though, it causes a really big problem if that is where the dependency gets pulled down from. So, my overall point is, when you're starting from an empty maven repo, you can definitely get really weird and odd things happening. It can be really hard to debug. (in the above problem, it 'manifested' as a junit test failure about a missing class!) Cris J H On 06/13/2014 09:37 AM, Drew Wills wrote: Folks, I'm encountering a new Maven dependency issue with echcache. It seems to happen always (small sample size) on a machine that doesn't have these artifacts cached in the local repo. These items do seem to be in m2 central. I'm not sure how Maven is getting the 'null:ehcache-web:jar:null' (see below) but I suspect it's a factor in the issue. drew --- BUILD FAILED /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:635: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1437: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1372: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1315: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1318: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1375: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1227: Unable to resolve artifact: Unable to get dependency information: Unable to read the metadata file for artifact 'net.sf.ehcache:ehcache-web:__jar': Cannot find parent: net.sf.ehcache:ehcache-web-__parent for project: null:ehcache-web:jar:null for project null:ehcache-web:jar:null net.sf.ehcache:ehcache-web:__jar:2.0.4 from the specified remote repositories: central (http://repo1.maven.org/maven2__), sonatype-nexus-snapshots (https://oss.sonatype.org/__content/repositories/snapshots https://oss.sonatype.org/content/repositories/snapshots__), apache-snapshots (http://repository.apache.org/__snapshots http://repository.apache.org/snapshots) Path to dependency: 1) org.jasig.portal:uportal-war:__war:4.1.0-SNAPSHOT 2) org.jasig.resourceserver:__resource-server-utils:jar:1.0.__38 -- You are currently subscribed to uportal-dev@lists.ja
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
Well yes, that's all good and definitely encouraged for any maven project you are in control of. But I also think it's worth standing up an artifact repository at your own organization and having that 'mirror' every repository. So that you actually don't go out and hit any repository directly yourself. Instead you only hit your own artifact repository, and that repository in turn will hit the internet. This is kind of the equivalent of fixing, at an organizational level the difference between a developer who has been around for a while and has a pretty full personal maven repo, and his builds work, and a new developer who has an empty personal maven repository and his build does not work. I'm NOT suggesting this is INSTEAD of putting things into central, but more of an additional thing an organization can do to help bring new developers on board. Cris J H On 06/13/2014 11:01 AM, Andrew Petro wrote: Cris, True, dependencies in Central can have dependencies on external repos. But that is at least discouraged: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement and in some happy future might even be enforced or at least mostly respected such that getting a dependency from Central is an indication that it doesn't have this problem. So, you're all right: getting the dependencies from Central doesn't solve all problems, but the more dependencies are entirely realizable via only-in-Central dependencies, the better. :) Kind regards, Andrew On 6/13/14, 12:54 PM, Cris J Holdorph wrote: It's not just a simple matter of putting YOUR dependencies into central and not putting repositories into YOUR pom files. With transitive dependencies, ESPECIALLY specific versions, this can happen through a dependency that came in from a transitive dependency. Example: I specify I want to use Foo version 1.1. At the time of my using it, it is in central, so I don't think anything more of it. I do not notice, but Foo version 1.1, uses bar 2.0. Bar 2.0 uses crud 3.0. crud 3.0 specifies a respository in it's pom.xml file to go get blah version 1.2.3 from some weird repo. Final result, my project is now dependent on some weird repo for version 1.2.3 of blah. Cris J H On 06/13/2014 09:57 AM, Eric Dalquist wrote: This highlights the very real danger of adding extra repositories. It may be more work up front to get all the deps you need into central but it is very much worth it long term to avoid this sort of dependency hell pain. On Fri, Jun 13, 2014 at 9:49 AM, Cris J Holdorph holdo...@unicon.net mailto:holdo...@unicon.net wrote: This is probably not your problem, but I thought I would share some recent experience with maven, repositories and dependency debugging. I was trying to set up a local artifact repository to do mirroring of maven dependencies. This is useful for dependencies that are not in central, that might disappear. Anyway, to fully test my 'mirror' I started with an empty repository and would try to build my projects. I discovered a really interesting situation. Take a look at these two pom files from two different maven repos. http://repo1.maven.org/maven2/__commons-dbcp/commons-dbcp/1.2.__2/commons-dbcp-1.2.2.pom http://repo1.maven.org/maven2/commons-dbcp/commons-dbcp/1.2.2/commons-dbcp-1.2.2.pom http://jcenter.bintray.com/__commons-dbcp/commons-dbcp/1.2.__2/#commons-dbcp-1.2.2.pom http://jcenter.bintray.com/commons-dbcp/commons-dbcp/1.2.2/#commons-dbcp-1.2.2.pom Notice how the second one is different then the first. I suspect the second one must have been autogenerated. In any case though, it causes a really big problem if that is where the dependency gets pulled down from. So, my overall point is, when you're starting from an empty maven repo, you can definitely get really weird and odd things happening. It can be really hard to debug. (in the above problem, it 'manifested' as a junit test failure about a missing class!) Cris J H On 06/13/2014 09:37 AM, Drew Wills wrote: Folks, I'm encountering a new Maven dependency issue with echcache. It seems to happen always (small sample size) on a machine that doesn't have these artifacts cached in the local repo. These items do seem to be in m2 central. I'm not sure how Maven is getting the 'null:ehcache-web:jar:null' (see below) but I suspect it's a factor in the issue. drew --- BUILD FAILED /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:635: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1437: The following error occurred while executing this line: /home/awills/Dropbox/Jasig/__portal/uPortal/build.xml:1372
Re: [uportal-dev] Trouble with net.sf.ehcache:ehcache-web-parent dependency
Artifactory is pretty good too. There's also archiva. I found this link comparing them helpful. http://docs.codehaus.org/display/MAVENUSER/Maven+Repository+Manager+Feature+Matrix I went with Artifactory myself. But Nexus has been around a little longer and seems more popular with people that don't like to pay for software. Artifactory does have an open source option which I'm using, but some of their cool features are only in the pay-for-license version. Cris J H On 06/13/2014 11:21 AM, Eric Dalquist wrote: Oh right, running a local Nexus instance as a proxy is very valuable. Being able to always reproduce previous builds and insulating your build process from external failures is quite valuable. On Fri, Jun 13, 2014 at 11:09 AM, Cris J Holdorph holdo...@unicon.net mailto:holdo...@unicon.net wrote: Well yes, that's all good and definitely encouraged for any maven project you are in control of. But I also think it's worth standing up an artifact repository at your own organization and having that 'mirror' every repository. So that you actually don't go out and hit any repository directly yourself. Instead you only hit your own artifact repository, and that repository in turn will hit the internet. This is kind of the equivalent of fixing, at an organizational level the difference between a developer who has been around for a while and has a pretty full personal maven repo, and his builds work, and a new developer who has an empty personal maven repository and his build does not work. I'm NOT suggesting this is INSTEAD of putting things into central, but more of an additional thing an organization can do to help bring new developers on board. Cris J H On 06/13/2014 11:01 AM, Andrew Petro wrote: Cris, True, dependencies in Central can have dependencies on external repos. But that is at least discouraged: https://docs.sonatype.org/__display/Repository/Sonatype+__OSS+Maven+Repository+Usage+__Guide#__SonatypeOSSMavenRepositoryUsag__eGuide-6.__CentralSyncRequirement https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement and in some happy future might even be enforced or at least mostly respected such that getting a dependency from Central is an indication that it doesn't have this problem. So, you're all right: getting the dependencies from Central doesn't solve all problems, but the more dependencies are entirely realizable via only-in-Central dependencies, the better. :) Kind regards, Andrew On 6/13/14, 12:54 PM, Cris J Holdorph wrote: It's not just a simple matter of putting YOUR dependencies into central and not putting repositories into YOUR pom files. With transitive dependencies, ESPECIALLY specific versions, this can happen through a dependency that came in from a transitive dependency. Example: I specify I want to use Foo version 1.1. At the time of my using it, it is in central, so I don't think anything more of it. I do not notice, but Foo version 1.1, uses bar 2.0. Bar 2.0 uses crud 3.0. crud 3.0 specifies a respository in it's pom.xml file to go get blah version 1.2.3 from some weird repo. Final result, my project is now dependent on some weird repo for version 1.2.3 of blah. Cris J H On 06/13/2014 09:57 AM, Eric Dalquist wrote: This highlights the very real danger of adding extra repositories. It may be more work up front to get all the deps you need into central but it is very much worth it long term to avoid this sort of dependency hell pain. On Fri, Jun 13, 2014 at 9:49 AM, Cris J Holdorph holdo...@unicon.net mailto:holdo...@unicon.net mailto:holdo...@unicon.net mailto:holdo...@unicon.net wrote: This is probably not your problem, but I thought I would share some recent experience with maven, repositories and dependency debugging. I was trying to set up a local artifact repository to do mirroring of maven dependencies. This is useful for dependencies that are not in central, that might disappear. Anyway, to fully test my 'mirror' I started with an empty repository and would try
Re: [uportal-dev] Gitter chat experiment
Does it allow someone to connect from their existing chat client, like pidgin? Cris J H On 04/18/2014 12:17 PM, Andrew Petro wrote: uPortal committers, As an experiment only (so far), let's check this out: https://gitter.im/Jasig/uPortal It *doesn't* seem to have the robust chat archive / search that we'd ideally want (but it does seem to be under active development and it's got more chat archive than the zero that we have operational on IRC now!) Love the GitHub integration, and the potential to turn on the Travis-CI integration etc. Andrew -- 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] Take BookmarksPortlet out of 4.1?
Removing dead-unused code is a common practice. If the code is used that changes the equation. My impression from Drew's original post and his followup response, was that he did not know of anyone actively using it. Therefore it would be dead-unused code. Cris J H On 12/10/2013 02:15 PM, Jim Helwig wrote: I, too, am wondering why you want to remove it. Very simple portlets might not require regular commits. What is the motivating rationale? JimH On 12/10/13, 3:04 PM, AUXEPAULES Ludovic wrote: We use the Bookmarks Portlet at UPMC. Why remove a Jasig Sponsored Portlet that works instead of trying to update or enhance it ? Ludovic Auxepaules -Message d'origine- De : bounce-33733171-52847...@lists.wisc.edu [mailto:bounce-33733171-52847...@lists.wisc.edu] De la part de Paul Gazda Envoyé : mardi 10 décembre 2013 20:10 À : uportal-dev@lists.ja-sig.org Objet : RE: [uportal-dev] Take BookmarksPortlet out of 4.1? We use the Bookmarks portlet, but could download and deploy the code separately. This might be worth posting on the uportal-user list to ask the broader user audience. Paul -Original Message- From: bounce-33732901-5712...@lists.wisc.edu [mailto:bounce-33732901-5712...@lists.wisc.edu] On Behalf Of Drew Wills Sent: Tuesday, December 10, 2013 11:44 AM To: uportal-dev@lists.ja-sig.org Subject: [uportal-dev] Take BookmarksPortlet out of 4.1? Hey folks, Would anyone object to removing (de-bundling) the BookmarksPortlet for the upcoming 4.1 release? We have largely moved away from portlets that start out blank and require users to do data entry -- which is what Bookmarks is. Meanwhile we're building bundling more and more compelling portlets, which gradually increases to build times and needs for PermGen space. Bookmarks hasn't received commits since Feb 2012. I think we're better off trimming it for the next release. drew -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: paul.ga...@nau.edu 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: ludovic.auxepau...@upmc.fr 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] Tomcat won't start on Mac
This is probably a more appropriate discussion for 'uportal-user'. 'uportal-dev' is for discussion of the uPortal core framework Java code. In any case, can you include the 'setenv.sh' you put in the directory as an attachment. I wonder if there is a kind of typo or whitespace problem in that. Cris J H On 11/22/2013 08:37 AM, Tim Raymond wrote: Thanks for the reply Andrew... I did add the setenv.sh to the tomcat bin per the instructions before attempting to launch. Tomcat isn’t even trying to start... nothing is being written to logs, only the catalina.sh usage written to terminal. Tim Raymond Director, Central Applications Instructional and Information Technology California State Polytechnic University, Pomona Phone: 909.869.6851 Cell: 909.260.3200 Fax: 909.979.6406 PGP Public Key: https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0x2FDBD1EADDC19329 -Original Message- From: Andrew Petro [mailto:ape...@wisc.edu] Sent: Friday, November 22, 2013 7:24 AM To: Tim Raymond; uportal-dev@lists.ja-sig.org Subject: Re: [uportal-dev] Tomcat won't start on Mac Tim, Have you given Tomcat more memory via a local setenv.sh ? If not, you almost certainly need to. There’s some documentation of how to do that here: https://wiki.jasig.org/display/UPM40/Installing+Tomcat Kind regards, Andrew --From: Tim Raymond Tim Raymond Reply: uportal-dev@lists.ja-sig.org uportal-dev@lists.ja-sig.org Date: November 22, 2013 at 9:20:19 AM To: uportal-dev@lists.ja-sig.org uportal-dev@lists.ja-sig.org Subject: [uportal-dev] Tomcat won't start on Mac Greetings. I am trying to get a local install on my Mac running Mavericks and I can't get tomcat to start. Executing startup.sh results in only displaying the usage for catalina.sh. Google is no help in this matter :(. Any ideas on a fix? BTW - I'm a noob (in case it wasn't totally obvious :) ) Thanks user$ ./startup.sh Using CATALINA_BASE: /Users/user/portal/apache-tomcat-7.0.42 Using CATALINA_HOME: /Users/user/portal/apache-tomcat-7.0.42 Using CATALINA_TMPDIR: /Users/user/portal/apache-tomcat-7.0.42/temp Using JRE_HOME: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home Using CLASSPATH: /Users/user/portal/apache-tomcat-7.0.42/bin/bootstrap.jar:/Users/user/p ortal/apache-tomcat-7.0.42/bin/tomcat-juli.jar Usage: catalina.sh ( commands ... ) commands: debug Start Catalina in a debugger debug -security Debug Catalina with a security manager jpda start Start Catalina under JPDA debugger run Start Catalina in the current window run -security Start in the current window with security manager start Start Catalina in a separate window start -security Start in a separate window with security manager stop Stop Catalina, waiting up to 5 seconds for the process to end stop n Stop Catalina, waiting up to n seconds for the process to end stop -force Stop Catalina, wait up to 5 seconds and then use kill -KILL if still running stop n -force Stop Catalina, wait up to n seconds and then use kill -KILL if still running configtest Run a basic syntax check on server.xml - check exit code for result version What version of tomcat are you running? Note: Waiting for the process to end and use of the -force option require that $CATALINA_PID is defined user$ Tim Raymond Director, Central Applications Instructional and Information Technology California State Polytechnic University, Pomona Phone: 909.869.6851 Cell: 909.260.3200 Fax: 909.979.6406 PGP Public Key: https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0x2FDBD1EADDC193 29 -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: ape...@wisc.edu 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] Bamboo failures
I recommend adding James Wennmacher ( jwennmac...@unicon.net ). Cris J H On 10/25/2013 07:13 AM, Jim Helwig wrote: I think I have the power but lack the knowledge. (Always a dangerous thing). Recommendations on who might best be in a position to be added to the admin list? Also, it seems there is a distinction between bamboo-admin and bamboo-plan-admin. Not sure what the difference is. JimH on 10/24/2013 9:24 AM Tim Levett said the following: I only have privs to run the builds. I do not have privs to configure them. On 10/23/2013 12:25 PM, James Wennmacher wrote: Tim L do you have the ability to modify Bamboo build settings? The issue on both the 4.0 and 4.1 builds is that maven is running out of PermGen during the build. Once we resolve this issue, we should document it on uPortal wiki as well. James Wennmacher - Unicon 480.558.2420 On 10/22/2013 11:32 PM, Jasig Bamboo wrote: Failed uPortal https://developer.jasig.org/bamboo/browse/UP/ › Trunk - Site https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE/ › #776 https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776/ failed Changes by 5 people https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776#changesSummary No failed tests found, a possible compilation error. Responsible No one is responsible for this build. Failing Jobs https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776/ Job Duration Tests Failed Default Job https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-JOB1-776/ (Default Stage) 15 minutes No tests found Logs https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-JOB1-776/log | Artifacts https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-JOB1-776/artifact Code Changes https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776/commit/ View all 23 code changes https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776/commit/ James Wennmacher https://developer.jasig.org/bamboo/browse/user/jameswennmacher Merge pull request #173 from shawnconnolly/UP-3792 https://developer.jasig.org/bamboo/project/jiraRedirect.action?jiraIssueKey=UP-3792bambooProjectKey=UP UP-3792 https://developer.jasig.org/bamboo/project/jiraRedirect.action?jiraIssueKey=UP-3792bambooProjectKey=UP: Adding functional add tab button to Respondr[d31bfa5_BAM_file_list] [d31bfa5_BAM_hash]5d593f3f288cbbb0926ed1966f867442afa859d9 [d31bfa5_BAM_commiter_name]Shawn Connolly [d31bfa5_BAM_commiter_email]sconno...@unicon.net mailto:sconno...@unicon.net [d31bfa5_BAM_timestamp]1382470611 [d31bfa5_BAM_commit_message]UP-3792 https://developer.jasig.org/bamboo/project/jiraRedirect.action?jiraIssueKey=UP-3792bambooProjectKey=UP: Adding functional add tab button 4262c3201642cb3191103ecdb892795b1314b474 James Wennmacher https://developer.jasig.org/bamboo/browse/user/jameswennmacher UP-3817 https://developer.jasig.org/bamboo/project/jiraRedirect.action?jiraIssueKey=UP-3817bambooProjectKey=UP (partial) Add Fluid to Respondr for admin portlets 8144f3a0f37455e164866f5e204451171ef874c5 Tim Levett https://developer.jasig.org/bamboo/browse/user/levett NOJIRA : Fix issue with master branch on local. Merge remote-tracking branch 'origin/master' 8216fa6b5f0020330f39951649c67c1c3e56de3d 20 more changes… https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776/commit View Online https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776 | Add Comments https://developer.jasig.org/bamboo/browse/UP-TRUNKSITE-776?commentMode=true This message was sent by Atlassian Bamboo https://developer.jasig.org/bamboo. If you wish to stop receiving these emails edit your user profile https://developer.jasig.org/bamboo/profile/userNotifications.action or notify your administrator https://developer.jasig.org/bamboo/viewAdministrators.action. -- You are currently subscribed touportal-...@lists.ja-sig.org as:jwennmac...@unicon.net To unsubscribe, change settings or access archives, seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed touportal-...@lists.ja-sig.org as:lev...@wisc.edu To unsubscribe, change settings or access archives, seehttp://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] voting for uPortal Committers
I don't want to derail the current vote. But after a couple of these proposals have come through I thought it was time to share a thought. Most of these votes I have had no basis to support an opinion on. Other then maybe the person who was doing the recommendation. In the future, it would be helpful if people could include an example or two of where the person has participated in some fashion. The best bet would be pull requests or patch files the person has produced. Lacking that, at least maybe some participation in jira or confluence. Just a suggestion. Without these things I'll just continue to watch the votes go by without being able to cast a vote one way or another. Cris J H -- 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] Enhancement to place (optionally) some config outside uPortal build/deploy process
Sakai uses a very similar approach and has very similar messages in
their logs. While uPortal could certainly do better, I don't think in
this case, it's anything to worry too much about. Especially when the
extremely simple fix is just to create an empty file for it to 'find' if
you're that concerned about clearing the log message out.
I think subclassing something from Spring will introduce more of a
maintenance task then it is worth. (e.g., if the next version of spring
adds a method to an interface, and suddenly the uportal class doesn't
compile)
Cris J H
On 01/23/2013 01:02 PM, Misagh Moayyed wrote:
Drew,
+1, this is very useful.
About the log entry, could we potentially circumvent the line by perhaps
writing a custom property configure that ignores the warning?
-Misagh
-Original Message-
From: bounce-26750363-57692...@lists.wisc.edu [mailto:bounce-26750363-
57692...@lists.wisc.edu] On Behalf Of Drew Wills
Sent: Wednesday, January 23, 2013 9:12 AM
To: uportal-dev@lists.ja-sig.org
Subject: [uportal-dev] Enhancement to place (optionally) some config
outside uPortal build/deploy process
Folks,
One of the ideas we discussed at the Unconference was an emphatic
suggestion from the SSP folks that uPortal should allow for placing
some configuration settings outside the uPortal webapp or outside
Tomcat altogether. This idea, furthermore, has come up before; I know
OHIO University brought it up when we were working with them.
I have a version of this enhancement working...
- https://gist.github.com/4608582
I would be delighted to:
- Whip up a JIRA
- Commit to master and rel-4-0-patches
- Update the uPortal Manual to document the use of this feature
There's one minor drawback I want to bring to light: the files are
100% optional but, as written, it puts the following in the log on
startup for each one that's not used...
WARN [main] o.s.c.s.PropertySourcesPlaceholderConfigurer 2013-01-23
08:41:54,293 - Could not load properties from URL
[file:/${PORTAL_HOME}/overrides.properties]:
\${PORTAL_HOME}\overrides.properties (The system cannot find the path
specified)
drew wills
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
mmoay...@unicon.net 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] Proposal: Remove $Revision$ from all source
I'm dealing with this every day in another project and it drives me bonkers. I vote not just for the $Revision$ keyword removal, but for ALL svn keywords to be removed. They are an annoyance when trying to diff. +1 even if this is limited to just the $Revision$ keyword. Cris J H On 04/10/2012 08:40 AM, Eric Dalquist wrote: After dealing with this in 'yet another diff' the $Revision$ CVS/SVN keyword is on my hit list. Anyone have any objections to doing a mass delete of that line in all files for 4.1? -Eric -- 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] Proposal: Remove $Revision$ from all source
4.1 vs. 4.0.x might depend on the timing of 4.1. If 4.1 was going to be released before the summer, then I'd definitely vote for waiting to do it there. But if 4.1 did not have an anticipated release date OR its release date was over 8 months (after Dec 2012) away then I'd vote for going ahead and doing it in 4.0.x. Cris J H On 04/10/2012 09:27 AM, Eric Dalquist wrote: I'm for this as well. I'll create a jira issue and schedule it to remove all the keywords. I was thinking 4.1 since it will this will touch all files and affect diffs but I'm thinking that people already have pain with diffs so doing this for the next 4.0 release might not be any more disruptive than the keywords already are. Thoughts on when we should do this? -Eric On 04/10/2012 11:06 AM, Cris J Holdorph wrote: I'm dealing with this every day in another project and it drives me bonkers. I vote not just for the $Revision$ keyword removal, but for ALL svn keywords to be removed. They are an annoyance when trying to diff. +1 even if this is limited to just the $Revision$ keyword. Cris J H On 04/10/2012 08:40 AM, Eric Dalquist wrote: After dealing with this in 'yet another diff' the $Revision$ CVS/SVN keyword is on my hit list. Anyone have any objections to doing a mass delete of that line in all files for 4.1? -Eric -- 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] Move uPortal source to GitHub Schedule
I got an email from github that said: View team: https://github.com/organizations/Jasig/teams/68892 but when I got there, I get a github 404. Any ideas? Cris J H On 10/13/2011 02:20 PM, Eric Dalquist wrote: Details of the uPortal SVN to GitHub migration, reasoning, and FAQ is in the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal I've done a final test migration of the uPortal SVN repository to: https://github.com/edalquist/uPortal-GitTest *Account Mapping* This is using best author mapping data that we could put together from those that explicitly have listed their git accounts [1] and account information for jasig SVN committers that was compiled from the Confluence/Jira services [2]. If you have ever commit to a Jasig project in the past and think you may ever commit to uPortal (or make a pull request) it would be great to have you setup a GitHub account and get the appropriate mapping information added to file [1]. [1] https://github.com/Jasig/svn2git-migration/blob/master/mappedAuthors.txt [2] https://github.com/Jasig/svn2git-migration/blob/master/resolvedAuthors.txt The following people currently have commit access to uPortal but have NOT yet setup an account on GitHub, meaning that their commit history won't transfer AND they won't be able to commit once we've moved. Please either email me your GitHub account info (should look like: Eric Dalquist eric.dalqu...@gmail.com) or event better, get to know git and fork https://github.com/Jasig/svn2git-migration add yourself to mappedAuthors.txt and then make a pull request. * Andrew Wills (awills) * Andy Gherna (agherna) * Anthony Colebourne (acolebourne) * Brad Szabo (bszabo) * Cris Holdorph (holdorph) * Gary Thompson (gthompson) * Lennard Fuller (lfuller) * Matthew Polizzotti (mpolizzo...@unicon.net) * Susan Bramhall (susan.bramh...@yale.edu) *Scheduling* 10/20 - Thursday 10:00am CDT - https://source.jasig.org/uPortal is made read-only 4:00pm CDT - https://github.com/Jasig/uPortal will be live and available for uPortal committers Unless there are objections the schedule will proceed as stated above. Realistically the GitHub repo should be available much earlier than 4pm but don't plan on making any commits to uPortal on Thursday 10/20 and if you have any work in progress make sure it is committed somewhere (create a temporary branch if needed) so that you don't have to re-apply the changes on the git side of things. -Eric -- 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] Move uPortal source to GitHub Schedule
I don't see any way to submit a pull request for https://github.com/Jasig/svn2git-migration Cris J H ps. I tried to do it the github way, but in any case, my github email address was/is holdo...@unicon.net On 10/13/2011 03:51 PM, Eric Dalquist wrote: Thought I had found a few people by guessing usernames but the accounts didn't have enough publicly available info for me to verify. So that email was likely from being added and then removed from the team. I'll still need the Full Name github@email.address string for the conversion if you care about commit history. -Eric On 10/13/11 5:06 PM, Cris J Holdorph wrote: I got an email from github that said: View team: https://github.com/organizations/Jasig/teams/68892 but when I got there, I get a github 404. Any ideas? Cris J H On 10/13/2011 02:20 PM, Eric Dalquist wrote: Details of the uPortal SVN to GitHub migration, reasoning, and FAQ is in the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal I've done a final test migration of the uPortal SVN repository to: https://github.com/edalquist/uPortal-GitTest *Account Mapping* This is using best author mapping data that we could put together from those that explicitly have listed their git accounts [1] and account information for jasig SVN committers that was compiled from the Confluence/Jira services [2]. If you have ever commit to a Jasig project in the past and think you may ever commit to uPortal (or make a pull request) it would be great to have you setup a GitHub account and get the appropriate mapping information added to file [1]. [1] https://github.com/Jasig/svn2git-migration/blob/master/mappedAuthors.txt [2] https://github.com/Jasig/svn2git-migration/blob/master/resolvedAuthors.txt The following people currently have commit access to uPortal but have NOT yet setup an account on GitHub, meaning that their commit history won't transfer AND they won't be able to commit once we've moved. Please either email me your GitHub account info (should look like: Eric Dalquist eric.dalqu...@gmail.com) or event better, get to know git and fork https://github.com/Jasig/svn2git-migration add yourself to mappedAuthors.txt and then make a pull request. * Andrew Wills (awills) * Andy Gherna (agherna) * Anthony Colebourne (acolebourne) * Brad Szabo (bszabo) * Cris Holdorph (holdorph) * Gary Thompson (gthompson) * Lennard Fuller (lfuller) * Matthew Polizzotti (mpolizzo...@unicon.net) * Susan Bramhall (susan.bramh...@yale.edu) *Scheduling* 10/20 - Thursday 10:00am CDT - https://source.jasig.org/uPortal is made read-only 4:00pm CDT - https://github.com/Jasig/uPortal will be live and available for uPortal committers Unless there are objections the schedule will proceed as stated above. Realistically the GitHub repo should be available much earlier than 4pm but don't plan on making any commits to uPortal on Thursday 10/20 and if you have any work in progress make sure it is committed somewhere (create a temporary branch if needed) so that you don't have to re-apply the changes on the git side of things. -Eric -- 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] Move uPortal source to GitHub Schedule
I followed those instructions before I sent my message. However, there are two problems. One, it's not clear that you have to do the pull request from your fork. If you're viewing the original repository, you see a 'pull requests' tab, and so as a NEW UNFAMILIAR user, you might be there, click on that tab, see the 'list' of requests (or empty list) and not know how to submit one. You must be on your own repo fork, but that's not clear in those instructions. Two, even when you get to your own repo and find the right screen to submit a pull request, you end up at this screen: http://img.skitch.com/20100831-qit9sjhuqk42t4ww91ifm5tm81.png Except in your case those two text fields will be blank, with NO indication what information should go in those text fields and no mention in the instructions about what should go in there. I guessed and submitted mine, but I had no idea if it would even work, when I pressed the 'send pull request' button. Cris J H On 10/13/2011 04:28 PM, Eric Dalquist wrote: The Step-by-step (the short version) section here https://github.com/diaspora/diaspora/wiki/Git-Workflow has good info, for something as simple as this you can skip a bunch of the steps (setting upstream remote and creating dev branch) and boil it down to: 1. Fork on GitHub (click Fork button) 2. Clone to computer ($ git clone g...@github.com:you/diaspora.git ) 3. Don’t forget to cd into your repo: ($ cd diaspora/ ) 4. Make changes// 5. Commit changes to issue branch. ($ git add . ; git commit -m ‘commit message’) 6. Push branch to GitHub ($ git push) 7. Issue pull request (Click Pull Request button) Post migration I'm going to be encouraging people to follow the full set of steps and do all development on branches. That should let everyone get the work they are doing out into a visible location earlier in the development cycle and keep trunk (master) more stable. -Eric On 10/13/11 6:12 PM, Cris J Holdorph wrote: I don't see any way to submit a pull request for https://github.com/Jasig/svn2git-migration Cris J H ps. I tried to do it the github way, but in any case, my github email address was/is holdo...@unicon.net On 10/13/2011 03:51 PM, Eric Dalquist wrote: Thought I had found a few people by guessing usernames but the accounts didn't have enough publicly available info for me to verify. So that email was likely from being added and then removed from the team. I'll still need the Full Name github@email.address string for the conversion if you care about commit history. -Eric On 10/13/11 5:06 PM, Cris J Holdorph wrote: I got an email from github that said: View team: https://github.com/organizations/Jasig/teams/68892 but when I got there, I get a github 404. Any ideas? Cris J H On 10/13/2011 02:20 PM, Eric Dalquist wrote: Details of the uPortal SVN to GitHub migration, reasoning, and FAQ is in the wiki: https://wiki.jasig.org/display/UPC/Git+Migration+Proposal I've done a final test migration of the uPortal SVN repository to: https://github.com/edalquist/uPortal-GitTest *Account Mapping* This is using best author mapping data that we could put together from those that explicitly have listed their git accounts [1] and account information for jasig SVN committers that was compiled from the Confluence/Jira services [2]. If you have ever commit to a Jasig project in the past and think you may ever commit to uPortal (or make a pull request) it would be great to have you setup a GitHub account and get the appropriate mapping information added to file [1]. [1] https://github.com/Jasig/svn2git-migration/blob/master/mappedAuthors.txt [2] https://github.com/Jasig/svn2git-migration/blob/master/resolvedAuthors.txt The following people currently have commit access to uPortal but have NOT yet setup an account on GitHub, meaning that their commit history won't transfer AND they won't be able to commit once we've moved. Please either email me your GitHub account info (should look like: Eric Dalquist eric.dalqu...@gmail.com) or event better, get to know git and fork https://github.com/Jasig/svn2git-migration add yourself to mappedAuthors.txt and then make a pull request. * Andrew Wills (awills) * Andy Gherna (agherna) * Anthony Colebourne (acolebourne) * Brad Szabo (bszabo) * Cris Holdorph (holdorph) * Gary Thompson (gthompson) * Lennard Fuller (lfuller) * Matthew Polizzotti (mpolizzo...@unicon.net) * Susan Bramhall (susan.bramh...@yale.edu) *Scheduling* 10/20 - Thursday 10:00am CDT - https://source.jasig.org/uPortal is made read-only 4:00pm CDT - https://github.com/Jasig/uPortal will be live and available for uPortal committers Unless there are objections the schedule will proceed as stated above. Realistically the GitHub repo should be available much earlier than 4pm but don't plan on making any commits to uPortal on Thursday 10/20 and if you have any work in progress make sure it is committed somewhere (create a temporary branch
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
+/- 0 I think making this change so soon after the uPortal 4.0.0 release, is a mistake. I think it would be better to let that release simmer for a while to shake out if there were any major problems. If this vote was to take place in a month, or at least 2 weeks after some university was running uPortal 4.0.0 in production, then my vote might be different. Cris J H On 08/31/2011 12:26 PM, Eric Dalquist wrote: I'd like to see uPortal's source code moved to git and hosted on GitHub. There have been quite a few folks that have been working on uPortal 4, uMobile or are otherwise interested that have asked about using git. After looking into it a bit more I think it would be a very valuable change for uPortal. For those not familiar Git is a _distributed_ source control tool. What that means is there is no true central repository like there is with SVN. Developers don't really checkout some version of the code, they clone the entire project when doing work. That doesn't prevent the convention of a central repository which is what a site like GitHub provides. A place to host a clone of the project that by convention we agree is the master copy of the project. GitHub adds some very nice social-coding aspects to git. Primarily it provides a VERY easy interface that allows anyone to clone a project, make changes and commit them to their clone, then make a pull request on the master project. Once that has happened a simple click of a button is all it takes for any developer with commit access on the master to accept the changes and merge them in. This process makes it very easy for people without direct commit access to commit changes that are reviewed by a core developer before merging in and significantly simplifies the work of the core developers. When there was first talk among about switching I solicited feedback from the Fluid project which recently moved from SVN to Git. I highly recommend reading the resulting thread which highlights a lot of the pros and cons http://old.nabble.com/Perspectives-on-Git-td31852449.html There is an eclipse Git Plugin, a TortiseGit client which is a clone of TortiseSVN and I believe most other IDEs have either built in or plugin support for git. Some other useful links: Git for those without Version Control background - http://hoth.entp.com/output/git_for_designers.html GitHub's wonderful help documentation - http://help.github.com/ TortiseGit - http://code.google.com/p/tortoisegit/ Some questions that I can try and answer before they come up: - The uPortal code in svn at source.jasig.org would likely be left in place, we would just make the entire /uPortal directory read-only - We're going to filter out the documentation and website files that were included in early versions of uPortal 2 to reduce the project repository size. Since this is a big change (and since I'm going on vacation for 2 weeks starting Friday) I'm planning on leaving this vote open for a while. +1, 0, -1 to vote and if you vote -1 you need to include a detailed reasoning for your -1 vote. -Eric -- 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] [VOTE] Move uPortal source to GitHub
Call me pessimistic, but... there seem to be two givens in the world of software that concern me with this change at this time. 1) a .0 release is notoriously not perfect and is usually followed on very quickly by a .1 release shortly after to fix some glaring bug that will prevent most people from using it. 2) switching to a new source code control system is a slow process that takes a while to get over all the hurdles of process, development, migration, etc. So, there's no guarantee either one of these would be true for uportal, but... if they were. Then we could be in a situation where we're unable to produce a critically needed 4.0.1 release, because we're not completely up to development speed on git. For example, what if there is an import/export bug, you want Drew Wills to fix. He's the best guy for the job. If the code was still in svn, he probably still has a checkout of it and he can take a look at it today. But if the code only exists in git, he might not have gotten around to doing anything with git yet. Even the github svn url you can use, would still require him changing his environment. My 'vote' was 0. Basically I'm saying I won't stand in the way of it happening, but I don't believe the time is right to fully support it right now either. Cris J H On 08/31/2011 02:05 PM, Eric Dalquist wrote: I'm curious as yo why the concern about the closeness to the 4.0 release? I was actually thinking that doing the switch as soon as possible after 4.0 would be better as it would give more time for developers to get used to the change before a 4.0.1 is needed. -Eric On 8/31/11 3:05 PM, Cris J Holdorph wrote: +/- 0 I think making this change so soon after the uPortal 4.0.0 release, is a mistake. I think it would be better to let that release simmer for a while to shake out if there were any major problems. If this vote was to take place in a month, or at least 2 weeks after some university was running uPortal 4.0.0 in production, then my vote might be different. Cris J H On 08/31/2011 12:26 PM, Eric Dalquist wrote: I'd like to see uPortal's source code moved to git and hosted on GitHub. There have been quite a few folks that have been working on uPortal 4, uMobile or are otherwise interested that have asked about using git. After looking into it a bit more I think it would be a very valuable change for uPortal. For those not familiar Git is a _distributed_ source control tool. What that means is there is no true central repository like there is with SVN. Developers don't really checkout some version of the code, they clone the entire project when doing work. That doesn't prevent the convention of a central repository which is what a site like GitHub provides. A place to host a clone of the project that by convention we agree is the master copy of the project. GitHub adds some very nice social-coding aspects to git. Primarily it provides a VERY easy interface that allows anyone to clone a project, make changes and commit them to their clone, then make a pull request on the master project. Once that has happened a simple click of a button is all it takes for any developer with commit access on the master to accept the changes and merge them in. This process makes it very easy for people without direct commit access to commit changes that are reviewed by a core developer before merging in and significantly simplifies the work of the core developers. When there was first talk among about switching I solicited feedback from the Fluid project which recently moved from SVN to Git. I highly recommend reading the resulting thread which highlights a lot of the pros and cons http://old.nabble.com/Perspectives-on-Git-td31852449.html There is an eclipse Git Plugin, a TortiseGit client which is a clone of TortiseSVN and I believe most other IDEs have either built in or plugin support for git. Some other useful links: Git for those without Version Control background - http://hoth.entp.com/output/git_for_designers.html GitHub's wonderful help documentation - http://help.github.com/ TortiseGit - http://code.google.com/p/tortoisegit/ Some questions that I can try and answer before they come up: - The uPortal code in svn at source.jasig.org would likely be left in place, we would just make the entire /uPortal directory read-only - We're going to filter out the documentation and website files that were included in early versions of uPortal 2 to reduce the project repository size. Since this is a big change (and since I'm going on vacation for 2 weeks starting Friday) I'm planning on leaving this vote open for a while. +1, 0, -1 to vote and if you vote -1 you need to include a detailed reasoning for your -1 vote. -Eric -- 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] uPortal 4 Release Schedule
minus custom ichannel support. So, if you have custom ichannels and do an export, those channels will not import into uPortal 4.0+ Cris J H On 05/05/2011 05:02 PM, Eric Dalquist wrote: 3.3 == 4.0 Just like you said, we decided that with so much work being done in 3.3, primarily around removing IChannel support, it would be better to jump a major version to 4.0 We are still planning complete support for data migration with the goal of being able to export from 2.5, 2.6, 3.0, 3.1, or 3.2 and import that data into 4.0 -Eric On 5/5/11 6:18 PM, Steve Swinsburg wrote: Hi Eric, How does uPortal 4 compare with uPortal 3.3? Is it because there was a lot of work in 3.3 that it was decided to be a major release, aka uPortal 4? cheers, Steve On 06/05/2011, at 4:28 AM, Eric Dalquist wrote: Well due to the time-sucking wonders that was a state-wide HR system upgrade I lost a big chunk of time for uPortal 4 work. Just to keep everyone here in the loop the current plan is to do a uPortal 4.0.0-M2 on 5/9 and then get the RC1 cut right before the conference. So if you have new-feature work that you have planned for uPortal 4 please plan on trying to have it complete by 5/18. Thanks! -Eric -- 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] Rename entity files to entity.type.xml
If you're going to rename them, is there a significant reason to even leave the '.channel' in the middle? To me this always felt like an unneeded complication when the 'type' was in the XML content to begin with. And in the case of uPortals own set of entity files it has them in subdirectories. So we had the type in THREE places (filename, directory name, xml content). Cris J H On 03/15/2011 05:30 PM, Drew Wills wrote: +1 This is a good practice -- I agree completely. drew On 3/14/2011 5:46 PM, Eric Dalquist wrote: renaming the entity files in trunk by adding .xml to the end? So IdentitySwapper.channel would become IdentitySwapper.channel.xml I think it might back life a little easier if editors recognize these files as XML by default. -- 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] Rename entity files to entity.type.xml
Having information required in the 'middle' of a filename is very non-standard. So, if we can't remove it at all, then I guess I am not in favor of renaming them at all. Seeing foo.channel I'm more inclined to think I have to keep the file named *.channel. If I see a file named foo.channel.xml, I might assume I can change everything but the .xml extension. Especially when you consider the redundancies in the other places. Cris J H On 03/21/2011 02:00 PM, Eric Dalquist wrote: If we remove it we would have to do one of two things. 1. Absolutely require the directory structure currently in use be used ALL the time. 2. Parse all the XML files twice, once to determine the root element and sort the data files then again to do the import. The order that the data is imported is VERY important and the primary use of those secondary extensions. Eric On 3/21/11 3:47 PM, Cris J Holdorph wrote: If you're going to rename them, is there a significant reason to even leave the '.channel' in the middle? To me this always felt like an unneeded complication when the 'type' was in the XML content to begin with. And in the case of uPortals own set of entity files it has them in subdirectories. So we had the type in THREE places (filename, directory name, xml content). Cris J H On 03/15/2011 05:30 PM, Drew Wills wrote: +1 This is a good practice -- I agree completely. drew On 3/14/2011 5:46 PM, Eric Dalquist wrote: renaming the entity files in trunk by adding .xml to the end? So IdentitySwapper.channel would become IdentitySwapper.channel.xml I think it might back life a little easier if editors recognize these files as XML by default. -- 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] Two New Project
Can you describe why you want to use JSF? Cris J H On 11/22/2010 08:59 AM, Frédéric Ravetier wrote: Hello, I am the project manager for the ESUP Mobile Project, working at Anyware-Services. We started the development last week. Our first portlet is a portlet to display messages (email from an IMAP server that is under CAS). Note that most of the ESUP portlet are using JSF (which is a real difficulty to use the taglib WNG from Wurfl with JSF). Also the goal is to have a multi-channel portlet (available to display data on mobile and desktop). Our strategy is: 1- to develop a web portlet with a default and simple skin (based on JSF) 2- build a filter (tomcat filter) based on WURFL to detect if the user is using a mobile or a desktop browser 3- make a mechanism to choose the JSP depending of the detection (mobile to use WNG taglib - from WURFL - or desktop to use classic JSF taglib) 4- modify the WNG taglib to work in an JSF environment. The last step may failed or may be too hard or too complicate to maintain. In this case we will reduce our constraints and we will use another taglib to render data to mobile. We already think about Trinidad. If you have suggestion I am open to them. We'd like to avoid framework or library that are only webkit compatible, because we'd like to support many mobile browsers and not only iphone and smartphone. It is a wish that can be reduce depending on the complexity and the maintainability. Why WURFL, because it is THE taglib known by most of the mobile developers that want a real compatibility with most of the mobiles. We are currently at step 2. We made the step 1 with some small doubt on step 1 because of the CAS environment, we do not have an IMAP that support CAS here. Do you have suggestions? Do you have others informations? Do not hesitate to contact me in order to have more information or to share some knowledge. Then we will have some others portlet to enhance or to develop (Calendar, Directory based on LDAP, news, ...) Let me know if you prefer another discussion channel than this one. Sincerely, Frédéric Ravetier Project Manager Anyware-Services (www.anyware-services.com) frederic.ravet...@anyware-services.com Phone: +33 5 62 19 19 03 Ametys: The CMS Java Open Source www.ametys.org Le 22/11/2010 16:03, Jonathan Markow a écrit : I recently had a conversation with Alain Mayeur, director of ESUP Portail, the nation-wide consortium of French universities that have developed a Digital Work Space based on uPortal, CAS, and a host of other open source applications that they have developed or integrated. Alain told me about two projects currently underway that are of interest to Jasig. The first one is the ESUP Mobile Project. With several participating universities, this project is working to coordinate the development of mobile services supported by the mobile framework in uPortal 3.2. The wiki page for the project (in French) is located at http://www.esup-portail.org/display/PROJESUPMOBILE/Projet+ESUP+Mobile. A second project, also the result of a collaboration among several organizations, is designed to enhance the content management capabilities of uPortal. Alain will ask the project leads to send us more information about these initiatives. I am hoping there might be some areas in which Jasig developers would be able to contribute. -Jonathan -- You are currently subscribed touportal-...@lists.ja-sig.org as:frederic.ravet...@anyware-services.com To unsubscribe, change settings or access archives, seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: holdo...@unicon.net 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] Two New Project
It is a question, because no other Jasig project, currently in Jasig subversion, uses JSF to my knowledge. So it's harder to share code/techniques between any existing Jasig work and this project. There is a lot of work already done for Mobile in Jasig, but not of it uses or works with JSF. I'll let someone who is more familiar with the current Jasig mobile work comment on what was used. Cris J H On 11/22/2010 09:46 AM, Frédéric Ravetier wrote: It is not really a choice, we have to use it because most of the existing portlets used by the ESUP community are based on JSF. And because we will have to enhance some of them to add the mobile view we have to do with it. In this way the people working on this community will be able to follow our guideline to enhance them portlets. Obviously if it is a big problem to add mobile view we will have to suggest them something else. Otherwise we would have choice something else because it is not our favorite Framework. Why this question? Regards, Fred Le 22/11/2010 17:05, Cris J Holdorph a écrit : Can you describe why you want to use JSF? Cris J H On 11/22/2010 08:59 AM, Frédéric Ravetier wrote: Hello, I am the project manager for the ESUP Mobile Project, working at Anyware-Services. We started the development last week. Our first portlet is a portlet to display messages (email from an IMAP server that is under CAS). Note that most of the ESUP portlet are using JSF (which is a real difficulty to use the taglib WNG from Wurfl with JSF). Also the goal is to have a multi-channel portlet (available to display data on mobile and desktop). Our strategy is: 1- to develop a web portlet with a default and simple skin (based on JSF) 2- build a filter (tomcat filter) based on WURFL to detect if the user is using a mobile or a desktop browser 3- make a mechanism to choose the JSP depending of the detection (mobile to use WNG taglib - from WURFL - or desktop to use classic JSF taglib) 4- modify the WNG taglib to work in an JSF environment. The last step may failed or may be too hard or too complicate to maintain. In this case we will reduce our constraints and we will use another taglib to render data to mobile. We already think about Trinidad. If you have suggestion I am open to them. We'd like to avoid framework or library that are only webkit compatible, because we'd like to support many mobile browsers and not only iphone and smartphone. It is a wish that can be reduce depending on the complexity and the maintainability. Why WURFL, because it is THE taglib known by most of the mobile developers that want a real compatibility with most of the mobiles. We are currently at step 2. We made the step 1 with some small doubt on step 1 because of the CAS environment, we do not have an IMAP that support CAS here. Do you have suggestions? Do you have others informations? Do not hesitate to contact me in order to have more information or to share some knowledge. Then we will have some others portlet to enhance or to develop (Calendar, Directory based on LDAP, news, ...) Let me know if you prefer another discussion channel than this one. Sincerely, Frédéric Ravetier Project Manager Anyware-Services (www.anyware-services.com) frederic.ravet...@anyware-services.com Phone: +33 5 62 19 19 03 Ametys: The CMS Java Open Source www.ametys.org Le 22/11/2010 16:03, Jonathan Markow a écrit : I recently had a conversation with Alain Mayeur, director of ESUP Portail, the nation-wide consortium of French universities that have developed a Digital Work Space based on uPortal, CAS, and a host of other open source applications that they have developed or integrated. Alain told me about two projects currently underway that are of interest to Jasig. The first one is the ESUP Mobile Project. With several participating universities, this project is working to coordinate the development of mobile services supported by the mobile framework in uPortal 3.2. The wiki page for the project (in French) is located at http://www.esup-portail.org/display/PROJESUPMOBILE/Projet+ESUP+Mobile. A second project, also the result of a collaboration among several organizations, is designed to enhance the content management capabilities of uPortal. Alain will ask the project leads to send us more information about these initiatives. I am hoping there might be some areas in which Jasig developers would be able to contribute. -Jonathan -- You are currently subscribed touportal-...@lists.ja-sig.org as:frederic.ravet...@anyware-services.com To unsubscribe, change settings or access archives, seehttp://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: holdo...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- http://www.anyware-services.com www.anyware-services.com http://www.anyware-services.com *Frédéric Ravetier* Chef de projet
Re: [uportal-dev] Bug in RDBMDistributedLayoutStore.java in uPortal 3.2.2
I fixed it in 3.2.x and trunk. It did not seem to be present in 3.1.
I'll take a look at 3.0.x today, I don't remember if I checked that
branch or not.
Cris J H
On 08/06/2010 08:55 PM, Eric Dalquist wrote:
That is a very good catch and is a bug. Are you able to take care of
getting that fixed? I think it affect trunk, 3.2, 3.1 and 3.0
-Eric
On 8/6/10 1:19 PM, Cris J Holdorph wrote:
Please take a look at uPortal 3.2.2 the file:
uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java
Specifically lines 1893-1903...
They look like this:
final ResultSet rs2 = pstmt2.executeQuery();
try {
while (rs2.next()) {
String pName = rs.getString(1);
if (tsd.containsParameterName(pName))
tsup.putParameterValue(pName, rs2.getString(2));
}
}
finally {
close(rs2);
}
Shouldn't the 'rs.getString(1)' be 'rs2.getString(1)' instead? I'm
changing this and checking it in as a fix to UP-2781. However, I would
like feedback from whomever might have made the changes, to be sure
I'm not missing something.
Cris J H
--
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] question on fisheye
Did you go to the page I mentioned? Those revisions don't show up in that list. I tried going to the first link you gave, and the page never finished rendering for me. Cris J H On 08/06/2010 08:56 PM, Eric Dalquist wrote: What are you looking for? Here are the revisions mentioned in the log: https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21106 https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21102 https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21023 -Eric On 8/6/10 12:52 PM, Cris J Holdorph wrote: I was looking at a bug Unicon ran across trying to upgrade someone from uPortal 3.2.1 to 3.2.2. In tracking this bug down, I noticed that the svn log information did not match fisheye. compare this URL in a browser https://developer.jasig.org/source/browse/jasigsvn/uPortal/branches/rel-3-2-patches/uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java to running this command from the command line svn log https://source.jasig.org/uPortal/branches/rel-3-2-patches/uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java the svn log command shows revisions like: r21106 | edalquist | 2010-07-16 09:17:37 -0700 (Fri, 16 Jul 2010) | 4 lines r21102 | edalquist | 2010-07-16 10:56:15 CDT UP-2630 Cleanup some direct JDBC code to reduce leaking cursors r21023 | edalquist | 2010-07-07 12:24:46 -0700 (Wed, 07 Jul 2010) | 1 line that do not show up in fisheye (at least as of Friday, Aug 6, around noon Pacific time). Cris J H -- 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] SmartLdap thread leak
What do you mean it will leak the refresh thread? Won't the thread complete and then die? I didn't think the thread lived on forever, but only for as long as it took to refresh the group tree one time. But I agree, if quartz is available, that's what quartz is good at and I'd strongly advocate for using it instead. I'm not sure how I missed knowing that got added to uPortal in the past. *shrug* Now I do. Cris J H On 08/06/2010 10:59 AM, Eric Dalquist wrote: The change set for SmartLdap will leak the refresh thread when the portal webapp is reloaded. If possible this refresh process should be a periodic trigger managed by the quartz scheduler that already exists in 3.x. Using the schedule guarantees correct thread handling and configuration level manageability of the refresh rate. https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21422 -Eric -- 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] SmartLdap thread leak
You imply to use Quartz you'd have to modify multiple config files. Until this email thread I didn't even know quartz was available. Now knowing that it is, why does there have to be multiple config files involved. Can't SmartLdap register a task with the quartz system on it's own? It doesn't seem like you should have to modify only the quartz config files to add new jobs/tasks. Now, in case there's some reason you can't register out of context a new job. And you must configure it separately. I think a counter point to your logic though, is why should someone have to edit multiple places to change all of the time based tasks? Wouldn't it be useful to have all of the time based configuration in the one quartz subsystem? Cris J H On 08/06/2010 11:34 AM, Drew Wills wrote: On 8/6/2010 11:10 AM, Cris J Holdorph wrote: What do you mean it will leak the refresh thread? Won't the thread complete and then die? I didn't think the thread lived on forever, but only for as long as it took to refresh the group tree one time. This is my understanding as well -- the thread completes dies. It's a daemon thread, moreover, so it won't interfere with shutting down the JVM. But I agree, if quartz is available, that's what quartz is good at and I'd strongly advocate for using it instead. I'm not sure how I missed knowing that got added to uPortal in the past. *shrug* Now I do. So... I like Quartz too. I understand these points, and I considered setting it up with the scheduler right off the bat. But I had some counter-points in mind too, which led me to think we might be better off with the alternative. SmartLdap is an optional component of uPortal. It's used by a minority of deployments. I dislike it when (and I think new adopters find it intimidating when) it takes changes in 2-3 separate config files to turn on 1 logical option. We actually have several components where this is the case. Consider the CacheSecurityContext/password replay tech: https://wiki.jasig.org/x/EIq8AQ Enabling this (one) option requires changes to 3 files: - security.properties - portletContainerContext.xml - securityContext.xml Actually the last of these wasn't even documented until the other day, when a new colleague of mine discovered that the documented steps for enabling this feature weren't working. To me, the tree-refresh feature of SmartLdap isn't something that needs to be complicated. You can configure how frequently it happens or shut it off entirely... all in the same file in which you configure the rest of it. There's even a sensible default behavior, so if you just drop your config from an earlier version into the new version, SmartLdap doesn't care and will do something reasonable. So then... I'm ok with changing it per Eric's suggestions. I'm happy for the uP devs to consider the question, form a consensus, and take action. I'd actually love to see more contributors in the code. But I wanted to make it clear: - (1) I don't believe it leaks threads; and - (2) The current setup was a conscious, reasoned choice, not an oversight or omission drew wills Cris J H On 08/06/2010 10:59 AM, Eric Dalquist wrote: The change set for SmartLdap will leak the refresh thread when the portal webapp is reloaded. If possible this refresh process should be a periodic trigger managed by the quartz scheduler that already exists in 3.x. Using the schedule guarantees correct thread handling and configuration level manageability of the refresh rate. https://developer.jasig.org/source/changelog/jasigsvn/uPortal?cs=21422 -Eric -- 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] question on fisheye
I was looking at a bug Unicon ran across trying to upgrade someone from uPortal 3.2.1 to 3.2.2. In tracking this bug down, I noticed that the svn log information did not match fisheye. compare this URL in a browser https://developer.jasig.org/source/browse/jasigsvn/uPortal/branches/rel-3-2-patches/uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java to running this command from the command line svn log https://source.jasig.org/uPortal/branches/rel-3-2-patches/uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java the svn log command shows revisions like: r21106 | edalquist | 2010-07-16 09:17:37 -0700 (Fri, 16 Jul 2010) | 4 lines r21102 | edalquist | 2010-07-16 10:56:15 CDT UP-2630 Cleanup some direct JDBC code to reduce leaking cursors r21023 | edalquist | 2010-07-07 12:24:46 -0700 (Wed, 07 Jul 2010) | 1 line that do not show up in fisheye (at least as of Friday, Aug 6, around noon Pacific time). Cris J H -- 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] Bug in RDBMDistributedLayoutStore.java in uPortal 3.2.2
Please take a look at uPortal 3.2.2 the file:
uportal-impl/src/main/java/org/jasig/portal/layout/dlm/RDBMDistributedLayoutStore.java
Specifically lines 1893-1903...
They look like this:
final ResultSet rs2 = pstmt2.executeQuery();
try {
while (rs2.next()) {
String pName = rs.getString(1);
if (tsd.containsParameterName(pName))
tsup.putParameterValue(pName,
rs2.getString(2));
}
}
finally {
close(rs2);
}
Shouldn't the 'rs.getString(1)' be 'rs2.getString(1)' instead? I'm
changing this and checking it in as a fix to UP-2781. However, I would
like feedback from whomever might have made the changes, to be sure I'm
not missing something.
Cris J H
--
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] VM Specs???
This probably belongs on uportal-user. The 'uportal-dev' list is for discussion of changes to the core uPortal framework code base. If you create a new post on uPortal-user, can you describe how your users might use the portal? Will they single-click in, and then leave the portal. Do you expect them to spend large amounts of time in the portal, using an interactive application like email? Those two extremes really change things a lot. Cris J H On 06/30/2010 11:24 AM, John A Parker wrote: Just me asking (rather than looking it up of course!) what the consensus might be for... - Sizing a 64bit RHEL5 VM to optimally run uPortal 3.2.1 (memory, CPUs, swap space, etc...)? - One big VM or multiple, smaller load balanced VMs? - Any data on per-user incremental load? (1 user ... 2 users ... n users ... ?) - Performance numbers for the above or variations of? THANKS IN ADVANCE!!! John P.S. We'll contribute to this area of interest once we have data to report. -- 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] contribution - how to?
I think it would be worth attaching the 3.1 patch to the Jira issue, so anyone who wants access to the feature sooner could grab it for their own system. Cris J H On 06/15/2010 11:34 AM, Eric Dalquist wrote: That is the way to go. Generally the following steps should work well: 1. Check out trunk 2. Get your patch applied 3. Update to the latest code from trunk, fixing any merge issues 4. Create patch in unified diff format (eclipse makes this very easy) 5. Post patch to Jira issue. Now you are a uPortal committer https://wiki.jasig.org/display/UPC/Committers so you can skip steps 4 5. Once you have the patch working commit it. If you'd like more eyes on it after that just email here again and ask folks to take a look! -Eric On 6/15/10 1:11 PM, Susan Bramhall wrote: Yale has implemented code in uPortal to allow users to subscribe and unsubscribe to entire fragments (tabs). I did a poster session demonstrating the feature at the conference and I believe it would be a welcome enhancement. We would like to contribute the code and documentation for it back to the uPortal project but I am not sure how. I could develop a patch against 3.1 (which is what we are running) but since it's an entirely new feature it can't go into 3.1 or 3.2. If I develop a patch against the trunk it would have to be against a specific version. Is that the way to go? Thanks. Susan -- Susan Bramhall (susan.bramh...@yale.edu mailto:susan.bramh...@yale.edu) Senior Developer, Infrastructure Systems and Architecture Yale University Information Technology Services (ITS) 25 Science Park, 150 Munson St, New Haven, CT 06520 Phone: 203 432 6697 -- You are currently subscribed touportal-...@lists.ja-sig.org as:eric.dalqu...@doit.wisc.edu To unsubscribe, change settings or access archives, seehttp://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] issues with portlets in trunk build
Unicon News, is broken in uPortal 3.2.x. This is documented with UP-2704 Cris J H Gary Weaver wrote: Some issues seen from cursory browsing of default uPortal trunk build currently: In News section: * uPortal-Powered Sites (error: This channel failed to accept needed data) * Unicon News (error: This channel failed to initialize) In Development section: * CSS View (error: Channel failed to accept runtime data (code 3)) * uPortal Data Dictionary (error: Channel failed to render (code 1)) * When attempting to run manual tests on test portlet #1/#2, get stuck after choosing edit/help mode because no way to undo mode switch that I can find In Admin section: * In Portal Administration, admin user not able to view Password Management (error: User not authorized (code 6)) * In Portal Administration, manage portlets, it says: Loading Information Please wait while the system finishes loading the portlet registry. but never finishes. There was an error I think, but I didn't know how to reload the portlet without restarting Tomcat, so I moved on in testing. * In Portal Administration, manage groups, I chose Channel Categories, clicked next, and clicked next again without filling anything in, and it broke the portlet (error: General rendering problem): An OgnlException occurred getting the value for expression 'groupAdministrationHelper.getGroupForm(selectedGroups.get(0).getId())' on context [class org.springframework.webflow.engine.impl.RequestControlContextImpl]...Caused by: ognl.MethodFailedException: Method get failed for object [] [java.lang.IndexOutOfBoundsException: Index: 0] * In Portal Administration, manage permissions, I clicked View - assign to a new target - left target blank and clicked submit and it broke the portlet (error: Channel failed to render (code 1)): An OgnlException occurred getting the value for expression 'permissionAdministrationHelper.getForm(owner, activity, requestParameters.target)' on context [class org.springframework.webflow.engine.impl.RequestControlContextImpl], originalValue = [null], mappedValue = [null]]] - that error happened in a few places (uPortal Error Channel, uPortal Groups) but didn't happen in Manage Expired with similar use case. * Import Export Portlet - left field empty and clicked Import button (error: Channel failed to render (code 1)) Cosmetic only: In Admin section: * In Portal Administration, manage groups shows bullets followed by radio buttons. Bullets seem unnecessary. * ImportExportPortlet sometimes has ImportExportPortlet as title and sometimes Import Export Portlet -- 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] pre-commit hook re: svn:mime-type preventing commit
Did you do the subversion add from the command line or from eclipse? If from eclipse, does anyone know if subclipse will use/pick up those parts of the subversion config file? Cris J H Nicholas Blair wrote: I have the uportal subversion config file from http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Subversion+Configuration in my .subversion directory (Eclipse Galileo, latest subclipse plugin, ubuntu karmic workstation), but every time I try to commit a new file I get the following message copied at the bottom of this message. It doesn't seem to be an issue for commits on existing files, only on new files. I looked at the svn properties for the file in question, and the following exist: svn:eol-style native svn:keywords Date Revision Author HeadURL Id These properties match values on other files in the same directory. Any ideas Error message below: Transmitting file data ... A repository hook failed svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Running /jasig/tools/subversion/subversion/bin/svnlook changed /jasig/svn/jasig -t 48014-1 Running /jasig/tools/subversion/subversion/bin/svnlook proplist /jasig/svn/jasig -t 48014-1 --verbose uPortal/branches/working-pluto-2.0/uportal-impl/src/main/java/org/jasig/portal/spring/locator/PortalDriverContainerServicesLocator.java /jasig/svn/jasig/hooks/check-mime-type.pl: uPortal/branches/working-pluto-2.0/uportal-impl/src/main/java/org/jasig/portal/spring/locator/PortalDriverContainerServicesLocator.java : svn:mime-type is not set Every added file must have the svn:mime-type property set. In addition text files must have the svn:eol-style property set. For binary files try running svn propset svn:mime-type application/octet-stream path/of/file For text files try svn propset svn:mime-type text/plain path/of/file svn propset svn:eol-style native path/of/file You may want to consider uncommenting the auto-props section in your ~/.subversion/config file. Read the Subversion book (http://svnbook.red-bean.com/), Chapter 7, Properties section, Automatic Property Setting subsection for more help. -- 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] pre-commit hook re: svn:mime-type preventing commit
So do you see the same behavior if you do the the subversion add from the command line? Cris J H Nicholas Blair wrote: Via eclipse. I'm using the have the JavaHL client. I should add I've added one line to the uportal subversion config as prescriped by subclipse to deal with a subversion bug that appears when using the gnome-keyring: password-stores = On Sun, Feb 28, 2010 at 11:39 AM, Cris J Holdorph holdo...@unicon.net wrote: Did you do the subversion add from the command line or from eclipse? If from eclipse, does anyone know if subclipse will use/pick up those parts of the subversion config file? Cris J H Nicholas Blair wrote: I have the uportal subversion config file from http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Subversion+Configuration in my .subversion directory (Eclipse Galileo, latest subclipse plugin, ubuntu karmic workstation), but every time I try to commit a new file I get the following message copied at the bottom of this message. It doesn't seem to be an issue for commits on existing files, only on new files. I looked at the svn properties for the file in question, and the following exist: svn:eol-style native svn:keywords Date Revision Author HeadURL Id These properties match values on other files in the same directory. Any ideas Error message below: Transmitting file data ... A repository hook failed svn: Commit failed (details follow): svn: 'pre-commit' hook failed with error output: Running /jasig/tools/subversion/subversion/bin/svnlook changed /jasig/svn/jasig -t 48014-1 Running /jasig/tools/subversion/subversion/bin/svnlook proplist /jasig/svn/jasig -t 48014-1 --verbose uPortal/branches/working-pluto-2.0/uportal-impl/src/main/java/org/jasig/portal/spring/locator/PortalDriverContainerServicesLocator.java /jasig/svn/jasig/hooks/check-mime-type.pl: uPortal/branches/working-pluto-2.0/uportal-impl/src/main/java/org/jasig/portal/spring/locator/PortalDriverContainerServicesLocator.java : svn:mime-type is not set Every added file must have the svn:mime-type property set. In addition text files must have the svn:eol-style property set. For binary files try running svn propset svn:mime-type application/octet-stream path/of/file For text files try svn propset svn:mime-type text/plain path/of/file svn propset svn:eol-style native path/of/file You may want to consider uncommenting the auto-props section in your ~/.subversion/config file. Read the Subversion book (http://svnbook.red-bean.com/), Chapter 7, Properties section, Automatic Property Setting subsection for more help. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: nicholas.bl...@gmail.com 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] [VOTE] Steve Swinsburg as a uPortal committer
I proposed him, so I think that's an implicit +1 from me. Here it is explicitly if needed. +1 Cris J H - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org Sent: Saturday, January 30, 2010 9:19:04 PM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] [VOTE] Steve Swinsburg as a uPortal committer After Chris's proposal I'm calling a vote for Steve to be a uPortal committer. As per the usual voting guidelines 3 + votes from current committers are needed with no - votes. If you post a - vote please include some reasoning. The voting will be open for 5 days (until 2/4). -Eric -- 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] SVN Configuration for committers
Yes, I have a file like that config in place. It's not the exact same one as uportal, but one I've used from Sakai for a while. It is nearly the same. I'll resolve the few differences (adding a couple of uportal file types like .cpd) in the mean time. Cris J H Eric Dalquist wrote: So after causing enough pain for each other we're going to start enforcing the use of a standard subversion configuration. This will enforce standard line endings in the repository and hopefully help avoid problems between people on differing platforms. Information on getting this configuration setup is here: http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Subversion+Configuration We have the following current committer list for uPortal, I'd like to get a direct confirmation from each person on this list that they have the SVN configuration file in place. acolebourne, apetro, arybicki, awills, bourey, bszabo, dschultz, edalquist, gthompson, holdorph, lfuller, nblair, sbattaglia, sbramhall, tuyly Thanks, Eric -- 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] SVN Configuration for committers
Ok, I resolved the diffs between the uportal config and the config i was using. The only difference that remains, is I use this in my file as well under the [miscellany] section global-ignores=bin target m2-target Cris J H Cris J Holdorph wrote: Yes, I have a file like that config in place. It's not the exact same one as uportal, but one I've used from Sakai for a while. It is nearly the same. I'll resolve the few differences (adding a couple of uportal file types like .cpd) in the mean time. Cris J H Eric Dalquist wrote: So after causing enough pain for each other we're going to start enforcing the use of a standard subversion configuration. This will enforce standard line endings in the repository and hopefully help avoid problems between people on differing platforms. Information on getting this configuration setup is here: http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Subversion+Configuration We have the following current committer list for uPortal, I'd like to get a direct confirmation from each person on this list that they have the SVN configuration file in place. acolebourne, apetro, arybicki, awills, bourey, bszabo, dschultz, edalquist, gthompson, holdorph, lfuller, nblair, sbattaglia, sbramhall, tuyly Thanks, Eric -- 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] uPortal and JDK support
How do people feel about JDK support and uPortal? Sun has dropped support for JDK 5 back in October. We have the next major release of uPortal, 3.2, coming out as a release candidate shortly. Recently a bug was introduced by some code that only built with JDK 6. Is it worth considering only supporting JDK 6 with uPortal 3.2? With some caveat, that it *might* run on JDK 5, but developers are not committed to compiling/running/testing against JDK 5. If we do NOT consider the above then we need to know what we're telling ourselves. To avoid the issue that Adam introduced, we must actually USE JDK 5, to build against, because just using JDK 6 in compile for java 5 mode, doesn't eliminate the prossibility of being compile time dependent on a JDK class difference. My personal preference would be to no longer officially support JDK 5, now that Sun is no longer officially supporting it. Cris J H -- 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] Jasig/uPortal Licensing Policy Update
Code will have to abide by the new licensing policy (signed agreements
included) to leave incubation. There is still the option for code to
live in the sandbox that never becomes a fully supported (into and out
of incubation) Jasig project.
Cris J H
Gary Weaver wrote:
Curious- will this also apply to all portlets contributed to sandbox?
How feasible is all of this if there is some code here and there (not
sure if there is, but if there is) that was contributed under a
different license?
In open source projects before, I've never been asked to change the
license by the person hosting the source control repository (it has
usually just been an initiative by the developers on the project
itself), so am just curious.
Thanks!
Gary
Jason Shao (CampusEAI Consortium) wrote:
Uh oh the board really wanted to validate everyone was comfortable signing
the forms before voting to finalize them...
If (DecisionMaking.repeatsAdInfinitum()) {break;}
*whew* that was close ;)
Not to steal John L.¹s thunder - but I'd like to publicly commend him --
he's done an excellent, enormous (and thankless) job putting these items
together. I know he and the rest of the board are very interested in making
sure we¹ve got the right balance between protecting everyone (developers,
institutions, Jasig) and not being too onerous. Hopefully when everyone
looks at the proposed documents if there are any comments (cynical or
otherwise) I think we¹d all love to hear them.
Jason
On 7/28/09 6:35 PM, Cris Holdorph holdo...@unicon.net wrote:
I'm waiting for the licensing policy to be officially voted on and
approved by the board, before signing it. Call me a cynic or lazy, but
I hate having to sign forms, then turn around and sign it again, because
they changed one sentence.
Cris J H
Eric Dalquist wrote:
As an FYI for uPortal developers and those interested in uPortal
development. The Jasig board has been working on updating the licensing
policy for projects under its purview. The updated policy is available
for public review on the wiki: http://www.ja-sig.org/wiki/x/6YB9AQ
I just wanted to let everyone know that I'm looking forward to these
changes and will be sending in my own signed Contributer License
Agreement (CLA) shortly. While I believe direct contact with existing
uPortal developers is planned I would encourage anyone with commit
access to the Jasig SVN repository to go ahead and submit a signed CLA
as well after of course going through whatever institutional policy you
need to for that. Your initiative in this effort will help make the
transition go as smoothly as possible.
If you have comments or questions about the licensing policy updates you
can continue the discussion here or email jasig-licens...@lists.jasig.org
Thanks,
-Eric Dalquist
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
jason_s...@campuseai.org
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
Jason Shao
Director of Product Development
CampusEAI Consortium
1940 East 6th Street, 11th Floor
Cleveland, OH 44114
Tel: 216.589.9626x249
Fax: 216.589.9639
Your input is important to improve upon our continuous efforts to service you
better. Please e-mail my manager at anjli_j...@campuseai.org with any feedback.
CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential;
intended for only the recipient(s) named above and may contain information that
is privileged. You should not retain, copy or use this e-mail or any
attachments for any purpose, or disclose all or any part of the contents to any
person. Any views or opinions expressed in this e-mail are those of the author
and do not represent those of CampusEAI Consortium or the Open Student
Television Network. If you have received this e-mail in error, or are not the
named recipient(s), you are hereby notified that any review, dissemination,
distribution or copying of this communication is prohibited by the sender and
to do so might constitute a violation of the Electronic Communications Privacy
Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender and
delete this e-mail and any attachments from your computer. Warning: Although
precautions have been taken to make sure no viruses are present in thi
s e-mail, the companies cannot accept responsibility for any loss or damage
that arise from the use of this e-mail or attachments.
--
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] Jasig/uPortal Licensing Policy Update
You should make sure to send these comments on to the suggested email
address.
jasig-licens...@lists.jasig.org
I'm not certain if the people that requested feedback watch this list
too closely or not.
Cris J H
Gary Weaver wrote:
Something else I thought of if it helps is that Sourceforge, Apache
(although it was several years ago and my patch was integrated by
someone else), and Atlassian community projects that I've contributed to
have not required actual hand-signed statements/contracts (that I
remember at least- RPI was the only one that required a signed agreement
for Bedework iirc).
Couldn't there just be an online form to submit a request for access to
contribute that doesn't require printing/signing/faxing or mailing? I'm
pretty sure that I had to agree to something when signing up with
sourceforge. Then whenever changes came about, they've just sent an
email to state the changes to the agreement (and maybe how to contact
them or opt-out if they disagree) iirc.
License changes for uPortal and other top-level JASIG projects could
then just be handled by an email out to the group stating that
everything under the JASIG umbrella in the code had a proposed license
change and it could be voted on like any other changes.
Thanks!
Gary
Gary Weaver wrote:
Curious- will this also apply to all portlets contributed to sandbox?
How feasible is all of this if there is some code here and there (not
sure if there is, but if there is) that was contributed under a
different license?
In open source projects before, I've never been asked to change the
license by the person hosting the source control repository (it has
usually just been an initiative by the developers on the project
itself), so am just curious.
Thanks!
Gary
Jason Shao (CampusEAI Consortium) wrote:
Uh oh the board really wanted to validate everyone was comfortable signing
the forms before voting to finalize them...
If (DecisionMaking.repeatsAdInfinitum()) {break;}
*whew* that was close ;)
Not to steal John L.¹s thunder - but I'd like to publicly commend him --
he's done an excellent, enormous (and thankless) job putting these items
together. I know he and the rest of the board are very interested in making
sure we¹ve got the right balance between protecting everyone (developers,
institutions, Jasig) and not being too onerous. Hopefully when everyone
looks at the proposed documents if there are any comments (cynical or
otherwise) I think we¹d all love to hear them.
Jason
On 7/28/09 6:35 PM, Cris Holdorph holdo...@unicon.net wrote:
I'm waiting for the licensing policy to be officially voted on and
approved by the board, before signing it. Call me a cynic or lazy, but
I hate having to sign forms, then turn around and sign it again, because
they changed one sentence.
Cris J H
Eric Dalquist wrote:
As an FYI for uPortal developers and those interested in uPortal
development. The Jasig board has been working on updating the licensing
policy for projects under its purview. The updated policy is available
for public review on the wiki: http://www.ja-sig.org/wiki/x/6YB9AQ
I just wanted to let everyone know that I'm looking forward to these
changes and will be sending in my own signed Contributer License
Agreement (CLA) shortly. While I believe direct contact with existing
uPortal developers is planned I would encourage anyone with commit
access to the Jasig SVN repository to go ahead and submit a signed CLA
as well after of course going through whatever institutional policy you
need to for that. Your initiative in this effort will help make the
transition go as smoothly as possible.
If you have comments or questions about the licensing policy updates you
can continue the discussion here or email jasig-licens...@lists.jasig.org
Thanks,
-Eric Dalquist
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
jason_s...@campuseai.org
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
Jason Shao
Director of Product Development
CampusEAI Consortium
1940 East 6th Street, 11th Floor
Cleveland, OH 44114
Tel: 216.589.9626x249
Fax: 216.589.9639
Your input is important to improve upon our continuous efforts to service you
better. Please e-mail my manager at anjli_j...@campuseai.org with any feedback.
CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential;
intended for only the recipient(s) named above and may contain information that
is privileged. You should not retain, copy or use this e-mail or any
attachments for any purpose, or disclose all or any part of the contents to any
person. Any views or opinions expressed in this e-mail are those of the author
and do not represent those of CampusEAI Consortium or the Open Student
Television Network. If you have received this e-mail in error, or are not the
named recipient(s), you are
Re: [uportal-dev] jira - how to re-open a bug?
are you sure it's closed? what is the issue number? It would be above the operations section if it's closed. Cris J H Aaron Brown wrote: Cris J Holdorph wrote: If you're logged in, you should simply see a Reopen Issue under the Available Workflow Actions in the left hand menu. You do have to be logged in to Jira to see this option. I don't see the option. After logging in, here are the Operations available to me (copy/pasted from the left column): = Operations Attach file to this issue Attach screenshot to this issue Clone this issue Comment on this issue Create sub-task Link this issue to another issue Voting: You cannot vote or change your vote on resolved issues. Watching: You are not watching this issue. Watch it to be notified of changes Worklog: You don't have permission to work on this issue. = - Aaron -- 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] jira - how to re-open a bug?
For 2235, I see an option for Reopen Issue right above the word Operations. You sure, you're not seeing that? Cris J H Aaron Brown wrote: Cris J Holdorph wrote: are you sure it's closed? what is the issue number? It would be above the operations section if it's closed. http://www.ja-sig.org/issues/browse/UP-2235 You may be right - it's marked as fixed / resolved, but if Jira doesn't equate that with Closed, then that could be the problem. For an issue at that state, should I just add comments, then? - Aaron -- 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] jira - how to re-open a bug?
I reopened the bug for you. Please add a comment to the bug to explain why it was opened. Seperately, does anyone know what needs to be done in Jira to get Aaaron the permission he needs to do this on his own. Maybe he needs to be added to a group in Jira? Cris J H Aaron Brown wrote: Cris J Holdorph wrote: are you sure it's closed? what is the issue number? It would be above the operations section if it's closed. http://www.ja-sig.org/issues/browse/UP-2235 You may be right - it's marked as fixed / resolved, but if Jira doesn't equate that with Closed, then that could be the problem. For an issue at that state, should I just add comments, then? - Aaron -- 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] Nominating Jen Bourey for uPortal Project Steering Committee
+1 Andrew Petro wrote: uPortal developers, I'd like to nominate Jen Bourey as a uPortal developer representative to the uPortal Steering Committee. I believe Jen needs no introduction to the community of uPortal committers, but I'd nonetheless take a moment to remind of her recent and ongoing contributions to uPortal. Ohloh credits http://www.ohloh.net/p/3510/contributors Jen with more than 200 commits to the uPortal codebase (which feels awfully low, in part because Jen has been a leader or major contributor to several Jasig portlet projects, including the Calendar portlet http://www.ja-sig.org/wiki/display/PLT/CalendarPortlet, the Feedback portlet http://www.ja-sig.org/wiki/display/PLT/Unconference+Feedback+Portlet, and the Tabbed Search portlet http://www.ja-sig.org/wiki/display/PLT/TabbedSearchPortlet). Jen has given several popular Jasig conference presentations about uPortal, including on JavaScript in uPortal 3, on using AJAX to improve the user experience, on uPortal 3 configuration and deployment automation, and on open source portlet incubation. Jen regularly posts to this developer email list and has answered many questions on the uportal-user@ email list. She is also regularly available and active in the uPortal IRC channel. In short, I believe Jen is eminently qualified to represent uPortal developers on the uPortal project steering committee and I would expect she would bring enthusiasm, technical competence, and particularly attention to continuing to grow the set of portlets and the quality of the user experience in uPortal. With many thanks to Jen for all her contributions to uPortal, Andrew - Original Message - From: Jonathan Markow jjmar...@ja-sig.org To: uportal-dev@lists.ja-sig.org Cc: uPortal PSC uportal-steering-commit...@lists.ja-sig.org, cas-steering-commit...@lists.ja-sig.org, JA-SIG Board bo...@lists.ja-sig.org Sent: Wednesday, June 10, 2009 8:48:29 AM GMT -07:00 U.S. Mountain Time (Arizona) Subject: [uportal-dev] Developer Representatives to Project Steering Committees Developers: You have received a couple of emails recently about the Jasig 2009 Elections, during which our membership will be selecting stakeholder positions on the project steering committees for both uPortal and CAS. At the same time we will be asking you to select developer representatives to each of the committees. uPortal has two developer positions and CAS has one: Current uPortal Reps: Eric Dalquist Andrew Petro Current CAS Rep: Scott Battaglia These developer positions are not subject to term limits, and incumbents may serve successive terms. But we do ask each team to revisit their selections each year and make fresh recommendations. The way the process works is this: 1. Any developer may serve if selected 2. Only committers have votes; they are not required to belong to Member organizations 3. Discussion is open to all on the developer lists 4. Please initiate discussion on your list when the spirit moves you (This week would be a good time to start :-) 5. You may nominate others or yourself 6. We will need a decision on your selections by the end of the Jasig election process, which is July 17, 2009 7. Committee chairs should monitor these selections and report results back to the steering committees. 8. New terms officially begin on September 1, 2009 Questions? Please feel free to ask. Thank you! Jonathan -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: ape...@unicon.net 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: holdo...@unicon.net 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] Portlet Administration Portlet Update (UP-2047)
I think you misunderstand what I'm getting at. If you have an existing portal you want to upgrade to uPortal 3.2 when it comes out. And if you have existing channels that *you* added that did not conform to the new naming conventions, then they would not import properly. I guess we can simply tell people they'll have to hand edit their channel files, before they reimport, but that seems kind of like a poor workaround. Cris J H Eric Dalquist wrote: I believe the export scripts are unaffected by these changes. Are they failing for you? Cris J Holdorph wrote: you might want to do some work on the export scripts, so people can't export something they can't then turn around and import. Cris J H Eric Dalquist wrote: In continuation of this great work I'm working on doing additional cleanup of the channel definition object model. One of these changes is enforcing further restrictions on FNames. I'm committing some changes that now enforce that all channel fnames can only contain characters [a-zA-Z0-9_-]. We had a bunch of channels that had . and / in the fnames which I've replaced with _ in the entity files and in the code where they are referenced. You will need do to do an initdb if you update from trunk after this email. -Eric Jen Bourey wrote: The new Portlet Administration Portlet is now the default channel managing utility in uPortal. If you notice any bugs, please let me know! The parameter-setting screen in particular still has a few rough edges, but you should be able to use the portlet to successfully modify, delete, and create channel definitions. - Jen On Wed, May 20, 2009 at 4:11 PM, Jen Bourey jennifer.bou...@gmail.com mailto:jennifer.bou...@gmail.com wrote: Hi all, The new Portlet Administration Portlet described by JIRA entry UP-2047 is now in the trunk, and I believe we've updated it to include all features currently available in CChannelManager. I would like to be able to switch the admin link in the layout over to use this new portlet. Does anyone have an objection to making this new portlet the default portlet administration tool sometime in the near future? Are there features you rely on in CChannelManager that don't appear to be included in the new portlet? We've also had discussions in the uPortal IRC channel about potentially removing CChannelManager altogether for the 3.2 release. Doing this would allow us to move forward with the proposed portlet workflow lifecycle work without having to worry about its affects on the legacy channel implementation. - Jen -- Jen Bourey -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu 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] Portlet Administration Portlet Update (UP-2047)
+1 for removing the old CChannelManager and switching over to the new one in trunk. I don't say this lightly either. I know there is some risk here, but I think this is a HUGE improvement and is worth the risk. Cris J H Jen Bourey wrote: Hi all, The new Portlet Administration Portlet described by JIRA entry UP-2047 is now in the trunk, and I believe we've updated it to include all features currently available in CChannelManager. I would like to be able to switch the admin link in the layout over to use this new portlet. Does anyone have an objection to making this new portlet the default portlet administration tool sometime in the near future? Are there features you rely on in CChannelManager that don't appear to be included in the new portlet? We've also had discussions in the uPortal IRC channel about potentially removing CChannelManager altogether for the 3.2 release. Doing this would allow us to move forward with the proposed portlet workflow lifecycle work without having to worry about its affects on the legacy channel implementation. - Jen -- Jen Bourey -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: holdo...@unicon.net 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] Fixing issues reported by automated code-review
I'm a fan of fixing the stuff reported by FindBugs. However, there are some things to be careful of. Too much code change can sometimes have the reverse effect that was intended. In certain cases '2 bugs' could be working together to cause the end code to actually function. So if you only 'fix' one bug, you could introduce a problem that did not exist before. This is a real annoyance to people who are simply trying to apply the latest patch. So, I would be very careful how much you do in the 3.1.x branch. I believe trunk is a lot more forgiving for these types of changes. Another thing you can do, is to make small changes like the one you've attached to the jira so far. That's a nice small, well controlled patch. Also, if you really want to work on improving the 3.1.x branch, make sure you include both 3.1.x branch *AND* trunk patches. Cris J H Ernst-Jan Verhoeven wrote: Hi all, I'm a developer for the University of Amsterdam and we are planning to run uPortal 3.1 in production in a few months. Of course we like the system to be as stable as possible, and as me and my colleagues are huge fans of automated code-review tools we ran the automated (byte-)code review tool 'Findbugs' on uPortal. Not all issue-categories reported by Findbugs are equally easy or rewarding to fix. I picked the '(possible) null pointer derefences' category as it usually contains issues that are both easy and rewarding to fix and spent an afternoon trying to fix these issues. I have included my efforts in a Jira report: http://www.ja-sig.org/issues/browse/UP-2443 This was more of an exercise to get a feeling of the maintainability of the code, but we intend to do more fixes like this. Other nice candidates seem e.g. 'method may fail to close database resource' (33 reported Findbugs-issues) 'Method may fail to clean up stream or resource' (40 reported Findbugs-issues) although in my experience (and/or opinion) Findbugs usually reports a very low number of false positives; so it may not be that useful to 'zoom in' on specific categories. How do others feel about this 'bottom-up' way of fixing possible issues in the uPortal code-base? -Ernst-Jan Verhoeven -- 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] Fluid 1.0 and UP-2047 updates
sounds like a good idea to me. Cris J H Jen Bourey wrote: Hi all, I'd like to update the uPortal trunk to Fluid 1.0 this evening, unless anyone has any objections. I think doing this update now will give us lots of time to perform CSS integration and testing, as well as keep us in step with Fluid's development. I'd also like to integrate in the work currently completed on UP-2047 (the new portlet administration portlet) by Unicon's cooperative support program. These changes mostly consist of added webflows and shouldn't impact the existing CChannelManager or any other critical uPortal components. Both these changes would be trunk-only and will not be merged into any of the maintenance branches. - 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
Re: [uportal-dev] portlet URL anchoring
I find the anchors extremely annoying and turn them off whenever I remember to. So the more places they are off by default, the better for me :) Cris J H Eric Dalquist wrote: Currently if the 'org.jasig.portal.ChannelManager.use_anchors' property is true all render portlet URLs will be generated with an anchor that brings focus to the top of the portlet chrome. I'm wondering if this only makes sense for portlets rendering in minimized and normal WindowStates. My thought is that in maximized and exclusive the portlet is the only thing on the page so the anchors are rather useless and also prevent the portlet developer from using anchors withing their portlet in a view where they render most of the content on the page. Any thoughts about making this change? -Eric -- 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] Unable to add portlet of channel content in uPortal 3
This is probably a question for uportal-user. Before you post there, you should probably include which version of uportal (e.g., 3.0.2), which browserversion and confirm that you have javascript enabled. Cris J H Nathan Mcilree wrote: Hi whenever I click on the add content link the box that appears has Loading portlet list . ., but doesn't show any channels or portlets. Likewise the search option does not work. Has this happened to anyone else, or does anyone know what the cause of this might be. -- 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] [jasig-webredesign-project] uPoral license information
if possible we should set up a http redirect for the old url. the old code will still be out there. - Original Message - From: Eric Dalquist eric.dalqu...@doit.wisc.edu To: uportal-dev@lists.ja-sig.org Sent: Wed, 18 Feb 2009 11:09:48 -0700 (MST) Subject: Re:[uportal-dev] [jasig-webredesign-project] uPoral license information Don't worry about it right now. Before the next GA release I'm going to use the Maven license plugin which will update the license headers on all of the files in the project to be consistent. -Eric Gary Thompson wrote: All, I am currently making changes to uPortal for the 3.1 release. I noticed this statement at the top of the theme files: | Copyright 2008 The JA-SIG Collaborative. All rights reserved. | See license distributed with this file and | available online at http://www.uportal.org/license.html I was going to update the url. However, this page: http://www.uportal.org/license.html No longer exists, and the forwarding page: http://www.jasig.org/uportal Does not have an obvious link to license information, which is here: http://www.jasig.org/uportal/about/license Should I update the statement to: | Copyright 2008 Jasig. All rights reserved. | See license distributed with this file and | available online at http://www.jasig.org/uportal/about/license ? There may be other such statements in the uPortal source code files. Gary -- 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] Upcoming 3.1 Milestone Release
the jira issues are hyperlinked in his comments. Cris J H Eric Dalquist wrote: Thanks for the reminder Arlo, I'll see if I can dig into the DLM issue. Would you happen to have a list of Jira issue ids for those patches? Thanks a lot! -Eric Arlo White wrote: The biggest concern I have is the DLM issue I reported in a thread named DLM fragment-layout issues in the uportal-user list. I haven't created a JIRA issue for it. Here are the issues I've reported that I'd like to see fixed by 3.1 final: There was an email thread a while back on subscribeIds not being added to hrefs/actions. I created a JIRA/patch for IChannels, but I think the portlet code was somewhere else. HTMLSerializer does not correctly detect and add # + subscribeId to hrefs/actions [PATCH] http://www.ja-sig.org/issues/browse/UP-2226 The other issues I've encountered and would like to see fixed are lower priority user-interface type issues. Jump To feature (left panel in focus mode) highlights wrong tab and breadcrumbs for selected channel http://www.ja-sig.org/issues/browse/UP-2268 Page Layout dialog resets the active tab, make setting active tab more explicit http://www.ja-sig.org/issues/browse/UP-2265 If you want I could try to tackle this issue and submit a patch. Add Content, search should be case insensitive [PATCH] http://www.ja-sig.org/issues/browse/UP-2227 You can't use the sign-out xsl method because: USER_NAME stylesheet parameter is not populated in universality.xml http://www.ja-sig.org/issues/browse/UP-2235 If you're supporting webkit browsers (Safari, Chrome): Change portlet-controls (channel buttons) CSS to have consistent padding and fix Webkit render bug [PATCH] http://www.ja-sig.org/issues/browse/UP-2269 The issues with [PATCH] are modifications I've made that we've been running successfully in production with for the past few weeks. The JIRAs have patch files attached. -Arlo Eric Dalquist wrote: I'd like to cut a milestone release from the trunk early next week. If there are specific Jira issues people would like to see addressed before this please let me know and we can coordinate on getting a patch in place. -Eric -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: eric.dalqu...@doit.wisc.edu 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] SVN Revision Renumbering
I'm in favor of this change. I do not use the revision numbers for anything specific. I do use the history, that you say will be preserved. Removing empty revisions, makes querying the revision history easier, so big +1 from me as well. Cris J H Eric Dalquist wrote: We're getting closer to migrating some services to Jira Studio, with the move I'd like to take the opportunity to filter out a large number of empty revisions from our SVN repository. We have close to 28000 empty revisions in SVN, they are vestiges of the CVS2SVN import and a few failed imports that were filtered out along the way. No version history, JIRA issue links or file/folder properties would be lost. The end result is instead of being on commit 44480 or so we would be around 16500. Since people will need to check out projects new anyways because of the changed server name I don't think this would be a problem. I know both uPortal and CAS reference fixes by JIRA id and not rev number but I just wanted to run this by everyone here first. -Eric -- 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] 3-0-x branch and ImpersonationFilter
Ok, I was a little misleading when I said relatively fresh checkout. It was an older checkout, but with a brand new 'svn update' and a run of 'svn status' to make sure I had not modified anything. Anyway, the problemm turns out that 'ant initportal' does NOT clean out things. And if you have a checkout that has existed across a release. then you can end up with multiple impl jars in your distribution. $ ls webapps/uPortal/WEB-INF/lib/uPortal* uportal-impl-3.0.1-SNAPSHOT.jar uportal-impl-3.0.3-SNAPSHOT.jar Completely removing tomcat, then redoing the build by first doing an ant clean then an ant initportal, fixed my problem. While the above is certainly not a common case, what do people think about having ant clean be a dependency for ant initportal ? Cris J H Cris J Holdorph wrote: Before I start chasing this down, I thought I would ask here to see if this is already a known bug or if anyone else is seeing the same thing. I tried a relatively fresh checkout/build/deploy of uPortal 3.0.x from the branch. https://www.ja-sig.org/svn/uPortal/branches/rel-3-0-patches My only changes are to rdbm.properties, dbloader.xml, personDirectoryContext.xml and pom.xml in order to use MySQL. I started with a fresh database and fresh tomcat. 'ant initportal' from the root complete successfully, tomcat starts successfully, however the uPortal web application does not. The following error (minus a several of the lest interesting lines of stack) occurs. ERROR [main] provider.ImpersonationFilter.[] Dec/11 16:35:17 - Falied to read security.properties java.lang.NullPointerException at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:119) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... ERROR [main] [localhost].[/uPortal].[] Dec/11 16:35:17 - Exception starting filter Impersonation Filter javax.servlet.ServletException: Falied to read security.properties at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:153) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... Does anyone else see this? Is this a partial commit from someone, or am I really missing a new deployment step that I am unaware of? Cris J H -- 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] 3-0-x branch and ImpersonationFilter
Consistent, but only to a certain extent. We did not have the same maven-multi-project+ant situation in uPortal 2.x. The problem is not the same. Specifically, I guess I just really don't like the Ant calling maven to do things paradigm. In Maven, there are very clear semantics with running a certain lifecycle step. All the preceding steps are done. So if you're going to compile the code, it *WILL* run clean first. ant initportal does build code, which in maven terms means it should probably clean as well. Anyway, I understand, and I will try to remember to do so in the future, but since we've started using maven in 3.x, I don't believe we're stuck with trying to remain consistent with 2.x conventions. Cris J H Eric Dalquist wrote: Nope, you need to run ant 'ant clean' to clean things out. or 'ant clean initportal' this is consistent with initportal's behavior from 2.x -Eric Cris J Holdorph wrote: Ok, I was a little misleading when I said relatively fresh checkout. It was an older checkout, but with a brand new 'svn update' and a run of 'svn status' to make sure I had not modified anything. Anyway, the problemm turns out that 'ant initportal' does NOT clean out things. And if you have a checkout that has existed across a release. then you can end up with multiple impl jars in your distribution. $ ls webapps/uPortal/WEB-INF/lib/uPortal* uportal-impl-3.0.1-SNAPSHOT.jar uportal-impl-3.0.3-SNAPSHOT.jar Completely removing tomcat, then redoing the build by first doing an ant clean then an ant initportal, fixed my problem. While the above is certainly not a common case, what do people think about having ant clean be a dependency for ant initportal ? Cris J H Cris J Holdorph wrote: Before I start chasing this down, I thought I would ask here to see if this is already a known bug or if anyone else is seeing the same thing. I tried a relatively fresh checkout/build/deploy of uPortal 3.0.x from the branch. https://www.ja-sig.org/svn/uPortal/branches/rel-3-0-patches My only changes are to rdbm.properties, dbloader.xml, personDirectoryContext.xml and pom.xml in order to use MySQL. I started with a fresh database and fresh tomcat. 'ant initportal' from the root complete successfully, tomcat starts successfully, however the uPortal web application does not. The following error (minus a several of the lest interesting lines of stack) occurs. ERROR [main] provider.ImpersonationFilter.[] Dec/11 16:35:17 - Falied to read security.properties java.lang.NullPointerException at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:119) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... ERROR [main] [localhost].[/uPortal].[] Dec/11 16:35:17 - Exception starting filter Impersonation Filter javax.servlet.ServletException: Falied to read security.properties at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:153) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... Does anyone else see this? Is this a partial commit from someone, or am I really missing a new deployment step that I am unaware of? Cris J H -- 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] 3-0-x branch and ImpersonationFilter
Hmm... I wonder what was causing me to think it did clean out the stuff. I guess maybe because the default lifecycle is just so dang long, it seems to encompass the whole world. In any case, then, rethinking this a bit more, the problem is more related to the jar file having a version number in it, where in 2.x it would not have. So in uPortal 2.x if I ran 'ant initportal' at one point in time, I would get a 'uportal.jar'. And if there were any .class file ADDITIONS or CHANGES they would get populated, but at the end of the build there would only be one uPortal.jar file. In this maven+ant build system we have not a 'uportal.jar' but a 'uPortal-impl-3.0.3-SNAPSHOT.jar' file. So, if the version in the maven file changes between doing a build, you'll end up duplicate jar files in your target directory. In uPortal 2.x, you'd only have one. The behavior between uPortal 2.x and 3.x has clearly changed. The current behavior might be viewed as the closest we can get, but it's certainly not the same. Cris J H Eric Dalquist wrote: Actually Maven does not run clean unless you explicitly request it, just running compile, package or install on a project with old files in the target directory will result in those old files being included in your final artifact. -Eric Cris J Holdorph wrote: Consistent, but only to a certain extent. We did not have the same maven-multi-project+ant situation in uPortal 2.x. The problem is not the same. Specifically, I guess I just really don't like the Ant calling maven to do things paradigm. In Maven, there are very clear semantics with running a certain lifecycle step. All the preceding steps are done. So if you're going to compile the code, it *WILL* run clean first. ant initportal does build code, which in maven terms means it should probably clean as well. Anyway, I understand, and I will try to remember to do so in the future, but since we've started using maven in 3.x, I don't believe we're stuck with trying to remain consistent with 2.x conventions. Cris J H Eric Dalquist wrote: Nope, you need to run ant 'ant clean' to clean things out. or 'ant clean initportal' this is consistent with initportal's behavior from 2.x -Eric Cris J Holdorph wrote: Ok, I was a little misleading when I said relatively fresh checkout. It was an older checkout, but with a brand new 'svn update' and a run of 'svn status' to make sure I had not modified anything. Anyway, the problemm turns out that 'ant initportal' does NOT clean out things. And if you have a checkout that has existed across a release. then you can end up with multiple impl jars in your distribution. $ ls webapps/uPortal/WEB-INF/lib/uPortal* uportal-impl-3.0.1-SNAPSHOT.jar uportal-impl-3.0.3-SNAPSHOT.jar Completely removing tomcat, then redoing the build by first doing an ant clean then an ant initportal, fixed my problem. While the above is certainly not a common case, what do people think about having ant clean be a dependency for ant initportal ? Cris J H Cris J Holdorph wrote: Before I start chasing this down, I thought I would ask here to see if this is already a known bug or if anyone else is seeing the same thing. I tried a relatively fresh checkout/build/deploy of uPortal 3.0.x from the branch. https://www.ja-sig.org/svn/uPortal/branches/rel-3-0-patches My only changes are to rdbm.properties, dbloader.xml, personDirectoryContext.xml and pom.xml in order to use MySQL. I started with a fresh database and fresh tomcat. 'ant initportal' from the root complete successfully, tomcat starts successfully, however the uPortal web application does not. The following error (minus a several of the lest interesting lines of stack) occurs. ERROR [main] provider.ImpersonationFilter.[] Dec/11 16:35:17 - Falied to read security.properties java.lang.NullPointerException at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:119) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... ERROR [main] [localhost].[/uPortal].[] Dec/11 16:35:17 - Exception starting filter Impersonation Filter javax.servlet.ServletException: Falied to read security.properties at org.jasig.portal.security.provider.ImpersonationFilter.init(ImpersonationFilter.java:153) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:221) ... snip snip many uninteresting lines of the stack ... Does anyone else see this? Is this a partial commit from someone, or am I really missing a new deployment step that I am unaware of? Cris J H -- 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] Looking for Java expert to help diagnose login problem with 2.5.3
I can't help with your greater problem but to the smaller one...
The code you included could run the outside finally block only, if the
m_authenticationService.authenticate() method throws an exception. In
this case, the call stack ends abnormally, so it never tries the next
normal line of code that wold begin the inner try block.
I do agree that if you see the 'inner' log/finally block executed you
should see the outer one as well. Unless of course, 'log.info()' itself
blows up, which is possible if you're passing it objects that are not
well behaved.
Cris J H
George Lindholm wrote:
I finally added a bunch if finally statements like so:
LoginServlet:
try {
m_authenticationService.authenticate():
try {
securityContext.authenticate();
} finally {
log.info(...);
}
} finally {
log.info(...);
}
The really weird part is that both finally blocks are not executed
How is this possible? I thought the JVM guaranteed that a finally block
will be execute.
Is there anything the Spring framework might be doing to unravel the
call stack??
Thanks
George
--
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] Looking for Java expert to help diagnose login problem with 2.5.3
if the parameters to the inner log statement fail in some way, the
externally visible behavior could look like only one of the two log
statements executing. For example...
String foo = null;
try {
try {
int x = something.length() / 2;
}
finally {
System.out.println(the inner value of foo is: + foo.toString());
}
}
finally {
System.out.println(the outer value of foo is: + foo);
}
Would only print:
the outer value of foo is: null
The inner statement would not print, instead it would throw a
nullpointerexception.
Cris J H
George Lindholm wrote:
Cris J Holdorph wrote:
I can't help with your greater problem but to the smaller one...
The code you included could run the outside finally block only, if the
m_authenticationService.authenticate() method throws an exception. In
this case, the call stack ends abnormally, so it never tries the next
normal line of code that wold begin the inner try block.
I do agree that if you see the 'inner' log/finally block executed you
should see the outer one as well. Unless of course, 'log.info()'
itself blows up, which is possible if you're passing it objects that
are not well behaved.
Hi Chris,
maybe no the best pseudo code.
try {
try {
Authentication.authenticate::securityContext.authenticate();
} finally {
log
}
} finally {
log
}
There should be no way the both log lines are not execute.
No errors in any of the log files.
?
George
Cris J H
George Lindholm wrote:
I finally added a bunch if finally statements like so:
LoginServlet:
try {
m_authenticationService.authenticate():
try {
securityContext.authenticate();
} finally {
log.info(...);
}
} finally {
log.info(...);
}
The really weird part is that both finally blocks are not executed
How is this possible? I thought the JVM guaranteed that a finally block
will be execute.
Is there anything the Spring framework might be doing to unravel the
call stack??
Thanks
George
--
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] Future of WSRP support
Last I knew, the uPortal community was interested in supporting WSRP, but no one had the availability to work on this effort. Maybe I missed, some discussion though. Cris J H Kris Easter wrote: There is a thread from earlier this year: http://thread.gmane.org/gmane.comp.java.jasig.uportal.devel/1686/focus=1686 discussing WSRP support in future versions of uPortal. Has there been any more thought or effort on bringing back WSRP support into uPortal 3.x? We'd like to be able to serve our existing IChannels up via a WSRP producer for consumption by the PeopleSoft portal. Thanks, Kris -- 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] Should we rename / recreate the uPortal lists?
I wonder if we should consider some list renaming. People consistently post to uportal-dev with questions that are about them developing their portal. Look at the list name, think about what those people are doing, it's really not a stretch. uportal-user sounds like it might be for people to learn how to login, move portlets around, etc. uportal-dev sounds more reasonable when I need to ask a question about how to write a new portlet for my portal. I wonder if we should have names that help make the distinction between development of the core framework services and development and configuration of portals using uPortal better. For example, what if uportal-dev was renamed uportal-framework and uportal-user was named uportal-admin. I don't really like the name uportal-admin but you get the idea. It just feels like the names we currently have will continue to cause us trouble, because they do not match well with the intent of the content to be posted to them, at least from a new-user-to-the-community perspective. Cris J H -- 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] Hello World Portlet deployment problem
Copying into the portlets directory is not necessary. You may run the
ant deployPortletApp target and specify where the file lives and that
can be completely outside of the uportal source tree.
Cris J H
Patel, Jayesh wrote:
First you need to copy your .war file in a uportal C:\Documents and
Settings\jpatel\workspace\uPortal_rel-2-X-X-XXX\trunk\lib\portlets location.
After that you have to be in where a .build.properties or build.xml file to
run following. (all) option will deploy all portlets in lib/portlets
location. If you want to deploy one specific then you need to give full path
(e.g. deployPortletApp -DportletApp= C:\Documents and
Settings\jpatel\workspace\uPortal_rel-x-x-x-xxx\trunk\lib\portlets\x.war
)
Note: Not sure onuPortal release 3.0 work same way as I rel 2.xxx.
I hope this will help.
Thank You,
Jayesh
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Edward Chen
Sent: Thursday, August 21, 2008 12:29 AM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Hello World Portlet deployment problem
Hi,
Thank you for your quick answer.
I did copy directly. How can I do to copy without doing copying
Also, when I do following, I have
C:\uPortal-3.0.1-quick-startant deployPortletApp -DportletApp=all
Buildfile: build.xml
BUILD FAILED
Target `deployPortletApp' does not exist in this project.
Thanks,
Edward
Cris J Holdorph wrote:
Did you run the ant deployPortletApp ant target, or did you just
copy the war file into webapps directly? copying directly will not
work. You must run the uPortal tool for deploying the portlet web
applications.
http://www.ja-sig.org/wiki/display/UPM30/04+Working+with+Portlets+in+uPortal
Cris J H
Edward Chen wrote:
Hi,
I set up uPortal-3.0.1-quick-start up and running, and I use netbean
ide 6.1 to create a helloworld portlet. I copy the HelloWorld.war
C:\uPortal-3.0.1-quick-start\apache-tomcat-5.5.23\webapps
Then restart uPortal,
I created a new channel to publish this portlet by portlet manager.
Here is my setting
Review: Please review the settings for accuracy (click workflow icons
or items in the table below to edit settings)
User can
modify?NameValue
Channel Type:Portlet
Channel Title:HelloWorld
Channel Name:HelloWorld
Channel Functional Name:HelloWorld
Channel Description: Channel Timeout:
5000milliseconds
Channel Secure:Not Secure
User cannot modifyPortlet Web Application Path
/HelloWorld
User cannot modifyPortlet NameHelloWorld
Channel Controlstrue Editable
true Has Help
false Has About
Selected Categories:categoryNews
categoryAll categories
categoryApplications
categoryEntertainment
categoryDevelopment
Selected Groups and/or People:unlockedStudents
unlockedStaff
unlockedPAGS Root
unlockedGuests
unlockedFaculty
unlockedEveryone
But, after I subscribe it, I have the following error
Channel ID:
n85
Message:
Message not available
Error type:
Channel failed to initialize (code 2)
Problem type:
General rendering problem
Error message
Content was written to response during loading of portlet window
'PortletWindowImpl[portletWindowId=16.n85,contextPath=/HelloWorld,portletNam
e=HelloWorld,windowState=normal,portletMode=view,expirationCache=null,requ
estParameters={}]'
with [channelPublishId=73, channelSubscribeId=n85,
portletApplicationId=/HelloWorld, portletName=HelloWorld,
user=admin]. Response Content: The requested resource
(/HelloWorld/PlutoInvoker/HelloWorld) is not available
What is it wrong?
Thanks,
Edward
--
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] Hello World Portlet deployment problem
/render.userLayoutRootNode.target.ctf3.uP?uPCM_action=selectCategoriesuPCM_capture=reviewChannel* categoryNews categoryAll categories categoryApplications categoryEntertainment categoryDevelopment http://localhost:8080/uPortal/render.userLayoutRootNode.target.ctf3.uP?uPCM_action=selectCategoriesuPCM_capture=reviewChannel *Selected Groups and/or People: http://localhost:8080/uPortal/render.userLayoutRootNode.target.ctf3.uP?uPCM_action=selectGroupsuPCM_capture=reviewChannel* unlockedStudents unlockedFaculty unlockedStaff unlockedEveryone unlockedGuests unlockedPAGS Root http://localhost:8080/uPortal/render.userLayoutRootNode.target.ctf3.uP?uPCM_action=selectGroupsuPCM_capture=reviewChannel Can you see anything wrong? Thanks, Edward Cris J Holdorph wrote: Can you try instead of C:\uPortal-3.0.1-quick-start\uPortal-3.0.1ant deployPortletApp -DportletApp=all to do C:\uPortal-3.0.1-quick-start\uPortal-3.0.1ant deployPortletApp -DportletApp=c:\the\path\to\your\portlet_web.war replacing c:\the\path\to\your\portlet_web.war with the fully qualified path+filename of your portlet web application archive. Cris J H Edward Chen wrote: Hi, Dustin S. wrote: Edward, You need to be in the uPortal directory to run deployPortletApp...so C:\uPortal-3.0.1-quick-start\uPortal-3.0.1 I use either C:\uPortal-3.0.1-quick-start\uPortal-3.0.1 or C:\uPortal-3.0.1-quick-start\, and I have the same thing below C:\uPortal-3.0.1-quick-startant deployPortletApp -DportletApp=all Buildfile: build.xml BUILD FAILED Target `deployPortletApp' does not exist in this project. Total time: 1 second C:\uPortal-3.0.1-quick-startcd uPortal-3.0.1 C:\uPortal-3.0.1-quick-start\uPortal-3.0.1ant deployPortletApp -DportletApp=all Buildfile: build.xml deployPortletApp: BUILD FAILED C:\uPortal-3.0.1-quick-start\uPortal-3.0.1\build.xml:396: portletApp 'C:\uPortal -3.0.1-quick-start\uPortal-3.0.1\all' does not exist Total time: 1 second C:\uPortal-3.0.1-quick-start\uPortal-3.0.1 You should probably move this conversation to /uportal-user/@lists.ja-sig.org http://lists.ja-sig.org Sorry about that. I will switch to there. There are some experts helping me from dev Thanks, Edward -- 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 3.1 Servlet 2.5
This sounds like it could be a pretty big upgrade path for a lot of organizations using uPortal. How does everyone feel about this? I'm all for moving onward with the later releases of the servlet spec and in particular later releases of Tomcat, but I'm curious how places that will likely need to upgrade their environments feel. Cris J H Eric Dalquist wrote: Now that uPortal will be shipping with portlets deployed within the portal webapp we're going to have to require a Servlet 2.5 container. The requirement comes from a need to be able to determine the web-application context path to be able to dispatch to these embedded portlets correctly. This means Tomcat 6.0 will be required to run the trunk of uPortal in SVN. I'll be adding a check which will log a useful error message if an older version of the servlet API is used. I'll also make sure to add notes about setting up Tomcat 6.0 for uPortal in the readme and on the wiki. -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] A modest DLM enhancement
+1 Drew Wills wrote: Hey folks, I'd like to make a modest enhancement to DLM. I've prepared a JIRA and a patch (attached to JIRA): http://www.ja-sig.org/issues/browse/UP-2117 Here's the description... * DLM already has the ability to remove channels that the user isn't authorized to render from the fragments it manages. Many people appreciate this feature quite a bit; it allows them, for example, to create a single 'Students' tab that contains some content that's only delivered to first-term freshmen. I'd like to enhance DLM to do the same for the header and footer areas. This change would allow me to place links/tools/content in the header or footer that only authorized (administrative or managerial) users could access. * Here's a more concrete example of how this change will be helpful... JHU, Gary Thompson, and I just got done creating a portlet for Fragment Administration. It's a channel that gets put in your header area when your layout gets created from your templateUser. But -- based on the enhancement described above -- it will only appear in the UI if you've been authorized to render it. If it does render, it loops the fragments defined in dlm.xml to evaluate (for each) if you're authorized to edit that fragment. It compiles a list of the fragments you can edit, sorts them, then presents them in a drop-down list at the top of your layout. When you select a fragment and click the 'Edit' button, you get logged in as that fragment owner (ServletFilter + RemoteUserSecurityContext does the magic). While you're logged in as the fragment owner, a corresponding FragmentAdminExit portlet appears in your header area. This portlet allows you to click a button and log back in as yourself. I know JHU is eager to this technology as well. drew wills -- 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 3 stats recorder to database
I agree with Eric, that it should NOT be enabled by default, until the appropriate maintenance code to accompany it is also written. The maintenance code could be a simple quartz job, that truncates the table after so many (configurable) days. That combined with logging a select number of events, would probably keep it from growing out of control with 'all default' settings. Cris J H Eric Dalquist wrote: It's too much data as is. This logger is just that ... a logger. All it does it persist portal events in a nice normalized set of tables. Until someone writes summarizing and maintenance code we can't enable it without having to include giant warnings about filling up peoples databases. As an example we are using this here and track logins, logouts, channel render time, portlet action time, and page render time. This really is no different than log rolling issues we have on the file system. For comparison this is a query from our production stats table: COUNT(*)8,651,758 MIN(ACT_DATE)2008-05-30 10:43:02.85 MAX(ACT_DATE) 2008-06-06 14:08:14.943 So we've had 8.6 million events logged in 7 days and students have been gone since the 17th. My hope is that one the code is there and easy to enable (should just be uncommenting a chunk of xml) my hope would be that someone (like you) goes and writes that portlet AND a little bit of code to flush old data from the tables or aggregate it into some more manageable summary view which can be stored without concern. As for Jen's post I'd think the most minimal option would be to log page renders and possibly channel renders/portlet actions. That would allow some decent performance graphing for people. I'm also going to look into a additional config option to disable the logging of groups associated with a stats session to save on table space. Does that sound reasonable? -Eric Andrew Petro wrote: Eric, It will be disabled by default. How about enabling it by default and in time for 3.1 someone (me?) goes after adding a JSR-168 portlet that does simple queries and presents them in Jen-Feedback-Portlet-style lickable graphs, giving uPortal even more of a marketable ootb suggestion that yes, this is a suitable platform for building metrics indicators? I'm envisioning a whole happily DLM-managed Stats tab presented to the admin user... Andrew Eric Dalquist wrote: Here is a more detailed user-targeted description of the database stats recorder: http://www.ja-sig.org/wiki/display/UPC/Database+Event+Logger I'm planning on committing this to trunk later today if I don't hear any objections. It will be disabled by default. -Eric Eric Dalquist wrote: I wanted to run this proposal for a database backed portal event logger by the dev list before going forward with any commits. The schema design is based closely on what we've been using here at UW since we switched to uPortal. The PortalEvent persistence is done using JPA/Hibernate to avoid introducing another JDBC API, in performance testing using the ORM layer for event logging doesn't appear to have much excess overhead. We don't have a reporting interface for this data yet and work will likely need to be done on a tool to summarize the raw data into tables that are easier to report against as for large installs the event log tables can grow much too large for reasonable query performance. There are still a few things I need to clean up before I'd be ready to commit it, the biggest one is to setup a separate JPA persistence context to allow the stats to be stored to their own database. We discovered this is necessary in large installs as well since the portal tables and the stats tables have opposite usage semantics, as the portal DB is primarily read from and the stats tables are primarily written to. I would only plan on including this for 3.1 as there are some non-trivial changes in the framework to provide additional information for some of the portal events. As always I look forward to feedback. -Eric Eric Dalquist wrote: I have the UW database stats recorder mostly ported to uPortal 3. I've attached a patch to the Jira issue I'm using to track the work: http://www.ja-sig.org/issues/browse/UP-2075 As noted in the Jira issue there is more work to be done which should be addressed in the next few days. Feel free to apply the patch and try the code if you're so inclined, hopefully I'll have something ready for inclusion in 3.1 soon. -Eric Eric Dalquist wrote: I'm actually starting on it today, I'll keep everyone posted as I progress. -Eric Matt Peterson wrote: Cool. I think I would be more of a hindrance than a help if you’re planning on porting it yourself in the next few weeks. If it’s likely to be more than a few weeks though, I’ll gladly give it a go, as I will need it for our next phase (23^rd June). Cheers, Matt.
Re: [uportal-dev] Zip files on Windows
I'm comfortable with it. Cris J H Eric Dalquist wrote: I'm working on getting 3.0.1 ready for release. Are we all comfortable with removing the .zip distributions? -Eric Andrew Petro wrote: Cris, I think that what you propose is a very good idea, especially if accompanied by good documentation/hints/links in the download area of the website along the lines of Why is there no .zip file? How do I open this files that are here? This would also help address the downsides of use of .zip formats on platforms that would benefit by formats that retain permissions flags on the extracted files, by simply preventing the use of the less-rich .zip format. One quick band-aid we could apply would be to slap a red warning box on the download page warning folks about naively opening the .zip distros in Windows. http://www.uportal.org/download.html However, I'd want to hear and give great weight to Eric Dalquist's perspective, since he's most recently been closely involved in the distribution build process automation. Andrew Cris J Holdorph wrote: This is something I see all the time in addition to the number of times it comes up on the list. What do people think about the advantages/disadvantages of changing our distribution format. I know just about any other format would require someone to install a tool they probably don't have on their box. But isn't that the crux of the current problem? That they are trying to unarchive without installing a new tool? So, what extra work would we really be adding? By way of suggestion, what about either .tar.gz or 7-zip formats? 7-zip is a free and open source solution available for both windows, linux and mac os. .tar.gz is also available quite easily on mac os x and linux. I think 7-zip or winzip (shareware) will open .tar.gz files. The other solution, that most other apps seem to take, is building self-extracting archives (or install programs), so that the download is either a .exe or .msi file. Cris J H Eric Dalquist wrote: One thing to keep in mind on Window is that the unzipping program included in Window does not handle path names longer than 255 characters and therefor cannot be used to unzip uPortal. You will need to find another unzip tool such as WinZip to extract uPortal on Windows. '-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] up3 guest user portlet preferences
I agree. I think 4 is the best solution for most situations. Cris J H Eric Dalquist wrote: I vote for 4 as the default behavior. -Eric Jen Bourey wrote: Hi all, I've mostly completed (but not checked in) work on http://www.ja-sig.org/issues/browse/UP-2027. This ticket describes work necessary to provide a way to configure various different behaviors for portlet preferences in guest mode. Supported use cases: 1. No preferences. 2. No preferences aren't loaded from the database store, but guest users can play with portlets and set preferences on a per-session basis. 3. Preferences are loaded from the database store. Guest users can't make changes. 4. Preferences are loaded from the database store. Guest users can make changes, which will only be stored in their session. No other users will see these changes, and they will only last for that user for the length of the session. 5. Preferences are loaded from the database store, and guest users can make changes. Preferences changes will be stored to the database and shared by all users. I'm hoping these options will cover the most commonly desired behaviors. Additional behaviors could be created by subclassing this portlet preferences service implementation and overriding methods as desired. Which of the above behaviors should we set as the defaults? - Jen -- 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 -- 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] Zip files on Windows
This is something I see all the time in addition to the number of times it comes up on the list. What do people think about the advantages/disadvantages of changing our distribution format. I know just about any other format would require someone to install a tool they probably don't have on their box. But isn't that the crux of the current problem? That they are trying to unarchive without installing a new tool? So, what extra work would we really be adding? By way of suggestion, what about either .tar.gz or 7-zip formats? 7-zip is a free and open source solution available for both windows, linux and mac os. .tar.gz is also available quite easily on mac os x and linux. I think 7-zip or winzip (shareware) will open .tar.gz files. The other solution, that most other apps seem to take, is building self-extracting archives (or install programs), so that the download is either a .exe or .msi file. Cris J H Eric Dalquist wrote: One thing to keep in mind on Window is that the unzipping program included in Window does not handle path names longer than 255 characters and therefor cannot be used to unzip uPortal. You will need to find another unzip tool such as WinZip to extract uPortal on Windows. '-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] [VOTE] Tuyhang Ly for uPortal committer
+1 Eric Dalquist wrote: I'd like to propose making Tuy a uPortal committer, she has provided several high-quality patches and enhancements to uPortal 3.0 both pre and post release and it would be good to have her committing these on her own. -Eric As a reminder votes need three positive votes with no negative votes to pass. If you vote -1 please include a detailed reason. The vote will remain open until at least 5/27. -- 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] New 3.1 features
Oh, I think the detached window changes are great for uPortal. I was just commenting that it would be possible to do Detached without a WindowState, if you didn't need to force it with a PortletURL. And I think it's something we could look at in the design of things. Similar to how Exclusive windowstate was done. It affected the very next call (well really just that one url request) but after that, the window state, did not appear to be exlusive to the porlet. So, you could support a Detached window state, so that a portlet who wants to write a portlet url to do that, can force it to happen. But other portlets, can 'support' being detached, without needing any uPortal specific code, as long as there is a portal control. I would then encourage as many portlets hosted OUTSIDE of the uPortal code base, to resist (or at least have it configurable) using the portal specific window states, so they portlets can be used in other portals. I would really like to avoid seeing JA-SIG portlets turn into the mess that most of the JBoss and liferay portlets are, where they can't be run outside of that portal. So, to summarize my votes: yes - detached support for portlets in uPortal. Yes - support for detached window state in portlet urls, for portlets that want to do that. No (or make it optional) to most portlets released into open source using portal specific portlet modes or window states. Cris J H Eric Dalquist wrote: The ability to do this via a PortletURL is the motivating factor for the new WindowState. A detached portlet would be very similar from the portlets view to being maximized. At least locally we'll have to allow portlets to trigger this via a PortletURL. Also, if any bits of these two issues seem a bit too narrow for uPortal in general please say-so we can always do these local-only first and go from there. I'd just rather do it in uPortal core and forgo the local-only step if everyone is comfortable with that. -Eric Cris J Holdorph wrote: I think a new Portlet Window for the same portlet entity is the right way to handle detached. However, it strikes me, that if you go that route, a new WindowState may not be needed at all. Unless there's some reason for a portlet to care that they are in a separate window, I think a new window state just encourages coding portlets that are not as portable. The only 'upside' I could see, is the ability to create a PortletURL that would cause the detached behavior, rather then relying on Portal controls. Cris J H Eric Dalquist wrote: For the DETACHED WindowState: - The use-case here is a portlet that pops open search results in new windows. These results would be able to be further refined by the user via controls in the pop-up window while the user can still interact with the original portlet on the tab. - The portlet object model does support the idea of multiple PortletWindows into one subscribed PortletEntity, this scopes the request parameters, WindowState and PortletMode from each instance the user interacts with while the session and preferences are still shared. I hope that helps clarify a bit. I'll update the jira issues later today. -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] New 3.1 features
What's the motivation behind the 'human readable' part? Do you expect, (as a student) I can read the URL, that at some point in the future, I'll simply type in http://myportal.myuniv.edu/supercooltab/someportlet in my address bar, because I remember I have a supercool tab and I put some portlet on that tab? Or is the motivation instead, something different? I'm not sure what human readable URL means if it's not the above use case. I think the first half of the JIRA makes sense, but wouldn't describe that as human readable url. The aspect of being able to control which tab/portlet is being displayed and what the portlet window state was with altering the URL, I think is interesting. But what part of those features requires it to be 'human readable'. Also, your second half of the jira, which Mark is commenting on, about tab/page/column doesn't seem to match up with what you described in the first half. Cris J H Mark Boyd wrote: Eric, Recall that uportal infrastructure sees layouts as folders and channel not tabs and columns. So if anyone ever does decide to put together a non tab/column layout this approach (like the paging that Susan B. started looking at a couple years ago) wouldn't make sense for these enhanced layouts. Secondly, keep in mind that tab labels can be internationalized. (Or could be if we ever roll the Luminis approach from the sandbox into baseline.) So you may well have mult-byte characters in those tab names. Perhaps we need to add a new friendly URL name to folders before such a folder (tab) is made available via such URLs. Or it can be mandatory with the caveat that its content must only consist of characters support by the URI spec. Ditto for channels. Food for thought. Mark On Wed, May 7, 2008 at 1:55 PM, Eric Dalquist [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: We have a portlet project coming through the pipes here that is going to require some new uPortal functionality. In an attempt to do this the right way I've described both features in uPortal Jira issues and plan on trying to implement them in uPortal directly then merge the features into our local version. I'd like to get other developers feedback on that approach and on ideas around these features. The first is human-readable / search engine friendly URLs: http://www.ja-sig.org/issues/browse/UP-2045 The second is a detached WindowState for portlets: http://www.ja-sig.org/issues/browse/UP-2046 -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 -- 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] uP3 template user default groups
I think I'm confused by what you said here. You said you changed defaultTemplateUser and gave one of the reasons why, because you didn't think that all users should be added to the developer group. Then you ask if we should put the new template user in the developer group. What am I missing? Cris J H Eric Dalquist wrote: We created a new defaultTemplateUser for the framework to use as a template for all new users. This replaces the demo user that has been used until now. The demo user was in the Developer group which resulted in all new users being placed in that group. Should we simply add the defaultTemplateUser to the same group? -- 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] uP3 template user default groups
Ok, in that case, I do not think that everyone in a uPortal deployment should be in the Developers group. If the developers group is going to exist, it should have some kind of 'developers' meaning, not really be synonymous with 'everyone'. But for what it's worth, I'm not sure, in my vision I see a big difference between administrators and developers, where uPortal is concerned permission wise. I'm with Drew on voting the PAGS route to create a rule that matches everyone. And having that PAGS group be a member of Everyone. Cris J H Eric Dalquist wrote: Sorry, the actual impetus for the change was to have a blank user who's only purpose is to be a template for new uPortal users instead of overloading the demo user like had been done historically. The new template user not being in the Developer group is just part of it being a new, blank, user. This does bring up the issue of how do we make new users appear to be in the Everyone group without loading up the database. -Eric Cris J Holdorph wrote: I think I'm confused by what you said here. You said you changed defaultTemplateUser and gave one of the reasons why, because you didn't think that all users should be added to the developer group. Then you ask if we should put the new template user in the developer group. What am I missing? Cris J H Eric Dalquist wrote: We created a new defaultTemplateUser for the framework to use as a template for all new users. This replaces the demo user that has been used until now. The demo user was in the Developer group which resulted in all new users being placed in that group. Should we simply add the defaultTemplateUser to the same group? -- 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] https://www.ja-sig.org/svn/up2 rename
It doesn't look like this happened. Did it? I still only see the up2 entry. Cris J H Eric Dalquist wrote: Thursday morning around 9am CDT the up2 folder in Subversion will be renamed to uPortal; https://www.ja-sig.org/svn/up2 to https://www.ja-sig.org/svn/uPortal After the rename you will need to run the svn switch command[1] to switch the SVN url of code you have checked out. This applies to the uPortal trunk, branches and tags. This does not apply to any code you have downloaded from www.uportal.org Also there will be a short (15 minute) SVN outage just before the rename. Please plan on avoiding any commits or relying on SVN availability from 8:30am to 9:30am CDT Thursday morning. Thank you, Eric Dalquist [1] http://svnbook.red-bean.com/en/1.0/re27.html -- 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] https://www.ja-sig.org/svn/up2 rename
ah, reading comprehension thanks for pointing out the obvious. Sorry everyone. Cris J H Jen Bourey wrote: I think it's scheduled for tomorrow morning. - Jen On Wed, Mar 26, 2008 at 12:16 PM, Cris J Holdorph [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: It doesn't look like this happened. Did it? I still only see the up2 entry. Cris J H Eric Dalquist wrote: Thursday morning around 9am CDT the up2 folder in Subversion will be renamed to uPortal; https://www.ja-sig.org/svn/up2 to https://www.ja-sig.org/svn/uPortal After the rename you will need to run the svn switch command[1] to switch the SVN url of code you have checked out. This applies to the uPortal trunk, branches and tags. This does not apply to any code you have downloaded from www.uportal.org http://www.uportal.org Also there will be a short (15 minute) SVN outage just before the rename. Please plan on avoiding any commits or relying on SVN availability from 8:30am to 9:30am CDT Thursday morning. Thank you, Eric Dalquist [1] http://svnbook.red-bean.com/en/1.0/re27.html -- 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 mailto:uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- 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 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 -- 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] channel/tab terminology
I disagree to an extent. I think continuing to use the term Channel reinforces the past. When people look to adopt a portal, what are they going to think if they see one Portal that is portlet based and one that is 'proprietary channel' based. I feel like reducing the visibility/use of the term 'channel' will help in the marketability of uPortal. Cris J H Andrew Petro wrote: Jen, I favor sticking with the historical tab and channel terminology for this release. It maximizes the re-usability of existing documentation. I object to portlet as the generic term for the dynamic boxes on the screen in the uPortal documentation and terminology because it is confusing in its relationship to JSR-168 Portlets. Some of the channels are implemented as JSR-168 portlets. Some are not. Technically, all of them are channels and can benefit by channel things, like channel types, metadata about which channel controls to show, categorization, and selection of audiences permitted to subscribe to them. I see why implementing schools might adopt portlet, or widget, or channel, or thingamabob as their local terminology. End users don't need to understand JSR-168 and the distinction of which channels are JSR-168 portlets and which are not. The target audience of the uPortal release, however, tends more towards the IT staff of higher education institutions who might adopt and implement uPortal locally. Avoiding calling things portlets that are not Portlets has value for this audience. I like the term tab. Using the default theme and skin, they look like tabs. I find it easier to explain this to people in terms of tabs, and then tell them that if they want they could look like something other than tabs. Tabs are nicely concrete and palpable and easier to grok. I like using managed fragment to differentiate between DLM managed tabs and end-user personal layout tabs. The term page has too much content management system expectations associated with it. uPortal *isn't* a content management system and you *don't* interact with pages in the sense of Drupal or HyperContent. Andrew Timothy Carroll wrote: we have implemented a bit more hierarchy than the out of box uportal. we use the terms tabs, pages, portlets Jen Bourey wrote: Hi all, In cleaning up the up3 UI, I've noticed that the terminology isn't always consistent. What do we want to use? I think historically we've used channel and tab as terms? At Yale, we've switched to calling those items portlets and pages, not that that's necessarily better. I don't have strong feelings about what terminology we use, although I would like to fix it to all be the same. What would everyone prefer? - Jen -- -- 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] uPortal policy on supported web browsers
I know it hasn't happened yet, might not happen, and if it did happen we should have time to react to it before it causes us a problem... However, I wonder about the Microsoft bid for Yahoo and if Microsoft does acquire Yahoo, what they will think about that list. Is there an equivalent out there, that isn't so close to being swallowed by one of the vendors with a vested interest in the list? But +1 for a list in general. Cris J H Andrew Petro wrote: uPortal developers, I'd like to see the project adopt a policy about what web browsers uPortal supports. Fortunately, the Yahoo YUI folks have an A-grade browser policy that I think[1] tracks very well with what uPortal support ought to be. Making the policy that of supporting YUI-graded A-grade browsers has some very nice properties in that they keep the list up to date and so uPortal will have a go-to, commonly respected, external criteria rather than dithering internally about which browsers to support. I've drafted a policy statement in the uPortal manuals: uP3 manual: http://www.ja-sig.org/wiki/x/LYKi uP2 manual: http://www.ja-sig.org/wiki/x/LIKi I'd like for one of two things to happen: 1) A flurry of +1s and huzzahs sufficient to adopt this browser support policy, so that we have one, making the project more marketable and setting a path. 2) responses leading to discussion that brings us to an even better policy statement, for which we can then have (1). Thanks, Andrew [1]: Thanks are due to Colin Clark, the rest of uPortal steering committee, and Gary Thompson in helping me to become informed enough to think about this. -- 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] uPortal Project
I'm sure someone else will chime in with a longer response. My best suggestion is to take a look at some of the more recent bugs entered into Jira against the uPortal project. http://www.ja-sig.org/issues/secure/BrowseProjects.jspa Find a bug you are both interested in seeing fixed, and one you think you have the ability and interest to fix. Then fix the bug if you can. When you're done, create a patch and attach it to the Jira with a comment describing what you've done. Then post here on the uportal-dev list, asking over people to review the patch. This is how I think someone could best get involved with coding/contributing to the uPortal project. In terms of testing, just installing and running uPortal will help. The uPortal project doesn't have a set of formal test cases, so it's kind of make it up as you go. I do know the forthcoming uPortal 3 release, would appreciate as many hands as possible downloading, testing, and reporting any bugs that are found (also to the same Jira link posted above). Cris J H Longwe, Miya W wrote: Dear Folks How can I get involved or contribute to the uPortal project i.e. coding, testing, etc? We are planning on deploying uPortal at BU’s School of Management. Best, Miya W. Longwe -- 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] Weather Portlet: AccuWeather.com Service
I don't think this portlet should ship WITH uPortal. I'd hate to see the main uPortal distribution encumbered with a license we somehow have to make sure commercial entities see and agree to, and contact accuweather, before they can ever start uPortal. Now as a separate download that people can go to some place and 'read the license' for that specific portlet before clicking on the link to download it, I think it is probably fine. Cris J H Jim Helwig wrote: I don't see a logo or link back as a problem. Since our primary focus is higher education, I don't see the fact that commercial users need to contact AccuWeather as a problem. From the sounds of it, this seems like a good option. It would be nice to see if this portlet could be implemented in a way that one could fairly easily plug in alternative weather feeds if they were concerned about this. My two cents, JimH on 2/13/2008 7:16 PM Dustin S. said the following: I have recently been in contact with AccuWeather.com to explore the possibility of using their services for weather data. AccuWeather.com's services are used in one of the most popular Firefox add-ons: ForecastFox. If you are unfamiliar with AccuWeather you can visit http://www.accuweather.com/ AccuWeather.com's people have been very friendly and nice to work with and have setup an XML weather service for uPortal to use in the weather portlet. An example: http://uport.accu-weather.com/widget/uport/weather-data.asp?location=16803metric=1 http://uport.accu-weather.com/widget/uport/weather-data.asp?location=16803metric=1 Use of their service in the weather portlet would require an AccuWeather logo and a link back to their site. The feed would be available without permission for all non-commercial users assuming they retain the logo and link back. They would like any commercial users to contact AccuWeather for permission to use the data. They said that commercial users are generally not a concern unless they are a large commercial user that could cause an overload to their servers. AccuWeather has /extensive/ international coverage of weather as well as /extensive /weather data and they seem to be very willing to work with us. I would really like to use AccuWeather's service but I'm not sure the commercial aspects would be acceptable to have this portlet included in UP3 hence the reason for this post. What does everyone else think? -- 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 -- 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 repository
Ok, I'm asking here, because my main purpose for doing this is to benefit the uPortal community. Although, it's not a specific uPortal question. I am currently the maintainer of a Google Portlet on the code.google.com hosting site. This portlet was exchanged in uPortal 2.6 for a version that could no longer be used by 'new' adopters. Anyway, with uPortal 3.0 moving to a maven build, it would be helpful for as many of it's dependencies as possible (all, would be nice) to be maven dependencies and in the central repository. So, I'd like to do my part and get my google portlet into the maven repository. I have read this guide at the maven web site. http://maven.apache.org/guides/mini/guide-central-repository-upload.html And I'm confused about the 'sync' approach. I find it odd, but entirely possible, that by having chosen google code to host the project, I will be unable to use the 'sync' approach. Does anyone have experience with this? Or more generally does anyone have experience with getting artifacts in the maven repository at all? I'm looking for help, and my Google searches so far have not turned up much help. Cris J H -- 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] Renaming https://www.ja-sig.org/svn/up2
I think the naming change to the subversion repository is both necessary and required if we're really going to call the next release version 3.0. So, +1 from me, despite any challenges it might bring. Cris J H Eric Dalquist wrote: So way back when uPortal 2 and uPortal 3 were separate code bases we moved from CVS to SVN. As part of this move I had the brilliant idea to include a version number in the name of the SVN path for uPortal 2.X (up2) and uPortal 3.X (up3). With the very smart change in direction we made in the last year /up3 has been moved to /sandbox/portal but /up2 remains. As we get closer to a 3.0.0-GA release this may be an issue we want to address. I would like to get peoples feelings on renaming /up2 to /uPortal. I believe that if we did this everyone that currently has /up2 checked out would need to do a new check out of /uPortal. Is the 2 in the path something we need to worry about? -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] uP3 persistence libraries
There are few 'trends' that most in the community seem to agree on. Eclipse was the first I noticed in this community. Hibernate and Spring were the second and third (not sure the order). I don't think you'll find much dissension on using Hibernate. But If you really wanted to open the door and think about all the reasons why or not, to use Hibernate, there is one downside. RedHat/JBoss and Interface 21 do not get along. I get the impression that some people use iBatis not because they think it's better then Hibernate, but because of the riff here and a desire to use something other then Hibernate. Personally, I'd use Hibernate. +1. Cris J H Eric Dalquist wrote: As I progress with the Pluto 1.1 integration in the trunk I'm getting closer to the point of needing to write some new DAOs to persist some portlet domain objects. I would like to propose using Hibernate 3 for _new_ DAO implementations. Initially this just provides an easy way to write DAOs for object persistence, in the very long term we could plan on moving all DAOs to Hibernate to take advantage of schema creation and cross-database support. For 3.0 Hibernate would only be used for new DAOs and all existing data access code would remain as is. -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] RDBMServices, JNDI JDBC
I'd have stronger opinions if I was using an environment other then Tomcat. However, in the Tomcat environment I don't see that it matters much either way. In higher end app-server environments, it's probably appropriate to let that server control the pools. Even so, you can configure spring to use JNDI datasources on a per installation environment if you need to. So I see no harm in converting if you feel strongly. Another thing to look at for a few minutes though, might be the recent flurry in the Sakai community trying to convert from Commons Connection Pooling to C3PO, which they did in response to a bug they hit in commons pooling. Cris J H Eric Dalquist wrote: Anyone have any thoughts on this? If I don't hear any reasons to keep the JNDI configs as the default way of doing things I'll be changing trunk to use commons-pool managed DataSources in the portal's application context. -Eric Eric Dalquist wrote: The issue of where to put those darn JDBC drivers has come up a few times in the last week or so on the -user list and has historically been a bit of an issue. I would like to propose no longer using a JNDI configured DataSource by default. With the consolidated Spring configuration I would like to create a dataSourceContext.xml as a place to configure JDBC DataSource objects. RDBMServices would be deprecated and re-worked to provide access to the DataSource objects from the Spring context. As work progresses to move more components into a Spring managed world they could bypass RDBMServices and simply have the DataSource injected directly. -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] RDBMServices, JNDI JDBC
Yeah, I wasn't trying to make a vote for moving, simply taking notice and making an informed decision. I haven't done any perf testing recently to compare the two, so I'm not in a good position to recommend one over the other. Cris J H Jason Shao wrote: On Oct 8, 2007, at 12:38 PM, Cris J Holdorph wrote: I'd have stronger opinions if I was using an environment other then Tomcat. However, in the Tomcat environment I don't see that it matters much either way. In higher end app-server environments, it's probably appropriate to let that server control the pools. Even so, you can configure spring to use JNDI datasources on a per installation environment if you need to. So I see no harm in converting if you feel strongly. Another thing to look at for a few minutes though, might be the recent flurry in the Sakai community trying to convert from Commons Connection Pooling to C3PO, which they did in response to a bug they hit in commons pooling. There's still some work to be done on the Sakai side -- UMich thinks disabling inactive session in DBCP will avoid the deadlocking bug, and Rutgers is actually going back to dbcp since there were other sideaffects related to different default values for autocommit and transactionIsolationLevel (likely Sakai specific though) Proxool seems to get some votes too -- though Juergen was complaining on TSS that there aren't any really good, clear OS choices for pools. Jason -- Jason Shao Application Developer Rutgers University, Office of Instructional Research Technology v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | http://jay.shao.org -- 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] Wrong port number being returned?
Actually, there is a Portlet method on javax.portlet.PortletRequest.getServerPort() I'm not sure how much I would want to rely on it as a Portlet given the general Portlet approach to URLs, but it's not something that you have to unwrap the PortletRequest to get at. Cris J H Eric Dalquist wrote: For anything executing as a JSR-168 portlet there is no valid request.getServerPort() call. While technically you can access a HttpServletRequest object when rendering in a JSP that object should never be used, the portlet's request/response objects must be used instead. The main question is how are URLs generated, as Chris pointed out portlets must generate URLs through an API that takes care of the entire URL string. My guess is there is something else going on with URL generation for the portlet (string concatenation or some such) and the format just happens to be close enough to what uPortal expects to work. -Eric Jason Shao wrote: On Oct 2, 2007, at 5:54 PM, Anastasia Cheetham wrote: Hi, everyone, We're observing a strange bug in a tool that we're deploying as a portlet in uPortal. I'm hoping that someone might be able to shed some light on it. The tool converts relative URLs to absolute URLs, but it's inserting a wrong port number. Our uPortal instance is running on port 8090, but the port number that turns up is 80. When the URLs are tested with the right port number substituted, they work. In case it matters: The tool is actually a Sakai tool that is wrapped as a portlet. When it runs within Sakai (which is running on port 8080) all is fine. No port number is included in the absolute URL, and in the Sakai context, this works. 1. wrapped as a portlet? are you using some kind of bridge servlet (like the Struts-Bridge?) 2. What do the connectors in your server.xml look like? 3. (probably only applies if you're using a bridge servlet) If you call request.getServerPort() what do you get? Jason -- Jason Shao Application Developer Rutgers University, Office of Instructional Research Technology v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | http://jay.shao.org -- 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] uP3 Progress Report
I know there was discussion of up3 at the barcamp at the ja-sig conference in June. Unfortunately, I had a 3.5 hour workshop to deliver during that time so I was unable to participate. What I don't understand is why the initial effort is being put towards the activities you mention and converting uPortal to Pluto 1.1 (or hopefully pluto 2.0) is not mentioned at all. JSR 286 was Finalized on August 27, 2007 (that was the date votes closed). If we release uPortal 3.0 nearly 1 year later in summer 2008 without JSR 286 support, I think that will send an unintentional message to Portal consumers/adopters/developers. So, while I can appreciate the great value in the conversion to Maven, and Spring Web MVC Dispatcher Servlet, I would to know more about how uPortal 3 is going to improve on it's support of Portlets (or even Channels if that was worthwhile). Cris J H Eric Dalquist wrote: There hasn't been much traffic on about the uP3 work since the conference and hopefully this is the first of many messages resolving that problem. Work has been happening on converting the trunk of the uPortal project to use Maven 2 as the build system. This has been a complete conversion so much of the directory structure has been re-arranged. The work is complete and, with a little testing from folks on this list, ready to be merged from the 'working-maven' branch back into the trunk. I would encourage everyone to check out from the branch and give it a try. There is a build.xml file that at this point replicates the main Ant targets used by developers pre-conversion, initportal is still all you need to run to get everything going after setting up build.properties. Please provide feedback, there are bound to be rough spots and missing developer features and hearing from developers is how they will be fixed. One known issue: Ant 1.7 will not work, there is a nasty little bug that will be fixed in 1.7.1, for now use Ant 1.6 With this progress and new build system I need to get it properly documented and have a place for documentation as this effort moves forward. After looking through the wiki and chatting in IRC I have the following proposal. All documentation in the uPortal 3 space related to the uPortal 3 sandbox code would be consolidated and moved under a uP3-Sandbox page then the uPortal 3 space would be used for documentation of the goals of this effort and documentation of changes as they happen. I'd like to get other thoughts and suggestions as to how to deal with the wiki documentation as well. The next step in the uP3 effort is consolidating the multiple Spring configurations in the project and replacing the inner workings of the static services with Spring configurations. Also related to this would be looking at using a Spring DispatcherServlet as the root servlet for uPortal, using Acegi to replace security.properties and similar tasks. Along side the documentation effort I'll be detailing these as sub-tasks of the root Spring related issue: http://www.ja-sig.org/issues/browse/UP-1789 I'll post an update when I get these sub-tasks details to look for some help in getting them done. -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] [VOTE] 2.6.1-GA
+1 Cris J H Eric Dalquist wrote: With no negative feedback on the RC I'd like to propose cutting the 2.6.1-GA release based on this code. Please respond with your vote on releasing. Thank you, -Eric Eric Dalquist wrote: uPortal developers, uPortal 2.6.1 release candidate one is now available from the uPortal downloads page^ http://www.uportal.org/release/allReleases.html. A release candidate signals feature completeness, makes a binary available for easy downloading and testing, and provides a concrete artifact to talk about and open issues against. It also defines a serious candidate for release as uPortal 2.6.1 GA. There are a short list of known issues to be resolved before GA, but it's a short list. Unless additional significant issues are raised, this will be uPortal 2.6.1. Release notes are available in the wiki^ http://www.ja-sig.org/wiki/display/UPC/2.6.1+RC1. Since the GA release of uPortal 2.6.0, six issues have been addressed, including a functional off-line build and deploy script. Eric Dalquist uPortal 2.6.1 release engineer -- 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-user] uPortal Session Failures?
Please let me know when a 2.6 patch is available, I have a training class going right now, where multiple machines are experiencing this problem with uPortal 2.6.0. If we see a patch we could test it on a couple machines. Cris J H Eric Dalquist wrote: There is a possible patch for this issue attached to the Jira case: http://www.ja-sig.org/issues/browse/UP-1816 This patch *_HAS NOT_* been extensively tested yet and makes some significant changes in the ChannelRender and related code. The Jira issue also has a link to yesterday's IRC log which I would recommend reading if you are interested in an in-depth discussion about the probably underlying issue causing the session bug. The high level overview is that due to uPortal's multi-threaded rendering model the Tomcat requestDispatcher is creating incorrectly wrapped HttpServletRequest objects to pass to the portlets for rendering. A more detailed overview follows, if there are questions about the patch please ask. Until an errata was recently filed in the servlet 2.4 spec it was against spec to allow multiple threads to access the request or response objects. The errata changed this so that it is no longer against spec but containers can optionally support multi-threaded access to these objects. With this wording it is not specifically a Tomcat bug, just an optional part of the spec that Tomcat does not implement. The patch involves having the ChannelRenderer.Worker class, which invokes rendering on a channel, create a wrapper around the HttpServletRequest specific for the thread that Worker is running in. The wrapper implements HttpServletRequest directly instead of extending HttpServletRequestWrapper to stop Tomcat from un-wrapping the wrapper. Passing objects back to the servlet container that are not either the original request object or extended from HttpServletRequestWrapper is also against the servlet spec, though breaking spec compliance in this area should fix the session problem and doesn't appear to cause other problems. The objects, specifically PortalControlStructures, which track the request and response through the rendering pipeline have also been modified to use ThreadLocals. This allows each rendering thread to have its own request and response objects as required by this patch. This patch is very closely based on code that UW-Madison has been running since going live in June 2006. It was not contributed back earlier due to both the significance of the changes in the rendering pipeline and the thought that the problem being addressed by the change was specific to a special case here at UW. I would encourage people experiencing the session problem and those who are familiar with the inner workings of the uPortal channel rendering code to try the patch and provide feedback. The patch was created against the 2.5-patches branch. Once some testing has been done on it confirming its viability I will create a patch for the 2.6-patches branch as well. -Eric Elliot Metsger wrote: Yup, I pulled HEAD of the 2-6-patches branch, and the buggy behavior still exists Parker Grimes wrote: Elliot, Yes we are using uPortal 2.6.0 GA with no custom patches. getMarkup() in CPortletAdapter is synchronized. -Parker On 9/9/07, Elliot Metsger [EMAIL PROTECTED] wrote: Hi Parker, Quick question: are you using uPortal 2.6.0 GA? Have you applied any custom patches? I'm curious if your CPortletAdapter's getMarkup() method is synchronized. Parker Grimes wrote: This is sounding very familiar to what we have been experiencing. We use uPortal 2.6.0 and the Spring Portlet MVC. -- View this message in context: http://www.nabble.com/uPortal-Session-Failures--tf4116258.html#a12582790 Sent from the uPortal - User mailing list archive at Nabble.com. --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user -- 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-user] uPortal Session Failures?
I apologize if this is in the IRC log. two questions. 1) why does the pluto 1.1 driver (test portal) not exhibit the same problem? Do they do something similar to what your patch does for uPortal? Specifically breaking part of the servlet spec (even though it probably is ok to do so)? 2) Will this change work in other containers? I know that CalPoly uses WebSphere (or did at some point in the past) and Colorado uses Resin. And a bonus question... * Does Tomcat 6 implement this optional 'erata' part of the Servlet spec? That is if, someone spent enough time to get uPortal 2.6.0 running in Tomcat 6, are they unlikely to see the same problem? Cris J H Eric Dalquist wrote: There is a possible patch for this issue attached to the Jira case: http://www.ja-sig.org/issues/browse/UP-1816 This patch *_HAS NOT_* been extensively tested yet and makes some significant changes in the ChannelRender and related code. The Jira issue also has a link to yesterday's IRC log which I would recommend reading if you are interested in an in-depth discussion about the probably underlying issue causing the session bug. The high level overview is that due to uPortal's multi-threaded rendering model the Tomcat requestDispatcher is creating incorrectly wrapped HttpServletRequest objects to pass to the portlets for rendering. A more detailed overview follows, if there are questions about the patch please ask. Until an errata was recently filed in the servlet 2.4 spec it was against spec to allow multiple threads to access the request or response objects. The errata changed this so that it is no longer against spec but containers can optionally support multi-threaded access to these objects. With this wording it is not specifically a Tomcat bug, just an optional part of the spec that Tomcat does not implement. The patch involves having the ChannelRenderer.Worker class, which invokes rendering on a channel, create a wrapper around the HttpServletRequest specific for the thread that Worker is running in. The wrapper implements HttpServletRequest directly instead of extending HttpServletRequestWrapper to stop Tomcat from un-wrapping the wrapper. Passing objects back to the servlet container that are not either the original request object or extended from HttpServletRequestWrapper is also against the servlet spec, though breaking spec compliance in this area should fix the session problem and doesn't appear to cause other problems. The objects, specifically PortalControlStructures, which track the request and response through the rendering pipeline have also been modified to use ThreadLocals. This allows each rendering thread to have its own request and response objects as required by this patch. This patch is very closely based on code that UW-Madison has been running since going live in June 2006. It was not contributed back earlier due to both the significance of the changes in the rendering pipeline and the thought that the problem being addressed by the change was specific to a special case here at UW. I would encourage people experiencing the session problem and those who are familiar with the inner workings of the uPortal channel rendering code to try the patch and provide feedback. The patch was created against the 2.5-patches branch. Once some testing has been done on it confirming its viability I will create a patch for the 2.6-patches branch as well. -Eric Elliot Metsger wrote: Yup, I pulled HEAD of the 2-6-patches branch, and the buggy behavior still exists Parker Grimes wrote: Elliot, Yes we are using uPortal 2.6.0 GA with no custom patches. getMarkup() in CPortletAdapter is synchronized. -Parker On 9/9/07, Elliot Metsger [EMAIL PROTECTED] wrote: Hi Parker, Quick question: are you using uPortal 2.6.0 GA? Have you applied any custom patches? I'm curious if your CPortletAdapter's getMarkup() method is synchronized. Parker Grimes wrote: This is sounding very familiar to what we have been experiencing. We use uPortal 2.6.0 and the Spring Portlet MVC. -- View this message in context: http://www.nabble.com/uPortal-Session-Failures--tf4116258.html#a12582790 Sent from the uPortal - User mailing list archive at Nabble.com. --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see
Re: [uportal-dev] [uportal-user] uPortal Session Failures?
I have a problem with the 2.6 patch, it complains my PortalControlStructures.java does not match. Cris J H Eric Dalquist wrote: Patches that should work on the last rev from both the 2-5-patches and 2-6-patches are now attached to the Jira issue: http://www.ja-sig.org/issues/browse/UP-1816 -Eric Cris J Holdorph wrote: I apologize if this is in the IRC log. two questions. 1) why does the pluto 1.1 driver (test portal) not exhibit the same problem? Do they do something similar to what your patch does for uPortal? Specifically breaking part of the servlet spec (even though it probably is ok to do so)? 2) Will this change work in other containers? I know that CalPoly uses WebSphere (or did at some point in the past) and Colorado uses Resin. And a bonus question... * Does Tomcat 6 implement this optional 'erata' part of the Servlet spec? That is if, someone spent enough time to get uPortal 2.6.0 running in Tomcat 6, are they unlikely to see the same problem? Cris J H Eric Dalquist wrote: There is a possible patch for this issue attached to the Jira case: http://www.ja-sig.org/issues/browse/UP-1816 This patch *_HAS NOT_* been extensively tested yet and makes some significant changes in the ChannelRender and related code. The Jira issue also has a link to yesterday's IRC log which I would recommend reading if you are interested in an in-depth discussion about the probably underlying issue causing the session bug. The high level overview is that due to uPortal's multi-threaded rendering model the Tomcat requestDispatcher is creating incorrectly wrapped HttpServletRequest objects to pass to the portlets for rendering. A more detailed overview follows, if there are questions about the patch please ask. Until an errata was recently filed in the servlet 2.4 spec it was against spec to allow multiple threads to access the request or response objects. The errata changed this so that it is no longer against spec but containers can optionally support multi-threaded access to these objects. With this wording it is not specifically a Tomcat bug, just an optional part of the spec that Tomcat does not implement. The patch involves having the ChannelRenderer.Worker class, which invokes rendering on a channel, create a wrapper around the HttpServletRequest specific for the thread that Worker is running in. The wrapper implements HttpServletRequest directly instead of extending HttpServletRequestWrapper to stop Tomcat from un-wrapping the wrapper. Passing objects back to the servlet container that are not either the original request object or extended from HttpServletRequestWrapper is also against the servlet spec, though breaking spec compliance in this area should fix the session problem and doesn't appear to cause other problems. The objects, specifically PortalControlStructures, which track the request and response through the rendering pipeline have also been modified to use ThreadLocals. This allows each rendering thread to have its own request and response objects as required by this patch. This patch is very closely based on code that UW-Madison has been running since going live in June 2006. It was not contributed back earlier due to both the significance of the changes in the rendering pipeline and the thought that the problem being addressed by the change was specific to a special case here at UW. I would encourage people experiencing the session problem and those who are familiar with the inner workings of the uPortal channel rendering code to try the patch and provide feedback. The patch was created against the 2.5-patches branch. Once some testing has been done on it confirming its viability I will create a patch for the 2.6-patches branch as well. -Eric Elliot Metsger wrote: Yup, I pulled HEAD of the 2-6-patches branch, and the buggy behavior still exists Parker Grimes wrote: Elliot, Yes we are using uPortal 2.6.0 GA with no custom patches. getMarkup() in CPortletAdapter is synchronized. -Parker On 9/9/07, Elliot Metsger [EMAIL PROTECTED] wrote: Hi Parker, Quick question: are you using uPortal 2.6.0 GA? Have you applied any custom patches? I'm curious if your CPortletAdapter's getMarkup() method is synchronized. Parker Grimes wrote: This is sounding very familiar to what we have been experiencing. We use uPortal 2.6.0 and the Spring Portlet MVC. -- View this message in context: http://www.nabble.com/uPortal-Session-Failures--tf4116258.html#a12582790 Sent from the uPortal - User mailing list archive at Nabble.com. --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You are currently subscribed to [EMAIL PROTECTED] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-user --- You
Re: [uportal-dev] Spring PortletMVC
The simplest way to do this is to set the EDIT mode on the portlet url , that you use for the target of the form. So, if edit mode has a form to fill in certain settings, you need a portlet action url to be the target for the html form. on that portlet action url, simply have the portlet mode set to 'VIEW', then when th user submits the form, after the Action processing is done they will go to the VIEW mode for render. It's also possible to set the portlet mode to view programatically in the action processing. There might be good reasons to do it either way. I just view doing it in the PortletURL as less code to write. Cris J H Jennifer Bourey wrote: How do you handle sending the portlet back to view mode? Does this happen automatically, or are you manually setting the mode? Thanks! - Jen On Sep 7, 2007, at 11:50 AM, Parker Grimes wrote: Here are some screenshots of one of our portlets. One in view mode and the other in edit mode. When you click Save or Cancel in edit mode it returns you to view mode. -Parker - Jennifer Bourey Technology and Planning Yale University ITS 203.432.5718 -- 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 -- 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] Requiring Jira issue ids in commit messages
I'm in favor of it as well. I was just lamenting this morning, that another project I am on, does not have it and I hope they introduce it soon. Cris J H Andrew Petro wrote: Eric, I favor adopting the script. We use it internally at Unicon and headaches are minimal. It's relatively gentle and friendly -- since SVN is transactional you don't get broken half-commits with it, and it gives you an error message telling you how to conform to the commit message requirement, this even shows up in the Eclipse console. Andrew Eric Dalquist wrote: Brad Szabo was kind enough to share a SVN script that would require a Jira issue id to be referenced in the commit message for any commit. The script can be bypassed explicitly by adding NOJIRA instead of an issue ID and also allow commits from some automated tools such as the maven release plugin. What are people's feelings on adding this script to our repository? It would require developers to at least acknowledge if there isn't a relevant Jira issue and remind us when we forget to add a reference to the relevant issue that does exist. I don't want to add something that is going to cause headaches or difficulties for commitiers but an automated catch might be nice to help enforce good behavior. -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
