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
