That's exactly, or well very close anyway, to my original point. What
people in this thread have been referring to "2". I strongly believe
that the installation and the system admin tasks need to come out of the
build scripts completely. They simply do not need to be part of them,
and it causes problems as you are saying.
---- Cris J H
On 11/07/2014 11:05 AM, James Wennmacher wrote:
This is a bit tangential, but one thing I'd like to see is uPortal move
away from needing to do a build in order to deploy to an environment.
Having a built artifact (ear, war, etc.) that can be deployed to any
environment (local, dev, test, etc.) and having all environment-specific
configuration be pulled from external configuration/property files IMHO
is desirable. It wouldn't eliminate the need for the overlays, but it
would reduce it a bit and would eliminate the need for the filtering
process and would simplify the build process a bit, but make the deploy
process perhaps a bit more complicated. It might also make it easier to
use Docker, Chef, or similar with uPortal.
Not now ... baby steps ... but worth mentioning/considering in case you
have to jump through hoops to get Gradle to accommodate uPortal's
current approach.
James Wennmacher - Unicon
480.558.2420
On 11/07/2014 10:09 AM, Misagh Moayyed wrote:
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: bounce-37554527-57692...@lists.wisc.edu [mailto:bounce-37554527-
57692...@lists.wisc.edu] On Behalf Of Cris J Holdorph
Sent: Friday, November 7, 2014 9:11 AM
To: uportal-dev@lists.ja-sig.org
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 uportal-dev@lists.ja-sig.org as:
holdo...@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:
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
