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.org<mailto:uportal-dev@lists.ja-sig.org> as: jwennmac...@unicon.net<mailto: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
