[uportal-dev] factoring uPortal into Java chunks
MM break up the code by packages that seem related by functionality and put them into their own separate modules. Yes. I think making strides in this direction of *factoring the uPortal codebase into cohesive chunks* is absolutely essential to the feasibility of *writing plugins for uPortal*, and I see the feasibility of writing plugins for adoption with uPortal that do not necessarily ship as source code in github/Jasig/uPortal as very desirable for *growing the ways in which uPortal is a platform*. It must become possible, neigh joyous, to write a new layout manager, or group store plugin, or profile mapper, and compile that against (semantically versioned) APIs, which will make that kind of exploration more feasible and common, and thus grow more flowers for potential inclusion in uPortal products, running with the let all the flowers bloom idiom. We need ourselves some more fertile soil and better gardening implements. CH problem I see a LOT when a project is broken down into too small chunks *Let's not chunk too small. * :) Right sized chunks. *The right chunk size is not the whole entire thing*, which is currently the chunk size of uportal-war , what with it containing both APIs and implementations and all the Web stuff for that matter too. I'd be excited to try out, say, six-ish chunks and see if that feels like an improvement. Certainly not jumping directly to sixty chunks. CH Say you modify the groups api project. But you don't bother to rebuild the permissions project. And then something is broken. I totally agree that mistakes will be made and defects will happen --- but I am greatly hopeful that being clear about what the APIs are, semantically versioning those APIs, depending only upon those APIs and not on implementation details not specified by the APIs, and comprehensive unit tests doing what we can to validate adherence to those APIs, will make the incidence of those kinds of changing-chunk1-broke-chunk2 errors acceptable. So let's say I'm trying to sell up-dev@ on trying breaking uportal-war up into a few smaller chunks for some future release. Shall we start thinking about what chunks would make sense? I think it would be nifty to be sure to have at least one of the chunks feel very much like a deliberate API, so that we can then prove out the actual feasibility of writing external plugins to it. People seem to need custom group stores a fair amount. Perhaps the uportal-groups-api .jar that the External Database Group Store implementation could have compiled against were it factored as an external project depend-on-able as a .jar via Maven? ( https://github.com/Jasig/uPortal/pull/401 ) ? Kind regards, Andrew On Tue, Oct 28, 2014 at 12:37 PM, Misagh Moayyed mmoay...@unicon.net wrote: One possible approach would be to break up the code by packages that seem related by functionality and put them into their own separate modules. The Groups API, rendering API, views, etc. The way, one could just run tests for the module in question without having to wait for everything else to pass, etc. This should also help with swapping out another module implementation of say, groups with another by minimizing the noise down to just one module. The webapp module would of course declare these modules as dependencies so impact to overlays should be small to none I hope. -Original Message- From: bounce-37470681-57692...@lists.wisc.edu [mailto:bounce-37470681-57692...@lists.wisc.edu] On Behalf Of Andrew Petro Sent: Tuesday, October 28, 2014 10:21 AM To: uportal-dev@lists.ja-sig.org Subject: Re: [uportal-dev] master unit tests broken JW my uportal build script disables running the tests. A natural reaction to a build process that is way, way too expensive and punishing of running the unit tests. Part of where I want to get with Semantic Versioning is being able to separate what’s currently a monolith in uportal-war/src/java into components small enough that it’s not too painful to run the unit tests on the one component I'm touching right at the moment, that are loosely coupled enough that I don’t have to whack all of the components all at once to get anything done, and that thus are in pieces small enough to build and test in the generous but not huge resource allocation that travis-ci affords. How do we get traction on doing that detangling, and calling the result uPortal 5? :) Kind regards, Andrew On Oct 28, 2014, at 12:14 PM, James Wennmacher jwennmac...@unicon.net wrote: Hi Andrew, Josh brought this to my attention late yesterday and I started looking into it. I hope to have a fix pushed shortly. I apologize, I forgot my uportal build script disables running the tests. James Wennmacher - Unicon 480.558.2420 On 10/28/2014 08:52 AM, Andrew Petro wrote: Devs, Looks to me like this changeset https://github.com/Jasig/uPortal/pull/438 causes this unit test to fail: http://goo.gl/KS6a6p
Re: [uportal-dev] factoring uPortal into Java chunks
It just so happens that we were just talking about this exact topic this morning. Vertein suggested the rule 30 approach, I agreed. I found a good summary of it in this blog posthttp://swreflections.blogspot.com/2012/12/rule-of-30-when-is-method-class-or.html for those who are not aware of it (taken from this bookhttp://www.amazon.com/Refactoring-Large-Software-Projects-Restructurings/dp/0470858923) Might be a good guideline if/when we do this project refactoring. :) Cheers, Tim Levett tim.levettATwisc.edu From: bounce-37478517-70367...@lists.wisc.edu bounce-37478517-70367...@lists.wisc.edu on behalf of Andrew Petro apetro.li...@gmail.com Sent: Wednesday, October 29, 2014 10:23 AM To: uportal-dev@lists.ja-sig.org Subject: [uportal-dev] factoring uPortal into Java chunks MM break up the code by packages that seem related by functionality and put them into their own separate modules. Yes. I think making strides in this direction of factoring the uPortal codebase into cohesive chunks is absolutely essential to the feasibility of writing plugins for uPortal, and I see the feasibility of writing plugins for adoption with uPortal that do not necessarily ship as source code in github/Jasig/uPortal as very desirable for growing the ways in which uPortal is a platform. It must become possible, neigh joyous, to write a new layout manager, or group store plugin, or profile mapper, and compile that against (semantically versioned) APIs, which will make that kind of exploration more feasible and common, and thus grow more flowers for potential inclusion in uPortal products, running with the let all the flowers bloom idiom. We need ourselves some more fertile soil and better gardening implements. CH problem I see a LOT when a project is broken down into too small chunks Let's not chunk too small. :) Right sized chunks. The right chunk size is not the whole entire thing, which is currently the chunk size of uportal-war , what with it containing both APIs and implementations and all the Web stuff for that matter too. I'd be excited to try out, say, six-ish chunks and see if that feels like an improvement. Certainly not jumping directly to sixty chunks. CH Say you modify the groups api project. But you don't bother to rebuild the permissions project. And then something is broken. I totally agree that mistakes will be made and defects will happen --- but I am greatly hopeful that being clear about what the APIs are, semantically versioning those APIs, depending only upon those APIs and not on implementation details not specified by the APIs, and comprehensive unit tests doing what we can to validate adherence to those APIs, will make the incidence of those kinds of changing-chunk1-broke-chunk2 errors acceptable. So let's say I'm trying to sell up-dev@ on trying breaking uportal-war up into a few smaller chunks for some future release. Shall we start thinking about what chunks would make sense? I think it would be nifty to be sure to have at least one of the chunks feel very much like a deliberate API, so that we can then prove out the actual feasibility of writing external plugins to it. People seem to need custom group stores a fair amount. Perhaps the uportal-groups-api .jar that the External Database Group Store implementation could have compiled against were it factored as an external project depend-on-able as a .jar via Maven? ( https://github.com/Jasig/uPortal/pull/401 ) ? Kind regards, Andrew On Tue, Oct 28, 2014 at 12:37 PM, Misagh Moayyed mmoay...@unicon.netmailto:mmoay...@unicon.net wrote: One possible approach would be to break up the code by packages that seem related by functionality and put them into their own separate modules. The Groups API, rendering API, views, etc. The way, one could just run tests for the module in question without having to wait for everything else to pass, etc. This should also help with swapping out another module implementation of say, groups with another by minimizing the noise down to just one module. The webapp module would of course declare these modules as dependencies so impact to overlays should be small to none I hope. -Original Message- From: bounce-37470681-57692...@lists.wisc.edumailto:bounce-37470681-57692...@lists.wisc.edu [mailto:bounce-37470681-57692...@lists.wisc.edumailto:bounce-37470681-57692...@lists.wisc.edu] On Behalf Of Andrew Petro Sent: Tuesday, October 28, 2014 10:21 AM To: uportal-dev@lists.ja-sig.orgmailto:uportal-dev@lists.ja-sig.org Subject: Re: [uportal-dev] master unit tests broken JW my uportal build script disables running the tests. A natural reaction to a build process that is way, way too expensive and punishing of running the unit tests. Part of where I want to get with Semantic Versioning is being able to separate what’s currently a monolith in uportal-war/src/java into components small enough that it’s not too painful
