You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jspwiki.apache.org by Glen Mazza <gl...@gmail.com> on 2012/12/09 15:23:15 UTC
Simplify OOTB deployment for new users?
Hi all, JSPWiki is presently nicely configured for (1) those who already
know what they're doing and have JSPWiki in production already, but can
be problematic for (2) newbie evaluators who just want to place a WAR in
the Tomcat and see what JSPWiki looks like and (3) newbie patch
submitters who have to do debugging but are annoyed at needing to
re-enter configuration, authorization and test page info everytime they
want to deploy a new WAR. I believe OOTB configuration should be better
suited for (2) and (3) as the users in (1) already know how to configure
their jspwiki.properties/jspwiki.properties.impl files and nearly
invariably have to do so anyway for their production deployments.
I was thinking we should maybe update our jspwiki.properties.impl file
with the following changes:
-jspwiki.baseURL=
+jspwiki.baseURL=http://localhost:8080/JSPWiki
-#jspwiki.workDir =
+jspwiki.workDir = myJSPWikiDir
-jspwiki.fileSystemProvider.pageDir = @pagedir@
+jspwiki.fileSystemProvider.pageDir = myJSPWikiDir/p/web/www-data/jspwiki/
-jspwiki.basicAttachmentProvider.storageDir = @pagedir@
+jspwiki.basicAttachmentProvider.storageDir =
myJSPWikiDir/p/web/www-data/jspwiki/
For incoming newbies in (2), we have a narrow window when they're
evaluating a Wiki for their corporate intranets and anything we can do
to shrink the soap opera between generating a WAR and viewing it from
their local Tomcat would be a good thing. Here, all we have to say is
generate the WAR (if they haven't downloaded it anyway from the
distribution) and dump in their local Tomcat and they can view it at
http://localhost:8080/JSPWiki and they're done. Couldn't be simpler.
While a URL of http://localhost:8080/JSPWiki may not work for *all*
newbies, it's far and away the most common URL for someone prototyping
on their local machine with Tomcat, sharply reducing the % who will
still need to configure the jspwiki.properties file.
Also, combining all files that JSPWiki creates into one place
"myJSPWikiDir" (or whatever you'd want to call it) that Tomcat nicely
creates in the user's home folder helps them easily see all of JSPWiki's
internal moving parts while remaining fully comfortable that JSPWiki
isn't dumping files in system folders that they're going to have trouble
finding and cleaning out later. It's uncomfortable/unnerving to
newcomers to see OOTB JSPWiki placing files in the "/p/web/..." of their
root system drive (a folder system the average user might not have
permission to anyway), especially for something they're just evaluating
locally.
For developers in (3), these above settings work great for me during
testing and debugging on my local standalone Tomcat, I just need to drop
the generated WAR in Tomcat each time I do an "ant war" without needing
to bother to reconfigure the jspwiki.properties file each time. This,
however, took me quite a while to figure out on my own and I'd like to
have this setup OOTB for any quick patch submitter without them needing
to go through similar initial headaches.
Regards,
Glen
Re: Simplify OOTB deployment for new users?
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi Glen,
latest commit puts http://localhost:8080/JSPWiki as the default
jspwiki.baseUrl value. I haven't changed the other values as they could be
overrided via -Dbuild.properties but if you think that's not enough we can
take a look at it.
br,
juan pablo
On Sun, Dec 9, 2012 at 7:26 PM, Glen Mazza <gl...@gmail.com> wrote:
> Harry, personally at least, I've never needed to do that, at least not
> with my setup (JDK 7 and Tomcat 7 on Ubuntu Linux) -- just dump the WAR in
> webapps and it expands fine. You may wish to try again with a newer Tomcat
> maybe. I would say that would be a Tomcat bug if it couldn't expand the
> WAR properly.
>
> It will get better once we can Mavenize (and I hope to put in some time to
> help in that regard), during development/debugging/testing it will just be
> c:\mvn tomcat7:deploy for a standalone Tomcat or c:\mvn tomcat7:run-war for
> an embedded Tomcat deployment, in the latter case you won't even need to
> have Tomcat installed on your machine, but in either case we can avoid the
> step of needing to go to file managers and copying/pasting the build/WAR to
> the webapps folder.
>
> Glen
>
>
> On 12/09/2012 01:03 PM, Harry Metske wrote:
>
>> +1 on the proposed changes for the default settings.
>> There is however still an issue with JSPWiki that makes it unsuitable for
>> a
>> plain war deployment, you always have to unzip the war into the tomcat
>> webapps dir to make it work, but I can't find out why this was the case.
>>
>> regards,
>> Harry
>>
>>
>>
>> On 9 December 2012 15:23, Glen Mazza <gl...@gmail.com> wrote:
>>
>> Hi all, JSPWiki is presently nicely configured for (1) those who already
>>> know what they're doing and have JSPWiki in production already, but can
>>> be
>>> problematic for (2) newbie evaluators who just want to place a WAR in the
>>> Tomcat and see what JSPWiki looks like and (3) newbie patch submitters
>>> who
>>> have to do debugging but are annoyed at needing to re-enter
>>> configuration,
>>> authorization and test page info everytime they want to deploy a new WAR.
>>> I believe OOTB configuration should be better suited for (2) and (3) as
>>> the users in (1) already know how to configure their
>>> jspwiki.properties/jspwiki.****properties.impl files and nearly
>>> invariably
>>> have to do so anyway for their production deployments.
>>>
>>> I was thinking we should maybe update our jspwiki.properties.impl file
>>> with the following changes:
>>>
>>> -jspwiki.baseURL=
>>> +jspwiki.baseURL=http://****localhost:8080/JSPWiki<http://**
>>> localhost:8080/JSPWiki <http://localhost:8080/JSPWiki>>
>>>
>>> -#jspwiki.workDir =
>>> +jspwiki.workDir = myJSPWikiDir
>>>
>>> -jspwiki.fileSystemProvider.****pageDir = @pagedir@
>>> +jspwiki.fileSystemProvider.****pageDir = myJSPWikiDir/p/web/www-data/**
>>> jspwiki/
>>>
>>> -jspwiki.****basicAttachmentProvider.****storageDir = @pagedir@
>>> +jspwiki.****basicAttachmentProvider.****storageDir =
>>> myJSPWikiDir/p/web/www-data/****jspwiki/
>>>
>>> For incoming newbies in (2), we have a narrow window when they're
>>> evaluating a Wiki for their corporate intranets and anything we can do to
>>> shrink the soap opera between generating a WAR and viewing it from their
>>> local Tomcat would be a good thing. Here, all we have to say is generate
>>> the WAR (if they haven't downloaded it anyway from the distribution) and
>>> dump in their local Tomcat and they can view it at
>>> http://localhost:8080/JSPWiki and they're done. Couldn't be simpler.
>>> While a URL of http://localhost:8080/JSPWiki may not work for *all*
>>> newbies, it's far and away the most common URL for someone prototyping on
>>> their local machine with Tomcat, sharply reducing the % who will still
>>> need
>>> to configure the jspwiki.properties file.
>>>
>>> Also, combining all files that JSPWiki creates into one place
>>> "myJSPWikiDir" (or whatever you'd want to call it) that Tomcat nicely
>>> creates in the user's home folder helps them easily see all of JSPWiki's
>>> internal moving parts while remaining fully comfortable that JSPWiki
>>> isn't
>>> dumping files in system folders that they're going to have trouble
>>> finding
>>> and cleaning out later. It's uncomfortable/unnerving to newcomers to see
>>> OOTB JSPWiki placing files in the "/p/web/..." of their root system drive
>>> (a folder system the average user might not have permission to anyway),
>>> especially for something they're just evaluating locally.
>>>
>>> For developers in (3), these above settings work great for me during
>>> testing and debugging on my local standalone Tomcat, I just need to drop
>>> the generated WAR in Tomcat each time I do an "ant war" without needing
>>> to
>>> bother to reconfigure the jspwiki.properties file each time. This,
>>> however, took me quite a while to figure out on my own and I'd like to
>>> have
>>> this setup OOTB for any quick patch submitter without them needing to go
>>> through similar initial headaches.
>>>
>>> Regards,
>>> Glen
>>>
>>>
>>>
>
Re: Simplify OOTB deployment for new users?
Posted by Glen Mazza <gl...@gmail.com>.
Harry, personally at least, I've never needed to do that, at least not
with my setup (JDK 7 and Tomcat 7 on Ubuntu Linux) -- just dump the WAR
in webapps and it expands fine. You may wish to try again with a newer
Tomcat maybe. I would say that would be a Tomcat bug if it couldn't
expand the WAR properly.
It will get better once we can Mavenize (and I hope to put in some time
to help in that regard), during development/debugging/testing it will
just be c:\mvn tomcat7:deploy for a standalone Tomcat or c:\mvn
tomcat7:run-war for an embedded Tomcat deployment, in the latter case
you won't even need to have Tomcat installed on your machine, but in
either case we can avoid the step of needing to go to file managers and
copying/pasting the build/WAR to the webapps folder.
Glen
On 12/09/2012 01:03 PM, Harry Metske wrote:
> +1 on the proposed changes for the default settings.
> There is however still an issue with JSPWiki that makes it unsuitable for a
> plain war deployment, you always have to unzip the war into the tomcat
> webapps dir to make it work, but I can't find out why this was the case.
>
> regards,
> Harry
>
>
>
> On 9 December 2012 15:23, Glen Mazza <gl...@gmail.com> wrote:
>
>> Hi all, JSPWiki is presently nicely configured for (1) those who already
>> know what they're doing and have JSPWiki in production already, but can be
>> problematic for (2) newbie evaluators who just want to place a WAR in the
>> Tomcat and see what JSPWiki looks like and (3) newbie patch submitters who
>> have to do debugging but are annoyed at needing to re-enter configuration,
>> authorization and test page info everytime they want to deploy a new WAR.
>> I believe OOTB configuration should be better suited for (2) and (3) as
>> the users in (1) already know how to configure their
>> jspwiki.properties/jspwiki.**properties.impl files and nearly invariably
>> have to do so anyway for their production deployments.
>>
>> I was thinking we should maybe update our jspwiki.properties.impl file
>> with the following changes:
>>
>> -jspwiki.baseURL=
>> +jspwiki.baseURL=http://**localhost:8080/JSPWiki<http://localhost:8080/JSPWiki>
>>
>> -#jspwiki.workDir =
>> +jspwiki.workDir = myJSPWikiDir
>>
>> -jspwiki.fileSystemProvider.**pageDir = @pagedir@
>> +jspwiki.fileSystemProvider.**pageDir = myJSPWikiDir/p/web/www-data/**
>> jspwiki/
>>
>> -jspwiki.**basicAttachmentProvider.**storageDir = @pagedir@
>> +jspwiki.**basicAttachmentProvider.**storageDir =
>> myJSPWikiDir/p/web/www-data/**jspwiki/
>>
>> For incoming newbies in (2), we have a narrow window when they're
>> evaluating a Wiki for their corporate intranets and anything we can do to
>> shrink the soap opera between generating a WAR and viewing it from their
>> local Tomcat would be a good thing. Here, all we have to say is generate
>> the WAR (if they haven't downloaded it anyway from the distribution) and
>> dump in their local Tomcat and they can view it at
>> http://localhost:8080/JSPWiki and they're done. Couldn't be simpler.
>> While a URL of http://localhost:8080/JSPWiki may not work for *all*
>> newbies, it's far and away the most common URL for someone prototyping on
>> their local machine with Tomcat, sharply reducing the % who will still need
>> to configure the jspwiki.properties file.
>>
>> Also, combining all files that JSPWiki creates into one place
>> "myJSPWikiDir" (or whatever you'd want to call it) that Tomcat nicely
>> creates in the user's home folder helps them easily see all of JSPWiki's
>> internal moving parts while remaining fully comfortable that JSPWiki isn't
>> dumping files in system folders that they're going to have trouble finding
>> and cleaning out later. It's uncomfortable/unnerving to newcomers to see
>> OOTB JSPWiki placing files in the "/p/web/..." of their root system drive
>> (a folder system the average user might not have permission to anyway),
>> especially for something they're just evaluating locally.
>>
>> For developers in (3), these above settings work great for me during
>> testing and debugging on my local standalone Tomcat, I just need to drop
>> the generated WAR in Tomcat each time I do an "ant war" without needing to
>> bother to reconfigure the jspwiki.properties file each time. This,
>> however, took me quite a while to figure out on my own and I'd like to have
>> this setup OOTB for any quick patch submitter without them needing to go
>> through similar initial headaches.
>>
>> Regards,
>> Glen
>>
>>
Re: Simplify OOTB deployment for new users?
Posted by Harry Metske <ha...@gmail.com>.
+1 on the proposed changes for the default settings.
There is however still an issue with JSPWiki that makes it unsuitable for a
plain war deployment, you always have to unzip the war into the tomcat
webapps dir to make it work, but I can't find out why this was the case.
regards,
Harry
On 9 December 2012 15:23, Glen Mazza <gl...@gmail.com> wrote:
> Hi all, JSPWiki is presently nicely configured for (1) those who already
> know what they're doing and have JSPWiki in production already, but can be
> problematic for (2) newbie evaluators who just want to place a WAR in the
> Tomcat and see what JSPWiki looks like and (3) newbie patch submitters who
> have to do debugging but are annoyed at needing to re-enter configuration,
> authorization and test page info everytime they want to deploy a new WAR.
> I believe OOTB configuration should be better suited for (2) and (3) as
> the users in (1) already know how to configure their
> jspwiki.properties/jspwiki.**properties.impl files and nearly invariably
> have to do so anyway for their production deployments.
>
> I was thinking we should maybe update our jspwiki.properties.impl file
> with the following changes:
>
> -jspwiki.baseURL=
> +jspwiki.baseURL=http://**localhost:8080/JSPWiki<http://localhost:8080/JSPWiki>
>
> -#jspwiki.workDir =
> +jspwiki.workDir = myJSPWikiDir
>
> -jspwiki.fileSystemProvider.**pageDir = @pagedir@
> +jspwiki.fileSystemProvider.**pageDir = myJSPWikiDir/p/web/www-data/**
> jspwiki/
>
> -jspwiki.**basicAttachmentProvider.**storageDir = @pagedir@
> +jspwiki.**basicAttachmentProvider.**storageDir =
> myJSPWikiDir/p/web/www-data/**jspwiki/
>
> For incoming newbies in (2), we have a narrow window when they're
> evaluating a Wiki for their corporate intranets and anything we can do to
> shrink the soap opera between generating a WAR and viewing it from their
> local Tomcat would be a good thing. Here, all we have to say is generate
> the WAR (if they haven't downloaded it anyway from the distribution) and
> dump in their local Tomcat and they can view it at
> http://localhost:8080/JSPWiki and they're done. Couldn't be simpler.
> While a URL of http://localhost:8080/JSPWiki may not work for *all*
> newbies, it's far and away the most common URL for someone prototyping on
> their local machine with Tomcat, sharply reducing the % who will still need
> to configure the jspwiki.properties file.
>
> Also, combining all files that JSPWiki creates into one place
> "myJSPWikiDir" (or whatever you'd want to call it) that Tomcat nicely
> creates in the user's home folder helps them easily see all of JSPWiki's
> internal moving parts while remaining fully comfortable that JSPWiki isn't
> dumping files in system folders that they're going to have trouble finding
> and cleaning out later. It's uncomfortable/unnerving to newcomers to see
> OOTB JSPWiki placing files in the "/p/web/..." of their root system drive
> (a folder system the average user might not have permission to anyway),
> especially for something they're just evaluating locally.
>
> For developers in (3), these above settings work great for me during
> testing and debugging on my local standalone Tomcat, I just need to drop
> the generated WAR in Tomcat each time I do an "ant war" without needing to
> bother to reconfigure the jspwiki.properties file each time. This,
> however, took me quite a while to figure out on my own and I'd like to have
> this setup OOTB for any quick patch submitter without them needing to go
> through similar initial headaches.
>
> Regards,
> Glen
>
>
Re: Simplify OOTB deployment for new users?
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
yes please! :-)
br,
juan pablo
On Sun, Dec 30, 2012 at 6:18 PM, Glen Mazza <gl...@gmail.com> wrote:
> Like me to add a JIRA for this so it doesn't slip through the cracks?
>
> Glen
>
>
> On 12/10/2012 05:32 PM, Juan Pablo Santos Rodríguez wrote:
>
>> Hi Glen,
>>
>> yes, probably something like ${user.home}/jspwiki-files probably makes
>> much
>> more sense, I'll try to have a look at it in the next days
>>
>>
>> br,
>> juan pablo
>>
>> On Sun, Dec 9, 2012 at 10:47 PM, Glen Mazza <gl...@gmail.com> wrote:
>>
>> I don't think java.io.tmpdir is a good location for the permanent stuff
>>> in
>>> jspwiki.fileSystemProvider.****pageDir and jspwiki.**
>>> basicAttachmentProvider.****storageDir; and at the same time, writing
>>> to a
>>>
>>> user's root folder via /p/..... is too intrusive/uncomfortable for
>>> someone
>>> just prototyping. I still think a simple "myJSPWikiDir" (or whatever
>>> other
>>> name you'd like) which results in the files being placed in that
>>> subdirectory of the user's home folder is the user-friendlier option for
>>> these latter two values, even if we keep jspwiki.workDir undefined so it
>>> still points to java.io.tmpdir.
>>>
>>>
>
Re: Simplify OOTB deployment for new users?
Posted by Glen Mazza <gl...@gmail.com>.
Like me to add a JIRA for this so it doesn't slip through the cracks?
Glen
On 12/10/2012 05:32 PM, Juan Pablo Santos Rodríguez wrote:
> Hi Glen,
>
> yes, probably something like ${user.home}/jspwiki-files probably makes much
> more sense, I'll try to have a look at it in the next days
>
>
> br,
> juan pablo
>
> On Sun, Dec 9, 2012 at 10:47 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>> I don't think java.io.tmpdir is a good location for the permanent stuff in
>> jspwiki.fileSystemProvider.**pageDir and jspwiki.**
>> basicAttachmentProvider.**storageDir; and at the same time, writing to a
>> user's root folder via /p/..... is too intrusive/uncomfortable for someone
>> just prototyping. I still think a simple "myJSPWikiDir" (or whatever other
>> name you'd like) which results in the files being placed in that
>> subdirectory of the user's home folder is the user-friendlier option for
>> these latter two values, even if we keep jspwiki.workDir undefined so it
>> still points to java.io.tmpdir.
>>
Re: Simplify OOTB deployment for new users?
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hi Glen,
yes, probably something like ${user.home}/jspwiki-files probably makes much
more sense, I'll try to have a look at it in the next days
br,
juan pablo
On Sun, Dec 9, 2012 at 10:47 PM, Glen Mazza <gl...@gmail.com> wrote:
> I don't think java.io.tmpdir is a good location for the permanent stuff in
> jspwiki.fileSystemProvider.**pageDir and jspwiki.**
> basicAttachmentProvider.**storageDir; and at the same time, writing to a
> user's root folder via /p/..... is too intrusive/uncomfortable for someone
> just prototyping. I still think a simple "myJSPWikiDir" (or whatever other
> name you'd like) which results in the files being placed in that
> subdirectory of the user's home folder is the user-friendlier option for
> these latter two values, even if we keep jspwiki.workDir undefined so it
> still points to java.io.tmpdir.
>
Re: Simplify OOTB deployment for new users?
Posted by Glen Mazza <gl...@gmail.com>.
Oh, is jspwiki.workDir *only* for temporary files that may be deleted
with startup & shutdown of Tomcat (i.e., nothing persistent across
Tomcat sessions?) In that case, remaining with java.io.tmpdir may be a
better idea for jspwiki.workDir--but nowadays if it's holding permanent
stuff java.io.tmpdir is probably not a good location for it.
I don't think java.io.tmpdir is a good location for the permanent stuff
in jspwiki.fileSystemProvider.pageDir and
jspwiki.basicAttachmentProvider.storageDir; and at the same time,
writing to a user's root folder via /p/..... is too
intrusive/uncomfortable for someone just prototyping. I still think a
simple "myJSPWikiDir" (or whatever other name you'd like) which results
in the files being placed in that subdirectory of the user's home folder
is the user-friendlier option for these latter two values, even if we
keep jspwiki.workDir undefined so it still points to java.io.tmpdir.
Regards,
Glen
On 12/09/2012 10:39 AM, Juan Pablo Santos Rodríguez wrote:
> Hello Glen,
>
> +1 to jspwiki.baseUrl change, and I agree that /p/web may be not the best
> default value. As for jspwiki.workDir, it defaults to java.io.tmpdir, which
> seems to me a good default value, so why not make
> jspwiki.fileSystemProvider.pageDir and
> jspwiki.basicAttachmentProvider.storageDir use the same default value?
>
> Also, it is possible to specify another build.properties (which holds those
> values) file via -Dbuild.properties property when invoking ant, or by
> replacing in line 66 the value of the build.properties property with your
> custom build.properties file.
>
>
> br,
> juan pablo
>
> On Sun, Dec 9, 2012 at 3:23 PM, Glen Mazza <gl...@gmail.com> wrote:
>
>> Hi all, JSPWiki is presently nicely configured for (1) those who already
>> know what they're doing and have JSPWiki in production already, but can be
>> problematic for (2) newbie evaluators who just want to place a WAR in the
>> Tomcat and see what JSPWiki looks like and (3) newbie patch submitters who
>> have to do debugging but are annoyed at needing to re-enter configuration,
>> authorization and test page info everytime they want to deploy a new WAR.
>> I believe OOTB configuration should be better suited for (2) and (3) as
>> the users in (1) already know how to configure their
>> jspwiki.properties/jspwiki.**properties.impl files and nearly invariably
>> have to do so anyway for their production deployments.
>>
>> I was thinking we should maybe update our jspwiki.properties.impl file
>> with the following changes:
>>
>> -jspwiki.baseURL=
>> +jspwiki.baseURL=http://**localhost:8080/JSPWiki<http://localhost:8080/JSPWiki>
>>
>> -#jspwiki.workDir =
>> +jspwiki.workDir = myJSPWikiDir
>>
>> -jspwiki.fileSystemProvider.**pageDir = @pagedir@
>> +jspwiki.fileSystemProvider.**pageDir = myJSPWikiDir/p/web/www-data/**
>> jspwiki/
>>
>> -jspwiki.**basicAttachmentProvider.**storageDir = @pagedir@
>> +jspwiki.**basicAttachmentProvider.**storageDir =
>> myJSPWikiDir/p/web/www-data/**jspwiki/
>>
>> For incoming newbies in (2), we have a narrow window when they're
>> evaluating a Wiki for their corporate intranets and anything we can do to
>> shrink the soap opera between generating a WAR and viewing it from their
>> local Tomcat would be a good thing. Here, all we have to say is generate
>> the WAR (if they haven't downloaded it anyway from the distribution) and
>> dump in their local Tomcat and they can view it at
>> http://localhost:8080/JSPWiki and they're done. Couldn't be simpler.
>> While a URL of http://localhost:8080/JSPWiki may not work for *all*
>> newbies, it's far and away the most common URL for someone prototyping on
>> their local machine with Tomcat, sharply reducing the % who will still need
>> to configure the jspwiki.properties file.
>>
>> Also, combining all files that JSPWiki creates into one place
>> "myJSPWikiDir" (or whatever you'd want to call it) that Tomcat nicely
>> creates in the user's home folder helps them easily see all of JSPWiki's
>> internal moving parts while remaining fully comfortable that JSPWiki isn't
>> dumping files in system folders that they're going to have trouble finding
>> and cleaning out later. It's uncomfortable/unnerving to newcomers to see
>> OOTB JSPWiki placing files in the "/p/web/..." of their root system drive
>> (a folder system the average user might not have permission to anyway),
>> especially for something they're just evaluating locally.
>>
>> For developers in (3), these above settings work great for me during
>> testing and debugging on my local standalone Tomcat, I just need to drop
>> the generated WAR in Tomcat each time I do an "ant war" without needing to
>> bother to reconfigure the jspwiki.properties file each time. This,
>> however, took me quite a while to figure out on my own and I'd like to have
>> this setup OOTB for any quick patch submitter without them needing to go
>> through similar initial headaches.
>>
>> Regards,
>> Glen
>>
>>
Re: Simplify OOTB deployment for new users?
Posted by Juan Pablo Santos Rodríguez <ju...@gmail.com>.
Hello Glen,
+1 to jspwiki.baseUrl change, and I agree that /p/web may be not the best
default value. As for jspwiki.workDir, it defaults to java.io.tmpdir, which
seems to me a good default value, so why not make
jspwiki.fileSystemProvider.pageDir and
jspwiki.basicAttachmentProvider.storageDir use the same default value?
Also, it is possible to specify another build.properties (which holds those
values) file via -Dbuild.properties property when invoking ant, or by
replacing in line 66 the value of the build.properties property with your
custom build.properties file.
br,
juan pablo
On Sun, Dec 9, 2012 at 3:23 PM, Glen Mazza <gl...@gmail.com> wrote:
> Hi all, JSPWiki is presently nicely configured for (1) those who already
> know what they're doing and have JSPWiki in production already, but can be
> problematic for (2) newbie evaluators who just want to place a WAR in the
> Tomcat and see what JSPWiki looks like and (3) newbie patch submitters who
> have to do debugging but are annoyed at needing to re-enter configuration,
> authorization and test page info everytime they want to deploy a new WAR.
> I believe OOTB configuration should be better suited for (2) and (3) as
> the users in (1) already know how to configure their
> jspwiki.properties/jspwiki.**properties.impl files and nearly invariably
> have to do so anyway for their production deployments.
>
> I was thinking we should maybe update our jspwiki.properties.impl file
> with the following changes:
>
> -jspwiki.baseURL=
> +jspwiki.baseURL=http://**localhost:8080/JSPWiki<http://localhost:8080/JSPWiki>
>
> -#jspwiki.workDir =
> +jspwiki.workDir = myJSPWikiDir
>
> -jspwiki.fileSystemProvider.**pageDir = @pagedir@
> +jspwiki.fileSystemProvider.**pageDir = myJSPWikiDir/p/web/www-data/**
> jspwiki/
>
> -jspwiki.**basicAttachmentProvider.**storageDir = @pagedir@
> +jspwiki.**basicAttachmentProvider.**storageDir =
> myJSPWikiDir/p/web/www-data/**jspwiki/
>
> For incoming newbies in (2), we have a narrow window when they're
> evaluating a Wiki for their corporate intranets and anything we can do to
> shrink the soap opera between generating a WAR and viewing it from their
> local Tomcat would be a good thing. Here, all we have to say is generate
> the WAR (if they haven't downloaded it anyway from the distribution) and
> dump in their local Tomcat and they can view it at
> http://localhost:8080/JSPWiki and they're done. Couldn't be simpler.
> While a URL of http://localhost:8080/JSPWiki may not work for *all*
> newbies, it's far and away the most common URL for someone prototyping on
> their local machine with Tomcat, sharply reducing the % who will still need
> to configure the jspwiki.properties file.
>
> Also, combining all files that JSPWiki creates into one place
> "myJSPWikiDir" (or whatever you'd want to call it) that Tomcat nicely
> creates in the user's home folder helps them easily see all of JSPWiki's
> internal moving parts while remaining fully comfortable that JSPWiki isn't
> dumping files in system folders that they're going to have trouble finding
> and cleaning out later. It's uncomfortable/unnerving to newcomers to see
> OOTB JSPWiki placing files in the "/p/web/..." of their root system drive
> (a folder system the average user might not have permission to anyway),
> especially for something they're just evaluating locally.
>
> For developers in (3), these above settings work great for me during
> testing and debugging on my local standalone Tomcat, I just need to drop
> the generated WAR in Tomcat each time I do an "ant war" without needing to
> bother to reconfigure the jspwiki.properties file each time. This,
> however, took me quite a while to figure out on my own and I'd like to have
> this setup OOTB for any quick patch submitter without them needing to go
> through similar initial headaches.
>
> Regards,
> Glen
>
>