It's the forking of ant from maven that is the slowness I'm referring to
in the current uPortal build. If everything was run from just maven,
instead of forking off ant (or using antrun), it would be faster.
However, speed is not the primary reason. It's all of the other ugly
side effects the ant parts cause, that would be why I'd recommend
spending time on this. Just ask James W. how much fun he's had over the
last few months debugging problems related to this.
---- Cris J H
On 10/28/2014 11:14 AM, Misagh Moayyed wrote:
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: bounce-37470921-57692...@lists.wisc.edu
[mailto:bounce-37470921-57692...@lists.wisc.edu] On Behalf Of Cris J
Holdorph
Sent: Tuesday, October 28, 2014 10:49 AM
To: uportal-dev@lists.ja-sig.org
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 <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
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 uportal-dev@lists.ja-sig.org as:
jwennmac...@unicon.net To unsubscribe, change settings or access
archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
andrew.pe...@wisc.edu To unsubscribe, change settings or access
archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
mmoay...@unicon.net To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to uportal-dev@lists.ja-sig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
