Agreed on all counts. I suppose my first objective was to first do a pure-conversion first and the tackle what can be moved out of the build script and into separate tasks. In terms of the refactoring effort, that seems like it would allow us to first remove a few trees in the way and get a clearer picture of what actually exists. (2) and (3) do not so much belong in the build script for sure, but nonetheless we'd have to provide some mechanism for the functionality they provide and Gradle seems like a good approach for those 2 as well. We can certainly move them out of the mother build script and have adopters simply call upon them when they need them.
Part of the reason (2) and (3) are complected in the build I suppose is because the scripting nature of Ant sort of paved the pathway for those ops and it must have seemed convenient to use the tool for both the build and post-build functionaries. We surely need to break these out, so options are: 1. Break the ant tasks out into a separate configuration. Have the uPortal "build" only be based on Maven and let Ant handle post-build ops like initializing the db, etc. While effort-wise, this might seem simpler, it would be very much confusing for adopters to try to learn the tricks of each tool and what commands are available. 2. Break the ant tasks out into a separate configuration but let both the build as well as (2) and (3) to be based on Gradle. This should provide a seamless syntax and would reduce technical dependencies. Plus, it seems like for some of the gymnastics ant build right now is doing to carry out x-y-z, Gradle would surely be a better fit since you can actually "code" the script rather than declare much of it. P.S1: If I remember correctly, the build we have even today creates and executes custom groovy scripts so in fact, we are using 3 things for a wholesome UP build :) P.S2: I am not prejudiced towards Gradle at all. Any other tool that would do the job with less noise would be most welcome. > -----Original Message----- > From: [email protected] [mailto:bounce-37554527- > [email protected]] On Behalf Of Cris J Holdorph > Sent: Friday, November 7, 2014 9:11 AM > To: [email protected] > Subject: Re: [uportal-dev] Moving away from Ant/Maven to Gradle > > One thing I think is important to look at with the 'build' system in > uPortal, is there has long been parts of the system that have nothing to > do with 'building'. Take a simple example, like adding a new fragment to > uPortal from a fragment definition file. This does not need to be tied to > the build system. Here's another... Loading the initial database. > That's an installation step, not a build step. > > uPortal's build system is complicated because it's trying to be 3 things > in one. It's trying to 1) build uPortal, 2) install uPortal, 3) system > administer uPortal. > > If I was to put time towards working on this problem, my first goal would > be to get "2" and "3" out of the build altogether and handled in some > other way. If you did that, I believe you'd have a simpler build system > then you have right now. > > Going with Gradle to handle the 'scripting' that is currently done in Ant, > tells me that we're just going to keep the problem of having all three of > these things mixed together in one system. I think that's a mistake. And > even if you get to something that feels like an improvement over the > current ant+maven, it will still be more complicated then it needs to be. > > ---- Cris J H > > On 11/07/2014 09:01 AM, Misagh Moayyed wrote: > > uPortal Devs, > > > > I have set aside some time to take a look at the uPortal build system > > and see if we can move away from the ant/maven hybrid setup and either > > to a pure maven-based build or perhaps even use Gradle. I am leaning > > more and more towards Gradle as that would take care of a lot of > > scripting ant-like tasks that exist today and certainly is easier to > > write and configure the build with. The downside is there aren't too > > many plugins available for Gradle like they are with Maven so > > depending on the pluginset uPortal uses today we might run into a few > roadblocks. > > > > So questions are: > > > > 1. How do others feel about this build tool and the approach? > > > > 2. Has anybody begun working on the same proposal locally perhaps? > > > > 3. What uPortal release should this be targeted to? I'd assume 5.0 as > > this would be a pretty big change both in scope and the effort/time > > required to implement this. > > > > Misagh > > > > -- > > > > 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
