Blog post laying out some vision for some steps towards a better chunked uPortal.
http://apetro.ghost.io/citizens-for-a-better-uportal-tomorrow-tomorrow/ Short version: * Semantic Versioning * Modularize the codebase * Separate API from implementation * uPortal becomes its own GitHub organization * The separate .jars become separate GitHub repos * Adopt Google Style * Increase unit test coverage leading to: greater development velocity, code quality, and confidence. Andrew On Wed, Oct 29, 2014 at 10:32 AM, Tim Levett <[email protected]> wrote: > 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 post > <http://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 book > <http://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:* [email protected] < > [email protected]> on behalf of Andrew Petro < > [email protected]> > *Sent:* Wednesday, October 29, 2014 10:23 AM > *To:* [email protected] > *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 <[email protected]> > 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: [email protected] >> [mailto:[email protected]] On Behalf Of Andrew >> Petro >> Sent: Tuesday, October 28, 2014 10:21 AM >> To: [email protected] >> 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 <[email protected]> >> > wrote: >> > >> > Hi Andrew, >> > >> > Josh brought this to my attention late yesterday and I started looking >> > into it. I hope to have a fix pushed shortly. >> > >> > I apologize, I forgot my uportal build script disables running the >> tests. >> > >> > James Wennmacher - Unicon >> > 480.558.2420 >> > >> > On 10/28/2014 08:52 AM, Andrew Petro wrote: >> >> Devs, >> >> >> >> Looks to me like this changeset >> >> >> >> https://github.com/Jasig/uPortal/pull/438 >> >> >> >> causes this unit test to fail: >> >> >> >> http://goo.gl/KS6a6p >> >> >> >> in this way: >> >> >> >> https://gist.github.com/apetro/2ad26a798d6b33e87c49 . >> >> >> >> Locally reverting the change: >> >> >> >> https://github.com/apetro/uPortal/tree/try_reverting_UP-4264 >> >> >> >> locally fixes the problem. >> >> >> >> >> >> Therefore I propose reverting this commit in master. >> >> >> >> >> >> Shall I press the Revert button here, or should we handle this in >> >> another way? https://github.com/Jasig/uPortal/pull/438 >> >> >> >> >> >> Andrew >> >> >> >> >> >> PS: Reminds me of the need to circle back and detangle this codebase >> >> and build so that Travis-CI can reliably build and run the unit >> >> tests, to help catch this kind of thing before Pull Request merge. :) >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> You are currently subscribed to [email protected] as: >> >> [email protected] To unsubscribe, change settings or access >> >> archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> > >> > >> > -- >> > You are currently subscribed to [email protected] as: >> > [email protected] To unsubscribe, change settings or access >> > archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] To unsubscribe, change settings or access archives, >> see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/uportal-dev >> > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- > > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
