So this gets me curious; before I spin to research mode I am wondering: are there any advantages to switch from ant over to a pure maven/gradle build that would help with performance? Or, are you saying if the build was to convert over to say a pure maven/gradle build there are features (like parallel builds and such) that uPortal could use to speed up build time?
I have converted projects from maven to gradle and have not noticed any significant performance improvements. No parallel builds or any other changes were made of course to the build scripts. Same old config, just written a different way executed on the same machine. One thing however that I noticed tremendously sped up the build was generation of log data as part of tests. Huge difference there. Of course, changing tests to less rely on external resources did help to a degree as well. Builds that used to take beyond 50 minutes (and thereby timing out on Travis because Travis has a 50-minute mark set for public projects on their free plan) now complete in less than 20 minutes, give or take. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Cris J Holdorph Sent: Tuesday, October 28, 2014 10:49 AM To: [email protected] Subject: Re: [uportal-dev] master unit tests broken Personally I think spending more time on getting rid of all the 'Ant' related parts would be a lot better then trying to break up uPortal into even smaller pieces. I understand the aspect you mention about disabling tests because they take so long, and if the tests took less time, then maybe you'd be less inclined to skip them. However, it's the 'build' in general that's taking a long time. And the "ant" parts of this build cause a LOT of problems. Speed is one them. Your recent mac/forking problem is an example of a second one. If you break the uPortal build into smaller chunks you will potentially address one small problem, but you will create new ones. One problem I see a LOT when a project is broken down into too small chunks, is that people then compile at too low of a level. Say you modify the groups api project. But you don't bother to rebuild the permissions project. And then something is broken. You never noticed, because you didn't rebuild everything. And if you DO rebuild everything, well then breaking the project apart, didn't really save you any time. It just introduced build time overhead. ---- Cris J H On 10/28/2014 10:20 AM, Andrew Petro wrote: > 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
