[jsword-devel] web sites

[Joe Walker]

Probably the simplest way to simulate "live" would be to install cygwin 
and run from there if you don't have a current Linux install.

Either way my crontab at home reads:
0 12 * * * sh /home/offsite/jsword/etc/build/nightly.sh

and there is a similar one at crosswire with a different path - 
/home/joe/devt rather than /home/offsite, I think. I'll use /wibble from 
now on

You then create 2 files:
/wibble/jsword/etc/build/settings.`dnsdomainname`.sh
/wibble/jsword/etc/build/commands.`dnsdomainname`.sh

Where `dnsdomainname` is a command that you should type to find out your 
domain.

The latter can be empty, it simply contains custom commands for your 
system (it was used at crosswire to rest permissions on the CVS 
directories while I was using extssh - do you remember the permission 
denied errors?)
The settings file you will need to edit - if contains pointers to things 
like where you want the webapp created, where the ftp download area 
(from a local directory point of view and from a web url point of view). 
If should be fairly self explanatory.

Joe.

DM Smith wrote:

> Joe,
>     I would like to know how to set up a test environment that 
> simulates production and how to build to it. If I had that I could 
> test the changes. It does not matter to me whether it is Windows or 
> Linux. I can shift my development from one to the other.
>     Part of the complexity is how Eclipse structures projects. Most 
> other build systems have a root and then recurse into sub-directories. 
> Eclipse does not have the notion of sub-projects, which would be 
> necessary to make it work.
>     I agree that it would be a good idea to pursue wiki for the future.
> DM
>
> Joe Walker wrote:
>
>>
>> Thanks for the comments. I'm going to fix the current scheme first.
>>
>> The reasoning is that our build system is complex. (And that is just 
>> life I think, build systems that work across several projects just 
>> are. If you care about a layered system then you have separate source 
>> directories, which means a complex build)
>>
>> Since the build system is complex is is frequently broken - I think 
>> it must be the single item most likely to be broken that we have. 
>> build.xml generally has the highest rev# on any project that I've 
>> worked on.
>>
>> BUT on the other hand some of the most important files that we have 
>> are the website, and there is no compile check before we commit to 
>> make sure that the website is not broken.
>>
>> A wiki would:
>> - break the dependency of the website on the build system
>> - shorten the distance between the edit and the view.
>>
>> In answer to specific points from Paul and DM:
>> - The bug is "the website is unstable", and it makes the code easier 
>> to maintain by allowing us to spend less time on the website.
>> - We can export all the data from snipsnap into xml, and then check 
>> it into CVS using cron. This would give us some history should we 
>> need it.
>> - SnipSnap can be switched to disallow public contribution and to 
>> remove the comment link, giving us total control over all the content.
>>
>> Point taken about "not now", but I think it would be a good idea for 
>> the future.
>>
>> Joe.
>>
>> DM Smith wrote:
>>
>>> I also agree that backup and control are important.
>>>
>>> I have shied away from wiki because it seemed to uncontrolled and 
>>> chaotic. More like a joint blog. Which would be just fine for a forum.
>>>
>>> At this point in time, I think we need to keep the goal in mind: a 
>>> 1.0 release. We need to consider the standard issues that are part 
>>> and parcel w/ a product release:
>>>     Correctness: Does the change fix a bug?
>>>     Maintainability: Does the change make the code easier to maintain?
>>>     Quality: Does the change enhance the quality?
>>>     Requirement: Does the change deliver promised functionality?
>>>     ....
>>>
>>> I also agree that the website needs some re-working. I just don't 
>>> know if now is the right time to change the mechanism of its 
>>> presentation.
>>>
>>> Paul Price wrote:
>>>
>>>> Hi Joe.
>>>>
>>>>     I wasn't sure what SnipSnap was, so I had a quick google
>>>> (http://snipsnap.org).  It looks like your standard Wiki to me (and I
>>>> thought that, yes, you could tell this one a mile off too....:).  My
>>>> only concern over a move would be that all content should be backed up
>>>> and controlled.  Being able to do it via CVS would be nice, but I 
>>>> don't
>>>> think that CVS is necessarily the only way to go here.
>>>>
>>>> Cheers,
>>>>
>>>> Paul.
>>>> <><
>>>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel