uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Where to put large generated things for our website to access
Date Mon, 24 Dec 2007 03:48:36 GMT
I updated our website download page and documentation page.  I made the
download page work with mirrors, and changed the format for accessing
previous archived files to follow the common practice on other sites,
referring to the archive.apache.org site.

I made our documentation page refer to apache.org/dist/incubator/uima
for the doc files - and didn't put any of these into our SVN for our
website.

I also followed common practice and put our Release notes into the
apache.org/dist/i/u at the top level (I changed the name to add the
suffix of the release version).  This allows (via the archive system)
for these things to be always available.

I added the Eclipse update site to a.o/d/i/u

The only thing not done as of yet is setting up a .htaccess file in this
directory, and adding HEADER.html and README.html files to make
directory listing more "customized".  I'm not going to tackle this right
now - if anyone else wants to take a crack, OK with me.

-Marshall

Michael Baessler wrote:
> Fine with me.
>
> -- Michael
>
> Marshall Schor wrote:
>> One further thought:  A lot of projects put the RELEASE NOTES for
>> particular releases at the "top level" of the dist/ - where the file
>> name includes the release:  for example:
>>   ANT:   RELEASE-NOTES-1.7.0.html
>>   HTTPD:   CHANGES_2.2.6
>>
>> Since these will get archived, and redirects can be done for them, their
>> URLs can be permanent.
>>
>> To be consistent with this practice, I would like to put our release
>> notes for display from our web site in a.o/dist/...
>>
>> They don't need to be signed, because only archives need that; also,
>> other projects don't sign these kinds of things. Any objections?
>>
>> -Marshall
>>
>>
>> Marshall Schor wrote:
>>  
>>> Here's an argument for keeping the big things we point to from our
>>> website, like the javaDocs and the 4 books in html form, on the
>>> a.o/dist/incubator/uima site:
>>>
>>>     It is automatically archived.  And, when it's "deleted" from the
>>> mirror, a redirect is put in to the archive spot.
>>>
>>> This would be ideal for being able to have older versions kept with
>>> permanent static URLs.
>>>
>>> So - upon further reflection - I think I'm changing my mind on this,
>>> and
>>> am now in favor of keeping these on the mirroring system.
>>> We can avoid having people who are on our web site and want to view the
>>> documentation, having to check signatures by not using the mirroring
>>> system, but just pointing them to the main a.o/dist location.  I'm not
>>> sure if this would be OK in terms of protocol for load balancing, but
>>> I'll set the doc page up this way for now, and we can change it if we
>>> need to. 
>>> -Marshall
>>>
>>> Michael Baessler wrote:
>>>      
>>>> Fine with me to delete the HTML documentations (manual and javadoc) on
>>>> the mirror. I thought we can use it and link them from our website.
>>>>
>>>> As far as I know, there is no script to upload the documentation. I
>>>> did it manually.
>>>>
>>>> -- Michael
>>>>
>>>> Marshall Schor wrote:
>>>>          
>>>>> Here are some examples of large files (or large collections of files
>>>>>
>>>>> The api java docs;
>>>>> The api java docs as a zip file
>>>>> The 4 books in html format
>>>>>
>>>>> It seems good to put them in
>>>>> people.a.o/www/incubator.a.o/uima/downloads.
>>>>>
>>>>> It seems bad to put them in SVN (because there's no need for
>>>>> "versioning" these - they're generated, and they are big, taking
>>>>> up SVN
>>>>> space).
>>>>>
>>>>> Our current strategy is hybrid:
>>>>>
>>>>> 1) for current release only: api java docs and the api java docs.zip
>>>>> file are put in people.a.o/www/incubator.a.o/uima/downloads, and are
>>>>> *not* kept in SVN.
>>>>> 2) for current release only: the 4 books in html format are put in
>>>>> SVN
>>>>> and copied to people.a.o/www/incubator.a.o/uima/downloads with the
>>>>> svn
>>>>> update command.
>>>>>
>>>>> I see, in fact that for release 2.2.0, we managed to put the books in
>>>>> html format into SVN twice - once under
>>>>>  2.2.0-incubating/docs/html, and once under
>>>>>  2.2.0-incubating/html
>>>>> and of course, on the website, it shows up twice also...  not good.
>>>>>
>>>>> Is there any automated process for getting the files installed on
>>>>> people.a.o/www/incubator.a.o/uima/downloads?  (Has anyone done any
>>>>> scripts for this)?
>>>>>
>>>>> Does everyone agree that it's best to keep these out of SVN, and
>>>>> to put
>>>>> them in the web server spot on
>>>>> people.a.o/www/incubator.a.o/uima/downloads?
>>>>>
>>>>> ===================
>>>>>
>>>>> The mirrored distribution spot contains, in addition to /binaries and
>>>>> /source, a /docs directory with the the following:
>>>>> <release>/apiDocs.zip , plus the 3 "signing" files [asc, md5, sha1]
>>>>> <release>/api /....     <-- unzipped set of javaDoc html files,
no
>>>>> signing files
>>>>> <release>/html/.....   <-- set of 4 books as html files, no
signing
>>>>> files
>>>>> <release>/pdf/.....    <-- set of 4 books as pdfs, no signing
files
>>>>>
>>>>> I think everything that's put onto the mirroring system is
>>>>> supposed to
>>>>> be signed, because Apache doesn't "control" what goes on at the
>>>>> mirrors
>>>>> (e.g., they could be "hacked").
>>>>>
>>>>> Currently, our download page is slient about the existance of these.
>>>>>
>>>>> I think we should delete these on the mirroring distribution system.
>>>>> Assuming we followed the top part of this note, we would have
>>>>> everything
>>>>> (except the pdf form of the 4 books) on the UIMA website, directly
>>>>> (not
>>>>> going thru a mirror).
>>>>>
>>>>> Other opinions?
>>>>>
>>>>> -Marshall
>>>>>
>>>>>                 
>>>>           
>>>
>>>       
>>
>>   
>
>
>


Mime
View raw message