I delivered Jira 3447 to remove extraneous material from the webserver's opensources directory.
Lou. On Fri, Nov 22, 2013 at 9:04 AM, Lou DeGenaro <lou.degen...@gmail.com>wrote: > 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 >> >> >> >
