[jsword-devel] web sites

Sat Aug 14 04:49:32 MST 2004

Joe,
	I run both WinXP SP2 and Fedora Core 2.
	Your answer is helpful, but I have another question? What do you use to 
run the jsp and are there any special setup instructions for it?
DM

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