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 to
Re: [uportal-dev] Pluto 2 development
No, I've looked through pluto-portal-driver-impl and we need our own impls of everything in there. The EventCoordinationService is going to be fairly complex and will likely be handled by the PortletExecutationManager that will replace ChannelManager since threading and timeouts are required. -Eric On 3/11/10 6:00 PM, Nicholas Blair wrote: 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.eduwrote: 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.eduwrote: 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.
