[jsword-devel] web sites
DM Smith
dmsmith555 at yahoo.com
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
>
More information about the jsword-devel
mailing list