I'm curious. What does the CLI need from tomcat? Is it the shared/lib/*
or the and the servlet-api.jar or tomcat-jdbc jar?
It needs all the provided dependencies in order to build the executable for
groovy due to it calling org.jasig.portal.shell.PortalShell which is in the war.
If you look at the definition of uportal-war-macro which is used in the target
up-shell you can see what ant is doing. We just wanted a way to run the groovy
script independently of ant.
It would be great to run a gradle build. I'm actually playing with it right now
for the uportal-bundle quickstart upload. Fun fact, you can call ant scripts
from gradle. Might make it an easier transition?
- Tim
From: bounce-41575205-70367...@lists.wisc.edu
bounce-41575205-70367...@lists.wisc.edu on behalf of James Wennmacher
jwennmac...@unicon.net
Sent: Wednesday, June 10, 2015 12:50 PM
To: uportal-dev@lists.ja-sig.org
Subject: Re: [uportal-dev] Module for CLI
I think this is a good thing.
Not to over-complicate it and tie it to other future work, but just dreaming,
it would be better with the gradle build (which Misagh has done some work on)
and specifically having the operational functions (non-build) be a separate
groovy, gradle, or whatever script that knows its dependencies and can
auto-resolve them.
If doing it with the current ant/maven strategy, it doesn't seem like it owuld
be that hard to have another module that builds a jar for the CLI or possibly
make it an alternate profile for the uportal-war project since you don't want
to build it all the time.
I'm curious. What does the CLI need from tomcat? Is it the shared/lib/* or
the and the servlet-api.jar or tomcat-jdbc jar?
James Wennmacher - Unicon
480.558.2420
On 06/10/2015 09:15 AM, Tim Levett wrote:
Hi Devs,
Me again. I had a thought, and I may have mentioned it last week. Does anyone
else have the desire to have a separate module for the uPortal CLI?
Our use case is we do entity imports via a jenkins job. We want this job to be
completely independent of a uPortal war instance. In order to be able to do
this on a build server we have to do a hack to get the groovy script to run.
Basically, we add .m2/repo//[tomcat lib].jar jars to the class path of the
java command. We get that list by running a maven script to list the provided
dependencies. Its very flaky, I don't recommend it. This got me thinking, what
if we could just have a jar that we could run with all the right classes in it
so we could do anything the CLI could do. It would force us to modularize the
uPortal war, which could be healthy.
Again, just curious if anyone else has this desire.
- Tim Levett
--
You are currently subscribed to
uportal-dev@lists.ja-sig.orgmailto:uportal-dev@lists.ja-sig.org as:
jwennmac...@unicon.netmailto: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:
tim.lev...@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:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
