[jsword-devel] web sites

[Joe Walker]

I should add 2 things:
- nightly.sh basically just takes the output of rebuild.sh and mails 
them to someone. So to check it is working you run rebuild.sh at watch 
the output directly.
- we will need to add the email address used by nightly.sh to the things 
to be customized in settings.XXX.sh!

Joe.

Joe Walker wrote:

> 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
>
>
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel