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]<mailto:[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]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Andrew Petro Sent: Tuesday, October 28, 2014 10:21 AM To: [email protected]<mailto:[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]<mailto:[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<tel: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]<mailto:[email protected]> as: >> [email protected]<mailto:[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]<mailto:[email protected]> as: > [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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
