I think there are two cases: build-time and run-time. For the run-time: I think we have to assume that external access is not possible for the target cluster. Hence, at run-time users employing the DUCC web-server need only access to it to obtain the necessary javascripts.
For the build-time: if the javascripts and images can be obtained by maven at external sites on-the-fly and put in the proper web-server location that is perfectly acceptable. Note, however that some images have been reduced in size by your truly using image manipulation tools, and thus their inclusion in our SVN is warranted. Finally, as to which javascripts to use, the human-readable ones or the compacted ones, I'm indifferent since I don't spend much time looking at the guts of these things (other than our own ducc.js). I don't know that there is much benefit to using the compacted versions, but am willing to consider this post-Rel 1.0. Lou. On Wed, Nov 20, 2013 at 5:47 PM, Marshall Schor <m...@schor.com> wrote: > I may have missed this discussion before, if so, please point me to the > thread ... > > DUCC includes a website that is provided by running a web server (Jetty, I > think > - is that right?). > > The site makes use of many javascript libraries (jquery and so forth). > > When building the website, the current design I think incorporates the > javascript libraries as part of the web project's "binary" build > artifacts. It > does this by building from a copy of the javascript sources in our svn > source > tree; these have been put there manually; as I understand it, this is > because > there wasn't a "maven central" kind of artifact that could be incorporated > at > build time. (I do see some jquery maven artifacts, but I'm not sure these > are > the "packaging" that you want). > > Reading on the internet indicates that jquery comes with some "packaging" > things > that let you incorporate /exclude the parts you need, and then you can do > some > kind of optimization (I'm guessing) to prepare a faster-to-load version of > it > for your application. I'm guessing we don't do any of that (yet) (maybe > for a > future release?). > > If we don't do any of that, I'm guessing there are several alternatives for > arranging to use these kinds of javascript libraries: > 1) copy the library sources into our SVN, and package these in the binary > build. In this case the web pages DUCC serves would use references to the > "built" subdirectories where these reside to load from. > > 2) Have the web pages DUCC serves use references to some standard places > on the > web where these libraries reside. For instance, using <script > src="http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js";> > > 3) Have the web pages DUCC serves use references to another standard > location > under the control of the Apache UIMA project. This could be our Apache > UIMA > website, or the main Apache distribution point (say, the same place where > we put > the Eclipse Update Site). > > Has this been discussed and intentionally decided on? I'm thinking the > team > picked (1). As far as I can tell (reading through several discussions on > other > lists) it's OK to have Apache-compatible licensed sources in our svn, and > these > libraries are licensed with the MIT license. And they are currently > packaged > under a separate SVN folder, which is nice. So maybe this is not an issue > that > needs resolving, but I'm posting it in case others want to chime in, or > clarify > the intents. > > -Marshall > > >
