[uportal-dev] moving on
Everyone, I have accepted a position at another company (TASC: https://tasconline.com) and my last day in the office at UW-Madison is Friday Jan 25. I am still personally interested in the Jasig/Apereo community, particularly Bedework, and I hope to contribute at some level on my own personal time. I really have enjoyed working with you all and hope that we will have more opportunities to do so in the future. My UW address (npbl...@wisc.edu) will not be active for too long, please update your contact to use this address. Thanks! Nick -- 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] Microsoft EWS API
The best thing to do is encourage the jcifs project to publish their artifacts with sonatype. Sonatype strongly discourages listing repositories in project poms, as a result calendarportlet may have difficulties being published with dependency on jasig repo. I recently ran into the same problem with ical4j, the author was really accommodating and now that's published to central through sonatype. On Nov 10, 2011 9:22 AM, Jen Bourey jennifer.bou...@gmail.com wrote: Hey Anthony, The calendar portlet actually already has an Exchange adapter out of the box. It uses spring-ws to connect to the services, which seems not too require too much custom code. I know Nick is also currently doing some EWS integration into the Scheduler too. Maybe there's an opportunity to create some documentation and best practices around Exchange integration? How've you found the Java library your'e using to be so far? - Jen On Thu, Nov 10, 2011 at 9:21 AM, Jen Bourey jennifer.bou...@gmail.comwrote: Hey Anthony, The calendar portlet actually already has an Exchange adapter out of the box. It uses spring-ws to connect to the services, which seems not too require too much custom code. I know Nick is also currently doing some EWS integration into the Scheduler too. Maybe there's an opportunity to create some documentation and best practices around Exchange integration? How've you found the Java library your'e using to be so far? - Jen On Nov 9, 2011, at 7:31 PM, Anthony Colebourne wrote: cc: licens...@jasig.org Hi, I want to contribute some Exchange 2010 adapters (development in progress). * CalendarPortlet * NotificationsPortlet Also in future * ContactsPortlet * EmailPreviewPortlet * ScheduleAssistant The jar is available form http://archive.msdn.microsoft.com/ewsjavaapi/Release/ProjectReleases.aspx?ReleaseId=5754 Would it be possible to get this into Jasig's Maven repo? It has the following dependencies: Apache Commons HttpClient 3.1 Apache Commons Codec 1.4 Apache Commons Logging 1.1.1 JCIFS 1.3.15 JCIFS is available from http://maven.jahia.org/maven2/ Others available in Maven central. Could these dependencies also be made available? Thanks, Anthony. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jennifer.bou...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Jen Bourey -- 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] Microsoft EWS API
Same applies for ewsjava. The soap web services api is truly awful, so if it is that much easier I'd be happy to depend on it too. On Nov 10, 2011 9:35 AM, Nicholas Blair nicholas.bl...@gmail.com wrote: The best thing to do is encourage the jcifs project to publish their artifacts with sonatype. Sonatype strongly discourages listing repositories in project poms, as a result calendarportlet may have difficulties being published with dependency on jasig repo. I recently ran into the same problem with ical4j, the author was really accommodating and now that's published to central through sonatype. On Nov 10, 2011 9:22 AM, Jen Bourey jennifer.bou...@gmail.com wrote: Hey Anthony, The calendar portlet actually already has an Exchange adapter out of the box. It uses spring-ws to connect to the services, which seems not too require too much custom code. I know Nick is also currently doing some EWS integration into the Scheduler too. Maybe there's an opportunity to create some documentation and best practices around Exchange integration? How've you found the Java library your'e using to be so far? - Jen On Thu, Nov 10, 2011 at 9:21 AM, Jen Bourey jennifer.bou...@gmail.comwrote: Hey Anthony, The calendar portlet actually already has an Exchange adapter out of the box. It uses spring-ws to connect to the services, which seems not too require too much custom code. I know Nick is also currently doing some EWS integration into the Scheduler too. Maybe there's an opportunity to create some documentation and best practices around Exchange integration? How've you found the Java library your'e using to be so far? - Jen On Nov 9, 2011, at 7:31 PM, Anthony Colebourne wrote: cc: licens...@jasig.org Hi, I want to contribute some Exchange 2010 adapters (development in progress). * CalendarPortlet * NotificationsPortlet Also in future * ContactsPortlet * EmailPreviewPortlet * ScheduleAssistant The jar is available form http://archive.msdn.microsoft.com/ewsjavaapi/Release/ProjectReleases.aspx?ReleaseId=5754 Would it be possible to get this into Jasig's Maven repo? It has the following dependencies: Apache Commons HttpClient 3.1 Apache Commons Codec 1.4 Apache Commons Logging 1.1.1 JCIFS 1.3.15 JCIFS is available from http://maven.jahia.org/maven2/ Others available in Maven central. Could these dependencies also be made available? Thanks, Anthony. -- You are currently subscribed to uportal-dev@lists.ja-sig.org as: jennifer.bou...@gmail.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- Jen Bourey -- 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] Using Git with Eclipse?
Thank you - this workflow seems to work a lot better. I'm also using Eclipse Indigo (adding a mention for clarity in the thread). I think part of what I was running into previously with the Import of exisiting Maven Projects is that the uportal Parent project (uPortal/pom.xml) would result in a project named uPortal, which conflicts with the General project imported from git. I find that after importing the existing Maven projects, the uportal-war project will need a right click-Maven-Update Project Configuration and a forced Clean/Build in order for the classes generated by JAXB to show up and be included in the compile classpath. This is more along the lines of what I mean by svn revert: use 'git checkout' to revert individual files back to the repository version. http://gitready.com/beginner/2009/01/11/reverting-files.html On Sat, Oct 22, 2011 at 11:52 AM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: With git your working directory and your repository are the same thing (well the repository is the .git directory in the root folder of the project). Here is my workflow, I'll try and get some screenshots and/or videos up next week as well 1. Switch to the git repository list, clone the uPortal repository (or your fork of it) 2. Expand the entry for the local repository, right click on the Working directory and select Import projects... continue with importing as a general project, don't relocate the source. 3. Once you have the general project imported right click on it and go to Configure Convert to Maven project 4. Right click on the project and go to Import ... select Maven Existing Maven Projects and select the uPortal modules you'd like to materialize as projects (in general uportal-war and uportal-search-api are the only two that are needed) As for reverting changes, what do you need to revert? I believe git reset --hard will remove all local modifications to the currently checked out branch. There is also a Reset ... option under the Team menu, that brings up a dialog and at the bottom Hard is one of the options you can select. -Eric On 10/22/11 10:37 AM, Nicholas Blair wrote: Can anyone point in the direction of some useful Git-Eclipse integration instructions, particularly those helpful for the uPortal project structure? I've tried following EGit's User Guide, but what I've been able to come up with is awkward and pretty unusable: http://wiki.eclipse.org/EGit/User_Guide What I've done so far: - Forked uPortal to my account on github: https://github.com/nblair/uPortal - Created a local clone of the repository, git clone g...@github.com:nblair/uPortal.git - Created a branch to work on git checkout -b UP-3226 Now in Eclipse, I've got EGit installed. Under the Git Repositories perspective, I added my local clone. The most intuitive path I started with was navigate under Branches/Local/UP-3226. It seemed to me that I could right click on that branch and check it out as a project, but that option doesn't exist. If you right click on the Working directory, Import project shows up as an option. It doesn't appear that .project files are available in the source tree, so the only option that works is to import as a General project. I did just that, thinking I could use Import-Existing Maven Projects and they'd all show up as I had them previously. That doesn't work however. The only way I could get rolling was to import just one sub-project (e.g. uportal-war) at a time. That works, but the project doesn't show up as attached to a VCS, so right clicking on any entry under that project doesn't offer any Team actions. I have to go up to the original general project to see Team actions. Can anyone share their workspace setups? I'm thinking I'm just missing the obvious, since so far my experience using Git with Eclipse has been pretty poor. Bonus question: What is the equivalent for svn revert? There is nothing under the Team actions that resembles it. I'm not even sure how to do it from the command line. -- 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] Move uPortal source to GitHub Schedule
That did the trick - thanks! On Fri, Oct 14, 2011 at 10:10 AM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: From that branches list page click on add-nblair-branch which should take you to: https://github.com/nblair/svn2git-migration/tree/add-nblair-branch There should be a button on the upper right named Pull Request. There are two screenshots attached with more detail. -Eric On 10/14/11 9:40 AM, Nicholas Blair wrote: I'm a bit stuck at the point where I push my changes back. I've got my development environment setup completely, cloned the project, created a local branch, and committed my changes to the local branch. When I perform what I believe to be the push from my changed branch back to my master (the original clone), I execute the following: git push origin add-nblair-branch Everything up-to-date Here's my repo: https://github.com/nblair/svn2git-migration And you can see my change on the add-nblair-branch: https://github.com/nblair/svn2git-migration/branches So what steps do I follow from here? Thanks! On Thu, Oct 13, 2011 at 11:42 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: Yeah, it is a little weird but that is apparently how the git commit message stuff works. The name part is just decorative, the email address is what matters. -Eric On 10/13/11 11:28 PM, Carroll, Timothy Dale wrote: okay. so i think the confusing part was that i don't put my github ID anywhere. i just need to put one of the email addresses that is associated with my github ID in that file. like this: tim = tim carroll t...@logiclander.com where the name part tim carroll is actually completely meaningless and arbitrary. i was thinking that somewhere there would be a mapping of my jasig ID to my github ID directly. like this: tim = timit On Oct 13, 2011, at 11:59 PM, Eric Dalquist wrote: Sorry, my previous reply wasn't very clear. So for the author mapping feature of svn2git to work we have to have Name em@i.l em@i.l format mappings for every SVN committer that the tool encounters. Since the chances of getting everyone that has ever committed to uPortal (all 74 of them) to create a GitHub account is very small I decided to put together two lists. resolvedAuthors.txt - A best guess at GitHub account info made by looking up each SVN account in the Jasig Crowd directory and using the name and email address registered for the account. This doesn't even work for really old committers so those accounts get fake mappings that look like: aha...@committers.jasig.org aha...@committers.jasig.orgaha...@committers.jasig.org. The important thing to remember is that this file is automatically generated, there was no hand editing of its data. mappedAuthors.txt - Explicit SVN username to GitHub account mappings. Every existing Jasig committer that has a GitHub account should list the mapping between their accounts here. When I run svn2git I first use the little mergeAuthors.groovy script which merges the two files with the mappings in mappedAuthors.txt replacing mappings from resolvedAuthors.txt. So no, the email address don't need to match, the email address in resolvedAuthors.txt is a best guess for each svn account. The email address in mappedAuthors.txt is your actual GitHub account email address. -Eric On 10/13/11 10:34 PM, Carroll, Timothy Dale wrote: so... they should probably match then... right? email is the common denominator to map between the accounts. On Oct 13, 2011, at 11:00 PM, Eric Dalquist wrote: File 2 is the automated output of looking up the name and email address for each svn account name from Crowd. File 1 is overlayed on top of File 2 to come up with the mapping file used for doing the migration. -Eric On 10/13/11 7:49 PM, Carroll, Timothy Dale wrote: do the email addresses used in file [1] and [2] need to match? On Oct 13, 2011, at 5: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+Proposalhttps://wiki.jasig.org/display/UPC/Git+Migration+Proposal#GitMigrationProposal-UsernameMapping 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
Re: [uportal-dev] [VOTE] Move uPortal source to GitHub
I was originally a 0 on this issue; I think the primary committers by and large won't have too much difficulty switching to git, but I shared some of the earlier concerns about deployers depending on svn. Now that this read-only mirror is possible, my vote is +1 as long as that becomes a required step in the transition. I also think we should capture in video form a number of common workflows for deploying and contributing patches using git to help those that are interested make the switch. On Wed, Sep 14, 2011 at 8:49 AM, Eric Dalquist eric.dalqu...@doit.wisc.eduwrote: I've verified that we will be able to the keep the existing https://source.jasig.org/uPortal svn data as a read-only mirror of the git repository. Existing revision numbers will not change and commits on the git side to the trunk and patches branches will automatically be reflected back to the Jasig svn repository. Hopefully this will address the needs of folks that are using svn:externals and the svn remote-merge features. -Eric On 9/11/11 9:48 PM, Eric Dalquist wrote: I'll be interested to hear what you hear about the Jasig/Sakai stuff. The talks we've had on the steering committee assumes that there will be work to merge infrastructure but that project governance will remain with the project steering committees, for example CAS3, mod_auth_cas, and phpCAS-Client have all moved or are in the process of moving to GitHub. I'll look more into maintaining a read-only SVN clone of uPortal, potentially in its existing location (this is complicated by the complicated nature of the uPortal history). I'm guessing we could have a bamboo job that would run git-svn post git commit to keep things in sync. -Eric On 9/11/11 6:00 PM, Steve Swinsburg wrote: Hi Eric, A could of responses inline: On 12/09/2011, at 1:01 AM, Eric Dalquist wrote: Since the concerns need some actual discussion I'll see if I can answer them here, my answers are in bold 1. Developer Familiarity Conversion Lag - Primary concern with speed for applying critical fixes for a 4.0.1 release - *I have done a test release using the maven release plugin against github and the developer workflow does not change for cutting releases * - *There are ~ 6 very active committers on the project, I'll be sure to touch base with each of them and get their vote before we make any move * 2. svn:externals - Used by some deployers as an alternative to a vendor drop import - *I'd like to get more insight on this approach versus doing a vendor drop* - *One option is for Jasig to maintain a read-only SVN clone of the git repository if there is enough interest from those using svn:externals * A subversion clone of the git repo would be handy, at least initially. It would actually tie in with 3 below, assuming the history is kept intact. 1. Local deployments using Subversion (if Subversion is their institutional repository) - Process to merge fixes into local repository directly from the uPortal repository? - *Are there examples of a patch merging process that is specific to uPortal using Subversion?* Not specific to uPortal, but specific to Subversion. For example, we use the vendor drop method for major releases, however from time to time we want to pull in a patch that has been added to the branch. So we can simply grab that fix from the uPortal repository via an svn merge: svn merge --dry-run -c12345 https://source.jasig.org/uPortal/branches/rel-3-2-patches/ We could generate a patch, but it saves a bit of extra work. Having the subversion repo clone as in 2 above would allow this practice to continue. At some stage we may be able to move to a git repo, but not soon. 1. Sakai-Jasig merger - How will this relate to the merger and any broader SCM/Release management strategy? ( http://groups.google.com/group/jasig-sakai-collaboration) - *As far as I know projects under a merged Jasig/Sakai Collaboration will still be responsible for setting their own SCM and release management strategies just as it is now under Jasig* I'll be speaking with Ian Dolphin and Josh Baron this week, as they are in Australia for AuSakai 11. I'll try and get some clarity around this issue. From what I read in the Jasig-Sakai Common Foundation Value Proposition Document [1]: Opportunities exist for bringing new and consolidated resources to bear on issues such as Quality Assurance... - I'm presuming that will have some impact on release management. Further, Consolidating our Technology Infrastructure - We expect to see cost savings from moving towards a common suite of centrally hosted communication and coordination tools (e.g. issue tracking, wiki etc.). - It's unclear as whether or not that includes SCM. I'll try and find out this week. cheers, Steve
Re: [uportal-dev] Portlet 2.0 Cookie Support
I've been working from option 3. There are 2 key elements in the data model: IPortalCookie, which represents a single Cookie Eric is referring to (1 key to relate to all portlet cookies). IPortletCookie, which mimics javax.servlet.http.Cookie per the portlet spec, but also provides a reference to the IPortletEntity that spawned the cookie. There isn't any scoping - as far as I've gotten - so any portlet can see all Cookies (IPortletCookies) in the request. When a portlet calls: javax.servlet.http.Cookie[] PortletRequest#getCookies() Should the returned array contain all non-portlet cookies as well? The only mention in the spec is: 11.1.5.1 The portlet can access cookies provided by the current request with the getCookies method. The returned cookie array provides the portlet with all cookie properties. I read that as yes, all Cookies returned by the normal ServletRequest should be included. On Mon, Jan 17, 2011 at 9:28 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: Hrm, that is a good point. The spec does refer to them in the same areas where it refers to using portlet request/response properties as HTTP headers which also implies no scoping. 3 would also be the easiest to implement since then the cookies have no relation to the portlet definition or entity objects. The more I think about it the more option 3 really seems to make sense. Our general plan for implementation is that uPortal will always set a specially named portal cookie with a big-random-token value in the users browser and store that token in the DB. Any time a portlet sets/reads a cookie it will actually be stored in the DB and never actually sent to the browser. The big technical reason for this is since uPortal is what the spec calls a Streaming Portal by the time portlets have started rendering there has already been content written to the browser. We'll have a background task that does purging of the portal cookie and portlet cookies from the DB to make sure these cookie stores don't just grow forever. -Eric On 1/17/11 4:40 PM, Steve Swinsburg wrote: You're right, it is confusing. From what I have read, there is no guarantee the cookies from one portlet will be available to another one (which is either 1 or 2 below) but it seems an odd use of cookies and general knowledge around the use of cookies would probably assume 3. regards, Steve On 18/01/2011, at 3:30 AM, Eric Dalquist wrote: Nick Blair is working on the cookie support for portlet 2.0 and we've come to a bit of confusion. After re-reading the portlet spec on cookies several times now and one thing is still not clear, how are cookies set by portlets scoped? It seems like there are a few options: Cookies are scoped the same way Preferences are, to the instance of the portlet entity Cookies are scoped at the definition level, essentially Portlet A can share a cookie among any number of users but Portlet B will never see it Cookies are not scoped at all. All portlets work in the same general space for cookies and a cookie set by Portlet A can be seen by Portlet B Does anyone here have thoughts on the intent in the spec or just what your gut feeling would be? -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] Portlet 2.0 Cookie Support
Oops! That makes sense though. Dropping the reference to IPortletEntity within IPortletCookie would clear up some of the troubles I ran into recently. On Tue, Jan 18, 2011 at 9:01 AM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: That would actually be option 1. If we did option 3 the reference from the IPortletCookie to IPortletEntity would go away and all portlets would see all cookies for a particular browser. -Eric On 1/18/11 8:30 AM, Nicholas Blair wrote: I've been working from option 3. There are 2 key elements in the data model: IPortalCookie, which represents a single Cookie Eric is referring to (1 key to relate to all portlet cookies). IPortletCookie, which mimics javax.servlet.http.Cookie per the portlet spec, but also provides a reference to the IPortletEntity that spawned the cookie. There isn't any scoping - as far as I've gotten - so any portlet can see all Cookies (IPortletCookies) in the request. When a portlet calls: javax.servlet.http.Cookie[] PortletRequest#getCookies() Should the returned array contain all non-portlet cookies as well? The only mention in the spec is: 11.1.5.1 The portlet can access cookies provided by the current request with the getCookies method. The returned cookie array provides the portlet with all cookie properties. I read that as yes, all Cookies returned by the normal ServletRequest should be included. On Mon, Jan 17, 2011 at 9:28 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: Hrm, that is a good point. The spec does refer to them in the same areas where it refers to using portlet request/response properties as HTTP headers which also implies no scoping. 3 would also be the easiest to implement since then the cookies have no relation to the portlet definition or entity objects. The more I think about it the more option 3 really seems to make sense. Our general plan for implementation is that uPortal will always set a specially named portal cookie with a big-random-token value in the users browser and store that token in the DB. Any time a portlet sets/reads a cookie it will actually be stored in the DB and never actually sent to the browser. The big technical reason for this is since uPortal is what the spec calls a Streaming Portal by the time portlets have started rendering there has already been content written to the browser. We'll have a background task that does purging of the portal cookie and portlet cookies from the DB to make sure these cookie stores don't just grow forever. -Eric On 1/17/11 4:40 PM, Steve Swinsburg wrote: You're right, it is confusing. From what I have read, there is no guarantee the cookies from one portlet will be available to another one (which is either 1 or 2 below) but it seems an odd use of cookies and general knowledge around the use of cookies would probably assume 3. regards, Steve On 18/01/2011, at 3:30 AM, Eric Dalquist wrote: Nick Blair is working on the cookie support for portlet 2.0 and we've come to a bit of confusion. After re-reading the portlet spec on cookies several times now and one thing is still not clear, how are cookies set by portlets scoped? It seems like there are a few options: Cookies are scoped the same way Preferences are, to the instance of the portlet entity Cookies are scoped at the definition level, essentially Portlet A can share a cookie among any number of users but Portlet B will never see it Cookies are not scoped at all. All portlets work in the same general space for cookies and a cookie set by Portlet A can be seen by Portlet B Does anyone here have thoughts on the intent in the spec or just what your gut feeling would be? -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] Pluto 2 development
Should we just add pluto-portal-driver-impl as well? For example, the RequiredContainerServices interface requires an EventCoordinationService implementation. There is one in pluto-portal-driver-impl although whether or not it meets our needs is unknown (it's not just a no-op implementation in that package). During development should we just use that package until we run a portlet for the first time? On Thu, Mar 11, 2010 at 11:11 AM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: So I got a response from the Pluto folks. For now we will need to plan on having pluto-portal-driver as a compile dependency of the uportal-impl module. There is code in there that is specific to the Pluto testing portal but we'll just ignore it for now. When we get closer to a 3.3 release I'll probably see what exactly we've used from pluto-portal-driver and work with the other Pluto developers on some refactoring to remove the Pluto test portal specific code from that module. You can read the pluto-dev thread here: http://old.nabble.com/PortletInvokerServiceImpl-in-pluto-portal-driver--ts27857072.html -Eric On 03/10/2010 06:13 PM, Nicholas Blair wrote: I've left Spring 3 in place, and just committed some fixes to address compilation problems in non-portlet packages introduced by the switch to Spring 3. One class that will need attention from others is org.jasig.portal.spring.web.context.support.PortalSessionScope - there is a new method defined in the Scope interface I'm not sure how to implement. I'd like to propose we keep pluto-portal-driver in the pom as a provided dependency for the time being. There are a number of uportal classes - that potentially won't be used in the future - that don't compile without the portal-driver library being on the classpath. Since these classes aren't used and aren't loaded, my thinking is that their presence doesn't hurt. It's the last barrier to getting the full impl source tree compiling. On Wed, Mar 10, 2010 at 4:54 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: As weird as it seems to be working on two changes at the same time I don't want to refactor using spring 2.5 and then have to refactor some of that again right away for spring 3.0. Though if you think it adds too much that's fine too. So the pluto dependencies should all be in order. The one big question I have for the pluto email list is what to do about the pluto-portal-driver JAR. As far as I can tell the intent is for portals that embed pluto to not reference it but it includes default implementations of a lot of the core pluto services that we can easily re-use. I'll be emailing the Pluto list about that today. Where I left off today was in the middle of creating org.jasig.portal.portlet.container.services. PortletContainerServices. This is the class that gets passed into the new PortletContainerImpl that provides all the callbacks into the portal for Pluto. Some of the service getters have already been implemented, these are the ones where I know uPortal already has a compatible service implementation. The getters with TODOs we still need to figure out. Unfortunately a lot of that figuring is going to depend on if we decided to include the pluto-portal-driver JAR though even then we will still need our own implementations of at least CCPPProfileService and EventCoordinationService, perhaps others as well. So until we hear back from the pluto folks the next steps are to look at those two services and to work on the Spring 3.0 updates in general. Off to email pluto-dev -Eric On 3/10/10 4:16 PM, Nicholas Blair wrote: Awesome! I noticed Spring 3 as the choice in the POM - I had been working locally against 2.5do we want to get Pluto 2 in first by itself? Or do both at the same time? On Wed, Mar 10, 2010 at 2:57 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: I just did some cleanup of the pluto 2 dependencies. I don't think we want to import anything from the pluto driver impl, that is the little stub-portal the pluto uses for testing. My commit does break compilation for now but I'm working on getting the service APIs fixed up. -Eric On 03/05/2010 02:54 PM, Nicholas Blair wrote: If anyone is interested in helping out integrating Pluto 2 (http://www.ja-sig.org/issues/browse/UP-2488) I've created a branch specific to this task: uPortal/branches/working-pluto-2.0 It is currently not functional. The poms have been updated and a number of classes have been ported (where obvious replacements exist or all that was needed was updated imports). It compiles, and the tests pass, but it will not run when deployed in tomcat. The ear deployer will need to be updated to copy all of the different artifacts from pluto 2 into Tomcat's shared/lib. There are a handful of classes where no direct replacement from pluto 1.1 exists; I've tried to mark these with TODO comments. -- You are currently subscribed
Re: [uportal-dev] Pluto 2 development
Awesome! I noticed Spring 3 as the choice in the POM - I had been working locally against 2.5do we want to get Pluto 2 in first by itself? Or do both at the same time? On Wed, Mar 10, 2010 at 2:57 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: I just did some cleanup of the pluto 2 dependencies. I don't think we want to import anything from the pluto driver impl, that is the little stub-portal the pluto uses for testing. My commit does break compilation for now but I'm working on getting the service APIs fixed up. -Eric On 03/05/2010 02:54 PM, Nicholas Blair wrote: If anyone is interested in helping out integrating Pluto 2 (http://www.ja-sig.org/issues/browse/UP-2488) I've created a branch specific to this task: uPortal/branches/working-pluto-2.0 It is currently not functional. The poms have been updated and a number of classes have been ported (where obvious replacements exist or all that was needed was updated imports). It compiles, and the tests pass, but it will not run when deployed in tomcat. The ear deployer will need to be updated to copy all of the different artifacts from pluto 2 into Tomcat's shared/lib. There are a handful of classes where no direct replacement from pluto 1.1 exists; I've tried to mark these with TODO comments. -- 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] Pluto 2 development
I've left Spring 3 in place, and just committed some fixes to address compilation problems in non-portlet packages introduced by the switch to Spring 3. One class that will need attention from others is org.jasig.portal.spring.web.context.support.PortalSessionScope - there is a new method defined in the Scope interface I'm not sure how to implement. I'd like to propose we keep pluto-portal-driver in the pom as a provided dependency for the time being. There are a number of uportal classes - that potentially won't be used in the future - that don't compile without the portal-driver library being on the classpath. Since these classes aren't used and aren't loaded, my thinking is that their presence doesn't hurt. It's the last barrier to getting the full impl source tree compiling. On Wed, Mar 10, 2010 at 4:54 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: As weird as it seems to be working on two changes at the same time I don't want to refactor using spring 2.5 and then have to refactor some of that again right away for spring 3.0. Though if you think it adds too much that's fine too. So the pluto dependencies should all be in order. The one big question I have for the pluto email list is what to do about the pluto-portal-driver JAR. As far as I can tell the intent is for portals that embed pluto to not reference it but it includes default implementations of a lot of the core pluto services that we can easily re-use. I'll be emailing the Pluto list about that today. Where I left off today was in the middle of creating org.jasig.portal.portlet.container.services. PortletContainerServices. This is the class that gets passed into the new PortletContainerImpl that provides all the callbacks into the portal for Pluto. Some of the service getters have already been implemented, these are the ones where I know uPortal already has a compatible service implementation. The getters with TODOs we still need to figure out. Unfortunately a lot of that figuring is going to depend on if we decided to include the pluto-portal-driver JAR though even then we will still need our own implementations of at least CCPPProfileService and EventCoordinationService, perhaps others as well. So until we hear back from the pluto folks the next steps are to look at those two services and to work on the Spring 3.0 updates in general. Off to email pluto-dev -Eric On 3/10/10 4:16 PM, Nicholas Blair wrote: Awesome! I noticed Spring 3 as the choice in the POM - I had been working locally against 2.5do we want to get Pluto 2 in first by itself? Or do both at the same time? On Wed, Mar 10, 2010 at 2:57 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: I just did some cleanup of the pluto 2 dependencies. I don't think we want to import anything from the pluto driver impl, that is the little stub-portal the pluto uses for testing. My commit does break compilation for now but I'm working on getting the service APIs fixed up. -Eric On 03/05/2010 02:54 PM, Nicholas Blair wrote: If anyone is interested in helping out integrating Pluto 2 (http://www.ja-sig.org/issues/browse/UP-2488) I've created a branch specific to this task: uPortal/branches/working-pluto-2.0 It is currently not functional. The poms have been updated and a number of classes have been ported (where obvious replacements exist or all that was needed was updated imports). It compiles, and the tests pass, but it will not run when deployed in tomcat. The ear deployer will need to be updated to copy all of the different artifacts from pluto 2 into Tomcat's shared/lib. There are a handful of classes where no direct replacement from pluto 1.1 exists; I've tried to mark these with TODO comments. -- 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] Pluto 2 development
Note to lay another question up for vote before we've resolved my prior proposal: Are there any objection to starting the removal of IChannel on uPortal/branches/working-pluto-2.0 by removing Test classes related to channels? A number of tests in oj.p.channels are failing with Spring 3 in place (due to springmodules going away)and since IChannel is going away do we care if tests for IChannel related items fail? On Wed, Mar 10, 2010 at 6:13 PM, Nicholas Blair nicholas.bl...@gmail.com wrote: I've left Spring 3 in place, and just committed some fixes to address compilation problems in non-portlet packages introduced by the switch to Spring 3. One class that will need attention from others is org.jasig.portal.spring.web.context.support.PortalSessionScope - there is a new method defined in the Scope interface I'm not sure how to implement. I'd like to propose we keep pluto-portal-driver in the pom as a provided dependency for the time being. There are a number of uportal classes - that potentially won't be used in the future - that don't compile without the portal-driver library being on the classpath. Since these classes aren't used and aren't loaded, my thinking is that their presence doesn't hurt. It's the last barrier to getting the full impl source tree compiling. On Wed, Mar 10, 2010 at 4:54 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: As weird as it seems to be working on two changes at the same time I don't want to refactor using spring 2.5 and then have to refactor some of that again right away for spring 3.0. Though if you think it adds too much that's fine too. So the pluto dependencies should all be in order. The one big question I have for the pluto email list is what to do about the pluto-portal-driver JAR. As far as I can tell the intent is for portals that embed pluto to not reference it but it includes default implementations of a lot of the core pluto services that we can easily re-use. I'll be emailing the Pluto list about that today. Where I left off today was in the middle of creating org.jasig.portal.portlet.container.services. PortletContainerServices. This is the class that gets passed into the new PortletContainerImpl that provides all the callbacks into the portal for Pluto. Some of the service getters have already been implemented, these are the ones where I know uPortal already has a compatible service implementation. The getters with TODOs we still need to figure out. Unfortunately a lot of that figuring is going to depend on if we decided to include the pluto-portal-driver JAR though even then we will still need our own implementations of at least CCPPProfileService and EventCoordinationService, perhaps others as well. So until we hear back from the pluto folks the next steps are to look at those two services and to work on the Spring 3.0 updates in general. Off to email pluto-dev -Eric On 3/10/10 4:16 PM, Nicholas Blair wrote: Awesome! I noticed Spring 3 as the choice in the POM - I had been working locally against 2.5do we want to get Pluto 2 in first by itself? Or do both at the same time? On Wed, Mar 10, 2010 at 2:57 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: I just did some cleanup of the pluto 2 dependencies. I don't think we want to import anything from the pluto driver impl, that is the little stub-portal the pluto uses for testing. My commit does break compilation for now but I'm working on getting the service APIs fixed up. -Eric On 03/05/2010 02:54 PM, Nicholas Blair wrote: If anyone is interested in helping out integrating Pluto 2 (http://www.ja-sig.org/issues/browse/UP-2488) I've created a branch specific to this task: uPortal/branches/working-pluto-2.0 It is currently not functional. The poms have been updated and a number of classes have been ported (where obvious replacements exist or all that was needed was updated imports). It compiles, and the tests pass, but it will not run when deployed in tomcat. The ear deployer will need to be updated to copy all of the different artifacts from pluto 2 into Tomcat's shared/lib. There are a handful of classes where no direct replacement from pluto 1.1 exists; I've tried to mark these with TODO comments. -- 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] Pluto 2 development
If anyone is interested in helping out integrating Pluto 2 (http://www.ja-sig.org/issues/browse/UP-2488) I've created a branch specific to this task: uPortal/branches/working-pluto-2.0 It is currently not functional. The poms have been updated and a number of classes have been ported (where obvious replacements exist or all that was needed was updated imports). It compiles, and the tests pass, but it will not run when deployed in tomcat. The ear deployer will need to be updated to copy all of the different artifacts from pluto 2 into Tomcat's shared/lib. There are a handful of classes where no direct replacement from pluto 1.1 exists; I've tried to mark these with TODO comments. -- 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] pre-commit hook re: svn:mime-type preventing commit
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
Add and commit of the new file succeeds if I manually set: svn:mime-type text/plain I don't see any obvious typos with the *.java line in the uportal subversion config: *.java = svn:eol-style=native;svn:keywords=Date Revision Author HeadURL Id;svn:mime-type=text/plain So I'm stumped. On Sun, Feb 28, 2010 at 11:30 AM, Nicholas Blair nicholas.bl...@gmail.com 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
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] pre-commit hook re: svn:mime-type preventing commit
I'll give it a shot next time I have to add a new file. On Sun, Feb 28, 2010 at 12:09 PM, Cris J Holdorph holdo...@unicon.net wrote: 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: 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] latest trunk: stop tomcat, hsqldb shuts down?
I'll take a look: http://www.ja-sig.org/issues/browse/UP-2632 On Fri, Feb 12, 2010 at 11:28 AM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: This shouldn't be happening but I have no idea what would be causing it. Perhaps the close call on the DBCP DataSource? -Eric On 02/12/2010 09:44 AM, Drew Wills wrote: I am also experiencing this behavior. I'd be happier if we could leave HSQL running, as it's an extra step to restart it each time I want to try a small tweak to something. drew Nicholas Blair wrote: Not sure if this is expected behavior or not, so I figured I'd post here first. I've noticed that on the latest trunk, when I stop tomcat the local hsqldb is shutdown cleanly (started using the 'hsql' ant target from a terminal). Is this expected behavior? I recall previous snapshots of uPortal leaving hsqldb running after tomcat is shutdown. I suspect the shutdown is the result of some destruction method being invoked by Spring as the applicationContext shuts down; maybe it's hibernate or Commons DBCP. Any thoughts, or should I open this in JIRA? -- 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] latest trunk: stop tomcat, hsqldb shuts down?
Not sure if this is expected behavior or not, so I figured I'd post here first. I've noticed that on the latest trunk, when I stop tomcat the local hsqldb is shutdown cleanly (started using the 'hsql' ant target from a terminal). Is this expected behavior? I recall previous snapshots of uPortal leaving hsqldb running after tomcat is shutdown. I suspect the shutdown is the result of some destruction method being invoked by Spring as the applicationContext shuts down; maybe it's hibernate or Commons DBCP. Any thoughts, or should I open this in JIRA? -- 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] error deploying current trunk from initportal?
I've just synchronized my workspace (Java 6, Tomcat 6.0.20) with the latest trunk, and it seems I am unable to run from a fresh 'ant initportal'. BookmarksPortlet, cas-proxy-test-portlet, FunctionalTestsPortlet, pluto-test-suite, uPortal, WeatherPortlet, and widget-portlets all seem to start without error. The guest view of uportal renders fine. Clicking the login link gives me a 404 error (since the /cas application failed to deploy). I see the following in cas.log: ERROR [main] Jan/21 18:44:44,587 context.ContextLoader.[] - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'dataSource' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Could not resolve placeholder 'hibernate.connection.driver_class' at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties(PropertyPlaceholderConfigurer.java:268) at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:75) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:527) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:362) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized(SafeContextLoaderListener.java:62) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4429) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:987) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:909) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:495) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:583) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) And the following in WebProxyPortlet.log: ERROR [main] Jan/21 18:44:58,798 context.ContextLoader.[] - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'dataSource' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Circular placeholder reference 'hibernate.connection.driver_class' in property definitions at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties(PropertyPlaceholderConfigurer.java:268) at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:75) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:527) at
Re:[uportal-dev] error deploying current trunk from initportal?
I was running Maven 2.0.10 when I encountered this problem - a switch to 2.2.1 fixed it. I've described the problem in http://www.ja-sig.org/issues/browse/UP-2597 Any objections to requiring Maven 2.2? On Thu, Jan 21, 2010 at 6:53 PM, Nicholas Blair nicholas.bl...@gmail.com wrote: I've just synchronized my workspace (Java 6, Tomcat 6.0.20) with the latest trunk, and it seems I am unable to run from a fresh 'ant initportal'. BookmarksPortlet, cas-proxy-test-portlet, FunctionalTestsPortlet, pluto-test-suite, uPortal, WeatherPortlet, and widget-portlets all seem to start without error. The guest view of uportal renders fine. Clicking the login link gives me a 404 error (since the /cas application failed to deploy). I see the following in cas.log: ERROR [main] Jan/21 18:44:44,587 context.ContextLoader.[] - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'dataSource' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Could not resolve placeholder 'hibernate.connection.driver_class' at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties(PropertyPlaceholderConfigurer.java:268) at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:75) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:553) at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:527) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:362) at org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:255) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:199) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:45) at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized(SafeContextLoaderListener.java:62) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4429) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:987) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:909) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:495) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1206) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:314) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:583) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) And the following in WebProxyPortlet.log: ERROR [main] Jan/21 18:44:58,798 context.ContextLoader.[] - Context initialization failed org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'dataSource' defined in ServletContext resource [/WEB-INF/applicationContext.xml]: Circular placeholder reference 'hibernate.connection.driver_class' in property definitions at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties(PropertyPlaceholderConfigurer.java:268) at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory(PropertyResourceConfigurer.java:75
Re: [uportal-dev] trunk 3.1 patches build failures
It appears that the last commit on that class (o.j.p.channels.sqlquery.XmlRowMapper) refers to java.sql.Types that do not exist in Java 5. Specifically: ROWID, NCLOB, and SQLXML. Reference: http://java.sun.com/j2se/1.5.0/docs/api/java/sql/Types.html I've committed a change on trunk and rel-3.1-patches that allows the build to complete, I've just commented out references to those 3 types. On Sat, Nov 28, 2009 at 10:12 AM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: Bamboo is reporting build failures for trunk and 3.1-patches: http://developer.jasig.org/bamboo/browse/UP-TRUNK-188 http://developer.jasig.org/bamboo/browse/UP-31PATCHES-83 Looks like both failures were caused by: Adam Rybicki UP-2455: Get all supported column types as String by letting the JDBC do the conversion. -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] UP-2505 resolved, looking for new task
All, I believe UP-2505 is just about wrapped up, barring any unexpected problems or enhancement requests. Is there a review process, or should I mark the item resolved? I'm also looking for a new task to help out on - does anyone have a task that they would like my participation on? Thanks! Nick -- 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-user] build error with uPortal trunk
And it's fixed, thanks to: http://commons.apache.org/io/api-release/org/apache/commons/io/FilenameUtils.html#separatorsToUnix(java.lang.String) On Wed, Nov 25, 2009 at 3:55 PM, Nicholas Blair nicholas.bl...@gmail.com wrote: Ah, it appears Windows path separator (\) is an issue - I'll see what I can do. Thanks for the heads up! On Wed, Nov 25, 2009 at 2:05 PM, Eric Dalquist eric.dalqu...@doit.wisc.edu wrote: Nick Blair, can you take a look at this? -Eric Tuyhang Ly wrote: Hi, I'm trying to build uPortal from trunk on window environment and getting the following failed test: [artifact:mvn] Failed tests: [artifact:mvn] testResourcesOutput(org.jasig.portal.web.skin.ResourcesXalanElementsTest) [artifact:mvn] Tests run: 314, Failures: 1, Errors: 0, Skipped: 0 Here is the test trace: junit.framework.AssertionFailedError: Transformation result differs from what's expectedorg.custommonkey.xmlunit.Diff [different] Expected attribute value 'media/skins/test/common/css/a.css' but was 'media\skins\test\common\css\a.css' - comparing link href=media/skins/test/common/css/a.css... at /head[1]/link[1]/@href to link href=media\skins\test\common\css\a.css... at /head[1]/link[1]/@href at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.jasig.portal.web.skin.ResourcesXalanElementsTest.testResourcesOutput(ResourcesXalanElementsTest.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Any ideas? Thanks, Tuy. -- You are currently subscribed to uportal-u...@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-user -- 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] maven plugin tests again
Good catch - fix is checked into trunk. On Thu, Nov 19, 2009 at 10:40 PM, Susan Bramhall susan.bramh...@yale.edu wrote: I am attempting to add additional info messages to the deploy ear mojo to track down problems we are having with maven plugin and discovered that the tests in M2 and trunk fail for me. The issue is that the hard coded filenames in ResourcesAggregatorImplTest do not match the names generated when I run the test. It looks they are using some sort of guid which is not always the same on every machine. I changed the Assert statements in question to use the file names in the lists returned from ResourceAggregatorImpl. Not sure if this tests what you intend but it passes. Patch is below. Susan ==patch= Index: src/test/java/org/jasig/portal/web/skin/ResourcesAggregatorImplTest.java === --- src/test/java/org/jasig/portal/web/skin/ResourcesAggregatorImplTest.java (revision 47213) +++ src/test/java/org/jasig/portal/web/skin/ResourcesAggregatorImplTest.java (working copy) @@ -154,13 +154,13 @@ Assert.assertEquals(6, cssList.size()); ListJs jsList = result.getJs(); Assert.assertEquals(1, jsList.size()); - Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/common/css/fluid/uportal3_aggr1_A3661D3474000B0B06BC01EA644DBE07.css).exists()); - Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/common/css/uportal3_aggr2_0A62110C5DBE25EECD978B41EE455466.css).exists()); - Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/common/css/uportal3_aggr2_0A62110C5DBE25EECD978B41EE455466.css).exists()); - Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/uportal3/uportal3_aggr3_3334333FF8A41D7D6BCE5C8AE5B71B4A.css).exists()); - Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/uportal3/uportal3_aggr5_0EC69539BB6BA6C8B611BAC539C67794.css).exists()); - Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/uportal3/uportal3_aggr6_F21DFDA90E2DFAEB81BC098A037A458C.css).exists()); - Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/common/javascript/uportal/uportal3_aggr7_158C92140AC7355300F2708F20D66DB2.js).exists()); + + Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/common/ + cssList.get(0).getValue()).exists()); + Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/common/ + cssList.get(1).getValue()).exists()); + Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/uportal3/ + cssList.get(2).getValue()).exists()); + Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/uportal3/ + cssList.get(4).getValue()).exists()); + Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/uportal3/ + cssList.get(5).getValue()).exists()); + Assert.assertTrue(new File(getTestOutputRoot() + /skin-universality/common/ + jsList.get(0).getValue()).exists()); } /** -- Susan Bramhall (susan.bramh...@yale.edu) Senior Developer, Infrastructure Systems and Architecture (formerly TP) Yale University Information Technology Services (ITS) 25 Science Park, 150 Munson St, New Haven, CT 06520 Phone: 203 432 6697 -- 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
[uportal-dev] resources aggregation now in trunk
I've just committed the resources aggregation process described in UP-2505 on to trunk. There is one caveat: it's currently not enabled. layout/theme/universality/page.xsl contains a comment that shows what needs to be done to switch. I've commented it out because it works for everything but the guest layout. It's odd too, sometimes the guest layout renders all the appropriate link and script tags perfectly as described in the skin, other times it only renders the first CSS link. In the case this problem occurs, ResourcesXalanElements (the class that the XSL uses to render the link/script tags from the skin configuration) doesn't even run (I've set a breakpoint on the first line in the class, and it doesn't get tripped). Chatting briefly with Eric he suggested it may be a guest layout caching issue; let me know if you have any thoughts or see anything that may be wrong. Thanks! Nick -- 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] more struggles with YUI Compressor
I've run into some trouble using YUI Compressor to process the javascript within the universality theme. Even the new version of YUI Compressor that we installed in the 3rd party repository (version 2.4.2) throws a StringIndexOutOfBoundsException in the constructor for the JavaScriptCompressor. I stumbled across the author's blog (http://www.julienlecomte.net/blog/2008/10/80/), in which he hints that he needed to modify Mozilla's Rhino javascript engine in order for it to work. Turns out that YUICompressor version 2.4 and later all include (!) the author's modified version of Rhino (see for yourself, org.mozilla.javascript packages bundled inside). I modified the pom.xml in maven-uportal-plugin to exclude rhino/js as a dependency for both yuicompressor and cernunnos, and sure enough the JavaScript compressor works without fail, including on the javascript in the universality theme. My question to the group is: is it ok to exclude the trusted rhino/js and depend on this author's undocumented changes? It's really the only way we can get YUI Compressor to work in this plugin. Will this present any other problems (e.g. licensing)? -- 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] maven plugin won't build with ResourcesAggregatorImplTest
This was related to my prior discussion about YUI Compressor and UP-2505. In short, the only YUI Compressor available via maven is version 2.3.6 - which is broken. I have installed 2.4.2 locally, and modified the pom to use it, and verified it works. Per my last comment on http://www.ja-sig.org/issues/browse/UP-2505 - this task is complete-able if we can get YUI Compressor 2.4.2 in a maven repository. If we can do that, I can make the last commits to get the resource aggregator mojo in the maven-uportal-plugin ready for use. On Mon, Nov 16, 2009 at 1:18 PM, Susan Bramhall susan.bramh...@yale.edu wrote: I've updated the maven plugin to throw the proper failure exception when appropriate so it does not end with BUILD SUCCESSFUL after a failure. Integrating this change in, I picked up some recent changes committed by Nick Blair. These seem to be setting up for new skin function in up 3.2. I'm assuming this is all no problem for people using the plugin for uP 3.1. However, the plugin will no longer build for me. I get test failures on the build (see stack trace below). I'd be grateful to know if this builds for other people. Nick? I think it might be a good idea to tag this so we can have a stable version for our use in production while preparation for future uPortal function is added. Thanks, Susan surefire report: === --- Test set: org.jasig.portal.web.skin.ResourcesAggregatorImplTest --- Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.313 sec FAILURE! testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.25 sec ERROR! java.lang.RuntimeException at com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:335) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.init(JavaScriptCompressor.java:532) at org.jasig.portal.web.skin.ResourcesAggregatorImpl.aggregateJsList(ResourcesAggregatorImpl.java:418) at org.jasig.portal.web.skin.ResourcesAggregatorImpl.aggregate(ResourcesAggregatorImpl.java:226) at org.jasig.portal.web.skin.ResourcesAggregatorImplTest.testControl(ResourcesAggregatorImplTest.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.266 sec ERROR! java.io.IOException: Unable to delete file: d:\susan\temp\1\resources-aggregator-impl-test-output\skin-test1\uportal3_aggr2_temp.js at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1390) at
Re: [uportal-dev] maven plugin won't build with ResourcesAggregatorImplTest
Excellent - I'll get the projects updated. Thanks! On Mon, Nov 16, 2009 at 1:50 PM, Jen Bourey jbou...@unicon.net wrote: Hi Nick, I've added the yuicompressor 2.4.2 jar to the Jasig third party repository (http://developer.jasig.org/repo/content/repositories/3rd-party/). - Jen On Mon, Nov 16, 2009 at 2:38 PM, Nicholas Blair nicholas.bl...@gmail.com wrote: This was related to my prior discussion about YUI Compressor and UP-2505. In short, the only YUI Compressor available via maven is version 2.3.6 - which is broken. I have installed 2.4.2 locally, and modified the pom to use it, and verified it works. Per my last comment on http://www.ja-sig.org/issues/browse/UP-2505 - this task is complete-able if we can get YUI Compressor 2.4.2 in a maven repository. If we can do that, I can make the last commits to get the resource aggregator mojo in the maven-uportal-plugin ready for use. On Mon, Nov 16, 2009 at 1:18 PM, Susan Bramhall susan.bramh...@yale.edu wrote: I've updated the maven plugin to throw the proper failure exception when appropriate so it does not end with BUILD SUCCESSFUL after a failure. Integrating this change in, I picked up some recent changes committed by Nick Blair. These seem to be setting up for new skin function in up 3.2. I'm assuming this is all no problem for people using the plugin for uP 3.1. However, the plugin will no longer build for me. I get test failures on the build (see stack trace below). I'd be grateful to know if this builds for other people. Nick? I think it might be a good idea to tag this so we can have a stable version for our use in production while preparation for future uPortal function is added. Thanks, Susan surefire report: === --- Test set: org.jasig.portal.web.skin.ResourcesAggregatorImplTest --- Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.313 sec FAILURE! testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.25 sec ERROR! java.lang.RuntimeException at com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:335) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.init(JavaScriptCompressor.java:532) at org.jasig.portal.web.skin.ResourcesAggregatorImpl.aggregateJsList(ResourcesAggregatorImpl.java:418) at org.jasig.portal.web.skin.ResourcesAggregatorImpl.aggregate(ResourcesAggregatorImpl.java:226) at org.jasig.portal.web.skin.ResourcesAggregatorImplTest.testControl(ResourcesAggregatorImplTest.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597
Re: [uportal-dev] maven plugin won't build with ResourcesAggregatorImplTest
(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Nicholas Blair wrote: There is a method annotated with @After (runs after each test) to clean up temporary files created by the test. The tests use the System property java.io.tmpdir to use as a root for these temporary files. I don't really know much about why that wouldn't work on windowsdo you have permission to delete files under d:\susan\temp? Is your d: drive a local or a remote filesystem? On Mon, Nov 16, 2009 at 3:27 PM, Susan Bramhall susan.bramh...@yale.edu wrote: Thanks to you both I am now down to just the errors caused by unable to delete temp files: java.io.IOException: Unable to delete file: d:\susan\temp\1\resources-aggregator-impl-test-output\skin-test1\uportal3_aggr2_temp.js One for each test in ResourcesAggregatorImplTest. Not sure why I get that and you don't. I am running under windows which does not like to delete open files. Maybe this is not getting closed? Susan Nicholas Blair wrote: I've just checked in the changes necessary to fix the tests - you should not have any problem building maven-uportal-plugin if you update to the trunk. On Mon, Nov 16, 2009 at 2:07 PM, Nicholas Blair nicholas.bl...@gmail.com wrote: Excellent - I'll get the projects updated. Thanks! On Mon, Nov 16, 2009 at 1:50 PM, Jen Bourey jbou...@unicon.net wrote: Hi Nick, I've added the yuicompressor 2.4.2 jar to the Jasig third party repository (http://developer.jasig.org/repo/content/repositories/3rd-party/). - Jen On Mon, Nov 16, 2009 at 2:38 PM, Nicholas Blair nicholas.bl...@gmail.com wrote: This was related to my prior discussion about YUI Compressor and UP-2505. In short, the only YUI Compressor available via maven is version 2.3.6 - which is broken. I have installed 2.4.2 locally, and modified the pom to use it, and verified it works. Per my last comment on http://www.ja-sig.org/issues/browse/UP-2505 - this task is complete-able if we can get YUI Compressor 2.4.2 in a maven repository. If we can do that, I can make the last commits to get the resource aggregator mojo in the maven-uportal-plugin ready for use. On Mon, Nov 16, 2009 at 1:18 PM, Susan Bramhall susan.bramh...@yale.edu wrote: I've updated the maven plugin to throw the proper failure exception when appropriate so it does not end with BUILD SUCCESSFUL after a failure. Integrating this change in, I picked up some recent changes committed by Nick Blair. These seem to be setting up for new skin function in up 3.2. I'm assuming this is all no problem for people using the plugin for uP 3.1. However, the plugin will no longer build for me. I get test failures on the build (see stack trace below). I'd be grateful to know if this builds for other people. Nick? I think it might be a good idea to tag this so we can have a stable version for our use in production while preparation for future uPortal function is added. Thanks, Susan surefire report: === --- Test set: org.jasig.portal.web.skin.ResourcesAggregatorImplTest --- Tests run: 5, Failures: 0, Errors: 5, Skipped: 0, Time elapsed: 0.313 sec FAILURE! testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.25 sec ERROR! java.lang.RuntimeException at com.yahoo.platform.yui.compressor.JavaScriptCompressor.printSourceNumber(JavaScriptCompressor.java:299) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.parse(JavaScriptCompressor.java:335) at com.yahoo.platform.yui.compressor.JavaScriptCompressor.init(JavaScriptCompressor.java:532) at org.jasig.portal.web.skin.ResourcesAggregatorImpl.aggregateJsList(ResourcesAggregatorImpl.java:418) at org.jasig.portal.web.skin.ResourcesAggregatorImpl.aggregate(ResourcesAggregatorImpl.java:226) at org.jasig.portal.web.skin.ResourcesAggregatorImplTest.testControl(ResourcesAggregatorImplTest.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25
Re: [uportal-dev] maven plugin won't build with ResourcesAggregatorImplTest
Yes, unfortunately YUICompressor's methods for compressing javascript and css depend on FileReader and FileWriter, which are concrete. If we want to have unit tests for resource aggregation, the only way to pull it off is by creating and deleting these temporary files. I'll take a look at how setup and teardown for this test can be improved. On Mon, Nov 16, 2009 at 3:48 PM, Susan Bramhall susan.bramh...@yale.edu wrote: YAY. Build successful now on Unix. Windows still complaining. I can research that a bit more. Whadda pain. Susan Nicholas Blair wrote: Just committed a fix for how the tests construct the path to their temporary directory, update and try again. On Mon, Nov 16, 2009 at 3:43 PM, Susan Bramhall susan.bramh...@yale.edu wrote: Fails on unix too but in different place.. --- Test set: org.jasig.portal.web.skin.ResourcesAggregatorImplTest --- Tests run: 6, Failures: 3, Errors: 3, Skipped: 0, Time elapsed: 0.019 sec FAILURE! testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.003 sec FAILURE! java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.assertTrue(Assert.java:37) at org.junit.Assert.assertTrue(Assert.java:46) at org.jasig.portal.web.skin.ResourcesAggregatorImplTest.testControl(ResourcesAggregatorImplTest.java:28) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.008 sec ERROR! java.io.FileNotFoundException: File does not exist: /tmpresources-aggregator-impl-test-output at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1386) at org.jasig.portal.web.skin.ResourcesAggregatorImplTest.cleanupTempDir(ResourcesAggregatorImplTest.java:142) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.MethodRoadie.runAfters(MethodRoadie.java:138) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:92) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51
Re: [uportal-dev] maven plugin won't build with ResourcesAggregatorImplTest
I've just checked in a change to the cleanup method in that test class. Can you try the build on Windows again to see if the changes have helped? Thanks! Nick On Mon, Nov 16, 2009 at 4:02 PM, Nicholas Blair nicholas.bl...@gmail.com wrote: Yes, unfortunately YUICompressor's methods for compressing javascript and css depend on FileReader and FileWriter, which are concrete. If we want to have unit tests for resource aggregation, the only way to pull it off is by creating and deleting these temporary files. I'll take a look at how setup and teardown for this test can be improved. On Mon, Nov 16, 2009 at 3:48 PM, Susan Bramhall susan.bramh...@yale.edu wrote: YAY. Build successful now on Unix. Windows still complaining. I can research that a bit more. Whadda pain. Susan Nicholas Blair wrote: Just committed a fix for how the tests construct the path to their temporary directory, update and try again. On Mon, Nov 16, 2009 at 3:43 PM, Susan Bramhall susan.bramh...@yale.edu wrote: Fails on unix too but in different place.. --- Test set: org.jasig.portal.web.skin.ResourcesAggregatorImplTest --- Tests run: 6, Failures: 3, Errors: 3, Skipped: 0, Time elapsed: 0.019 sec FAILURE! testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.003 sec FAILURE! java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:74) at org.junit.Assert.assertTrue(Assert.java:37) at org.junit.Assert.assertTrue(Assert.java:46) at org.jasig.portal.web.skin.ResourcesAggregatorImplTest.testControl(ResourcesAggregatorImplTest.java:28) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) testControl(org.jasig.portal.web.skin.ResourcesAggregatorImplTest) Time elapsed: 0.008 sec ERROR! java.io.FileNotFoundException: File does not exist: /tmpresources-aggregator-impl-test-output at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:1386) at org.jasig.portal.web.skin.ResourcesAggregatorImplTest.cleanupTempDir(ResourcesAggregatorImplTest.java:142) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.MethodRoadie.runAfters(MethodRoadie.java:138) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:92) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run
