Re: JSPWiki on Facebook
Hi Dave, it looks nice :-) Thanks for your effort Siegfried Goeschl (not a Facebook user) > On 24 Feb 2016, at 02:40, Dave Koelmeyer <dave.koelme...@davekoelmeyer.co.nz> > wrote: > > Hi All, > > I've now made a Page on Facebook: > > https://www.facebook.com/ApacheJSPWiki/ > > > I've added Janne as a co-admin, and to safeguard against not having > access to the account down the line if any of the core devs would also > like to be added as page admins please drop me a line. > > Cheers, > Dave > > -- > Dave Koelmeyer > http://blog.davekoelmeyer.co.nz > GPG Key ID: 0x238BFF87 >
Re: 2.10.2 and missing i18n resources
Hi folks, any nifty tools to find the missing translations or is visual diff? Cheers, Siegfried Goeschl PS: I can take care of DE > On 28 Jan 2016, at 05:20, Harry Metske <harry.met...@gmail.com> wrote: > > Sure, I will check the nl translation. > And the german one if no one else does > > Rgrds, > Harry > Op 27 jan. 2016 22:56 schreef "Juan Pablo Santos Rodríguez" < > juanpablo.san...@gmail.com>: > >> Hi all, >> >> In order to release 2.10.2, it would be nice to have the i18n entries >> metioned below completed. I was thinking in leaving 2/3 weeks in order to >> let enough time to get as many translations as possible, preferably as a >> patch at https://issues.apache.org/jira/browse/JSPWIKI-925 or directly >> committed into trunk, and then proceed with 2.10.2 release. >> >> sounds reasonable? >> >> >> br, >> juan pablo >> >> >> On Wed, Jan 27, 2016 at 10:50 PM, Juan Pablo Santos Rodríguez (JIRA) < >> j...@apache.org> wrote: >> >>> Juan Pablo Santos Rodríguez created JSPWIKI-925: >>> --- >>> >>> Summary: Missing i18n resources >>> Key: JSPWIKI-925 >>> URL: https://issues.apache.org/jira/browse/JSPWIKI-925 >>> Project: JSPWiki >>> Issue Type: Task >>> Components: Localization >>>Reporter: Juan Pablo Santos Rodríguez >>> Fix For: 2.10.2 >>> >>> >>> Between 2.10.1 and current trunk, a number of i18n literals have been >>> introduced; it would be nice to have them translated for 2.10.2 >>> >>> Specifically: >>> >>> * de >>> ** /CoreResources_de.properties: 1 entry missing >>> ** /templates/default_de.properties: 32 entries missing, 1 outdated >>> >>> * fi >>> ** /CoreResources_fi.properties: 4 entries missing >>> ** /templates/default_fi.properties: 35 entries missing, 1 outdated >>> >>> * fr >>> ** /CoreResources_fr.properties: 1 entry missing >>> ** /templates/default_fr.properties: 32 entries missing, 1 outdated >>> >>> * it >>> ** /CoreResources_it.properties: 1 entry missing >>> ** /templates/default_it.properties: 32 entries missing, 1 outdated >>> >>> * nl >>> ** /templates/default_nl.properties: 2 entries missing >>> >>> * pt_BR >>> ** /CoreResources_pt_BR.properties: 1 entry missing >>> ** /templates/default_pt_BR.properties: 192 entries missing >>> >>> * ru >>> ** /CoreResources_ru.properties: 1 entry missing >>> ** /templates/default_ru.properties: 32 entries missing, 1 outdated >>> >>> * zh_CN >>> ** /CoreResources_zh_CN.properties: 1 entry missing >>> ** /templates/default_zh_CN.properties: 32 entries missing, 1 outdated >>> >>> >>> >>> -- >>> This message was sent by Atlassian JIRA >>> (v6.3.4#6332) >>> >>
Re: Cannot search for bold words
Hi Arend, opening a JIRA would be highly appreciated - the behaviour your experiencing seems weird :-) Thanks in advance Siegfried Goeschl On 29 Jun 2015, at 10:17, Arend v. Reinersdorff ar...@arendvr.com wrote: Correction, turns out I didn't test properly. Sorry. The problem is jspwiki.lucene.analyzer = org.apache.lucene.analysis.de.GermanAnalyzer When I turn that off and delete the Lucene index files, I can find bold words. When I turn it on again and delete the Lucene index files, I cannot find bold words anymore. Siegfried, thanks for pointing me in the direction of search related properties :-) Shall I open a bug for this? Regards, Arend On Mon, Jun 29, 2015 at 9:59 AM, Arend v. Reinersdorff ar...@arendvr.com wrote: Hi Siegfried, thanks a lot for your feedback :-) I tried to reproduce this with clean installs of JSPWiki 2.10.1 and 2.10.0 on my machine, but couldn't. So this looks like a configuration problem on our company wiki. I'll leave it at that for now, except if anyone has an idea which configuration property might cause this. Our company is using the following: JSPWiki v2.10.0 And the following search related settings in jspwiki.properties: jspwiki.searchProvider =LuceneSearchProvider jspwiki.lucene.analyzer = org.apache.lucene.analysis.de.GermanAnalyzer I tried to set the the analyzer to org.apache.lucene.analysis.standard.StandardAnalyzer, but that didn't help. Regards, Arend On Fri, Jun 26, 2015 at 2:34 PM, Siegfried Goeschl siegfried.goes...@it20one.com wrote: Hi Arend, made a quick check (SVN trunk) but I can not reproduce the issue * Added a “__district__” to a page * I can find the term “district” using the LuceneSearchProvider and the “BasicSearchProvider” What version of of JSPWiki and SearchProvider are you using? Thanks in advance Siegfried Goeschl On 26 Jun 2015, at 12:52, Siegfried Goeschl siegfried.goes...@it20one.com wrote: Hi Arend, from looking at your examples I think the markup is accidentally in the underlying Lucene index - in other words * the “__” is part of the indexed token * prefix wildcard search is usually ignored due to performance reasons (it is like a full-table scan for a DB) - that’ a feature Could you open a JIRA - it looks like a bug :) Thanks in advance Siegfried Goeschl On 26 Jun 2015, at 12:33, Arend v. Reinersdorff ar...@arendvr.com wrote: Hi, by chance I noticed that I cannot search in JSPWiki for bold words. If there's text on a Wiki page like: __mysearchterm__ Then the following searches give no result: mysearchterm *mysearchterm__ __mysearchterm mysearchterm~ These searches work: __mysearchterm__ __mysearchterm* __mysearchterm__ __mysearchterm~ I'm using JSPWiki 2.10.0. I can find words in the middle of bold text and italic text: __where is mysearchterm gone__ ''mysearchterm'' Is this a general problem or maybe a problem with my installation? Any other ideas? Regards, Arend
Re: Cannot search for bold words
Hi Arend, made a quick check (SVN trunk) but I can not reproduce the issue * Added a “__district__” to a page * I can find the term “district” using the LuceneSearchProvider and the “BasicSearchProvider” What version of of JSPWiki and SearchProvider are you using? Thanks in advance Siegfried Goeschl On 26 Jun 2015, at 12:52, Siegfried Goeschl siegfried.goes...@it20one.com wrote: Hi Arend, from looking at your examples I think the markup is accidentally in the underlying Lucene index - in other words * the “__” is part of the indexed token * prefix wildcard search is usually ignored due to performance reasons (it is like a full-table scan for a DB) - that’ a feature Could you open a JIRA - it looks like a bug :) Thanks in advance Siegfried Goeschl On 26 Jun 2015, at 12:33, Arend v. Reinersdorff ar...@arendvr.com wrote: Hi, by chance I noticed that I cannot search in JSPWiki for bold words. If there's text on a Wiki page like: __mysearchterm__ Then the following searches give no result: mysearchterm *mysearchterm__ __mysearchterm mysearchterm~ These searches work: __mysearchterm__ __mysearchterm* __mysearchterm__ __mysearchterm~ I'm using JSPWiki 2.10.0. I can find words in the middle of bold text and italic text: __where is mysearchterm gone__ ''mysearchterm'' Is this a general problem or maybe a problem with my installation? Any other ideas? Regards, Arend
Re: Cannot search for bold words
Hi Arend, from looking at your examples I think the markup is accidentally in the underlying Lucene index - in other words * the “__” is part of the indexed token * prefix wildcard search is usually ignored due to performance reasons (it is like a full-table scan for a DB) - that’ a feature Could you open a JIRA - it looks like a bug :) Thanks in advance Siegfried Goeschl On 26 Jun 2015, at 12:33, Arend v. Reinersdorff ar...@arendvr.com wrote: Hi, by chance I noticed that I cannot search in JSPWiki for bold words. If there's text on a Wiki page like: __mysearchterm__ Then the following searches give no result: mysearchterm *mysearchterm__ __mysearchterm mysearchterm~ These searches work: __mysearchterm__ __mysearchterm* __mysearchterm__ __mysearchterm~ I'm using JSPWiki 2.10.0. I can find words in the middle of bold text and italic text: __where is mysearchterm gone__ ''mysearchterm'' Is this a general problem or maybe a problem with my installation? Any other ideas? Regards, Arend
Re: JSPWiki no results from LuceneSearchProvider
Hi Brian, a wild guess assuming that you first started JSPWiki and later copied the wiki files * can you stop JSPWiki * delete the /var/lib/jspwiki/workDir/lucene directory * start JSPWiki again * check if the “lucene” directory contains more bigger files * check if the search is working again JSPWiki will re-index the existing pages if no “lucent” directory is found but otherwise assume that all changes are done though the JSPWiki server Cheers, Siegfried Goeschl On 06 Feb 2015, at 20:14, Brian Buchanan brian.bucha...@wescoair.com wrote: Hi, Thanks for the help. I'm using the packaged version from Ubuntu Universe. The package is 2.8.0-5 and the LeftMenu footer says 2.8.0-beta-21. On this same server I just tried a parallel install with the 2.10.1 WAR file, with the same results. This Ubuntu server has a bit of history, it started as a 13.10 and I originally installed Tomcat7 (I chose the installer option to make it a Tomcat Java Server) before I realized I had to use Tomcat6 with the package version of JSPWiki. After the install I copied over the Wikifiles, chown'ed, and created a template with a new logo. I'm able to add, edit and delete Wiki Pages. (I can't change My Prefs/Profile/E-mail address, I get an error about permission denied to /etc/jspwiki/userdatabase.xml.new ) The workDir/lucene directory (I even tried moving it out of /tmp) contains two small files: tech@hermes:/var/lib/jspwiki/workDir/lucene$ ls -lA total 8 -rw-r--r-- 1 tomcat6 tomcat6 32 Feb 6 12:20 segments_1 -rw-r--r-- 1 tomcat6 tomcat6 20 Feb 6 12:20 segments.gen My Config (with workDir set back to /tmp): tech@hermes:~$ grep -v ^$\|^\s*\# /etc/jspwiki/jspwiki.properties jspwiki.applicationName = JSPWiki jspwiki.pageProvider = VersioningFileProvider jspwiki.usePageCache = true jspwiki.fileSystemProvider.pageDir = /var/lib/jspwiki/default/en jspwiki.workDir = /tmp jspwiki.attachmentProvider = BasicAttachmentProvider jspwiki.basicAttachmentProvider.storageDir = /var/lib/jspwiki/default/en jspwiki.attachment.forbidden=*.jsp jspwiki.diffProvider = TraditionalDiffProvider jspwiki.baseURL = http://hermes.interfast.ca/JSPWiki/ jspwiki.referenceStyle=relative jspwiki.encoding = UTF-8 jspwiki.translatorReader.allowHTML = false jspwiki.breakTitleWithSpaces = false jspwiki.translatorReader.matchEnglishPlurals = true jspwiki.translatorReader.camelCaseLinks = false jspwiki.templateDir = interfast jspwiki.translatorReader.useOutlinkImage = true jspwiki.lockExpiryTime = 60 jspwiki.searchProvider = LuceneSearchProvider jspwiki.specialPage.CreateGroup = NewGroup.jsp jspwiki.specialPage.FindPage = Search.jsp jspwiki.specialPage.Login = Login.jsp jspwiki.specialPage.NewGroup = NewGroup.jsp jspwiki.specialPage.UserPreferences = UserPreferences.jsp jspwiki.plugin.searchPath = jspwiki.loginModule.class = com.ecyrd.jspwiki.auth.login.UserDatabaseLoginModule jspwiki.authorizer = com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer jspwiki.groupdatabase = com.ecyrd.jspwiki.auth.authorize.XMLGroupDatabase jspwiki.userdatabase = com.ecyrd.jspwiki.auth.user.XMLUserDatabase jspwiki.xmlUserDatabaseFile = /etc/jspwiki/userdatabase.xml jspwiki.aclManager = com.ecyrd.jspwiki.auth.acl.DefaultAclManager jspwiki.interWikiRef.JSPWiki = http://www.jspwiki.org/Wiki.jsp?page=%s jspwiki.interWikiRef.Edit = Edit.jsp?page=%s jspwiki.interWikiRef.WikiWikiWeb = http://c2.com/cgi/wiki?%s jspwiki.interWikiRef.TWiki = http://twiki.org/cgi-bin/view/TWiki/%s jspwiki.interWikiRef.MeatballWiki = http://usemod.com/cgi-bin/mb.pl?%s jspwiki.interWikiRef.Wikipedia = http://www.wikipedia.com/wiki/%s jspwiki.interWikiRef.Google = http://www.google.com/search?q=%s jspwiki.interWikiRef.Doc = http://doc.jspwiki.org/2.2/Wiki.jsp?page=%s jspwiki.rss.generate = true jspwiki.rss.fileName = rss.rdf jspwiki.rss.interval = 3600 jspwiki.rss.channelDescription = Oh poor me, my owner has not set \ a channel description at all. \ Pity me. jspwiki.rss.channelLanguage = en-us jspwiki.userdatabase.datasource=jdbc/UserDatabase jspwiki.userdatabase.table=users jspwiki.userdatabase.uid=uid jspwiki.userdatabase.email=email jspwiki.userdatabase.fullName=full_name jspwiki.userdatabase.loginName=login_name jspwiki.userdatabase.password=password jspwiki.userdatabase.wikiName=wiki_name jspwiki.userdatabase.created=created jspwiki.userdatabase.modified=modified jspwiki.userdatabase.lockExpiry=lock_expiry jspwiki.userdatabase.attributes=attributes jspwiki.userdatabase.roleTable=roles jspwiki.userdatabase.role=role jspwiki.groupdatabase.datasource=jdbc/GroupDatabase jspwiki.groupdatabase.table=groups jspwiki.groupdatabase.membertable=group_members jspwiki.groupdatabase.created=created jspwiki.groupdatabase.creator=creator jspwiki.groupdatabase.name=name jspwiki.groupdatabase.member=member jspwiki.groupdatabase.modified
Re: JSPWiki no results from LuceneSearchProvider
Hi Brian, a few thoughts along the line * are you using the old version (from your Windows Server) or a newer released version? * does the log file give any hints (errors, directories, file permissions, what so ever)? * how does your configuration file look like? Cheers, Siegfried Goeschl On 06 Feb 2015, at 18:21, Brian Buchanan brian.bucha...@wescoair.com wrote: Hello, I migrated from an old Windows Sever running Tomcat5 to a new Ubuntu 14.04 server running Tomcat6 and I'm not getting any search results when I use the default LuceneSearchProvider. When I tested switching to BasicSearchProvider, I do get search results. Is there something missing from the Server install of Ubuntu that Lucene needs to return results? Brian This email may contain material that is confidential and/or privileged and is for the sole use of its intended recipient. All pricing information contained in this email or any attachment to this email is confidential and proprietary information. Any review, reliance or distribution by others, without express permission, is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Re: Error when building JSPWiki
Hi folks,
actually the following snippet is defined in jspwiki-war/pom.xml
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemPropertyVariables
java.io.tmpdir${project.build.directory}/java.io.tmpdir
/systemPropertyVariables
/configuration
/plugin
In other words
* the temp directory should be “./target”
* the temp directory can be supplied on the command line, e.g.
“-Djava.io.tmpdir=/tmp/jspwiki”
Cheers,
Siegfried Goeschl
On 08 Jul 2014, at 12:24, Juan Pablo Santos Rodríguez
juanpablo.san...@gmail.com wrote:
Hi Dave,
yes, tests should run ok on a fresh install. Looking at the source, the
test is trying to create the directory
${java.io.tmpdir.}/non-existent-directory and check that it has been able
to create it. Would you mind checking if you have rw on that folder?
Looking at AbstractFileProvider:110, seems that the test is failing due to
being unable to create that folder. Maybe we should change that test to
look into ./target/non-existent-directory + System.currentTimeMillis()
instead, WDYT?
br,
juan pablo
On Tue, Jul 8, 2014 at 12:02 PM, Dave Koelmeyer
dave.koelme...@davekoelmeyer.co.nz wrote:
On 08/07/14 20:51, Brian Burch wrote:
On 08/07/14 08:35, Juan Pablo Santos Rodríguez wrote:
within that directory you'll see a bunch of txt and xml files, one of
each
type for every junit file; the xml ones have the same information as the
txt ones, but they're in different format, so they can be consumed by
other
tools.
As for the txt files, you'll see most of them weight about 1k, those are
files corresponding to tests which have ended successfully. You'll surely
have on txt file weighting a little more (say 5 or 6k, it depends on the
test file), which will contain the failing test. It should also appear on
your console, somewhat above the build failure message
grep -lir failed /home/dave/jspwiki/jspwiki-
war/target/surefire-reports/*.txt
ought to identify the txt files containing the test that failed. You only
need to look at that one.
Awesome, thanks all. The offending test appears to be:
/home/dave/jspwiki/jspwiki-war/target/surefire-reports/org.apache.wiki.
WikiEngineTest.txt
And the contents:
---
Test set: org.apache.wiki.WikiEngineTest
---
Tests run: 40, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.894 sec
FAILURE! - in org.apache.wiki.WikiEngineTest
testNonExistentDirectory(org.apache.wiki.WikiEngineTest) Time elapsed:
0.025 sec ERROR!
org.apache.wiki.api.exceptions.WikiException: JSPWiki: Unable to load and
setup properties from jspwiki.properties. Failed to start; please check log
files for bett
er information.
at org.apache.wiki.providers.AbstractFileProvider.initialize(
AbstractFileProvider.java:110)
at org.apache.wiki.providers.CachingProvider.initialize(
CachingProvider.java:146)
at org.apache.wiki.PageManager.init(PageManager.java:190)
at sun.reflect.GeneratedConstructorAccessor12.newInstance(Unknown
Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.apache.wiki.util.ClassUtil.getMappedObject(ClassUtil.java:359)
at org.apache.wiki.WikiEngine.initialize(WikiEngine.java:563)
at org.apache.wiki.WikiEngine.init(WikiEngine.java:430)
at org.apache.wiki.TestEngine.init(TestEngine.java:127)
at org.apache.wiki.WikiEngineTest.testNonExistentDirectory(
WikiEngineTest.java:98)
Is there some manual configuration I need to perform somewhere, or is
running 'mvn package' supposed to just work?
Cheers,
Dave
JSPWiki Portable comes now with Max OS launcher for Oracle JDK ...
Hi folks, if anyone would like to play with it - the previous launcher using Apple JDK 1.6 are now mostly retired (is now shipped as woas-apple-jdk.app”) http://people.apache.org/~sgoeschl/download/wikionastick/jspwiki-portable-2.10.1-SNAPSHOT-woas.tar.gz To get it running * Unpack the tar.gz * Start the “woas.app” application using finder Feedback highly appreciated, Siegfried Goeschl
Slides from ApacheCon 2014 ...
Hi folks, you can download the slides from http://people.apache.org/~sgoeschl/presentations/apachecon-2014 Might be handy to present JSPWiki or serves as starting point for your presentation :-) Cheers, Siegfried Goeschl
Re: Current progress on jspwiki-portable (aka Wiki On A Stick)
Hi Juan Pablo, thanks for your time 1) ad inlined images - you refer to jspwiki.translatorReader.inlinePattern.X? Assuming that this should be the default behaviour for JSPWiki we should add this to the jspwiki.properties used for the default configuration - I’m just picking up the existing default configuration and overwrite a few settings 2) patches - for 3.1 I need to test my patch but I haven’t looked into 3.2 in more details 3) ad “private” “public” - that is my use case that i have approx. 10 wikis deployed - for each of my customers/project I create a JSPWiki web app using the a shared library approach. And their are no credentials assigned to the wiki spaces 4) add URL - fixed Cheers, Siegfried Goeschl On 03 Mar 2014, at 20:04, Juan Pablo Santos Rodríguez juanpablo.san...@gmail.com wrote: Hi Siegfried, tested linux exec under cygwin and looks really good! As there are public and private spaces, are there any default users/admins, or are they just two given names? I also noticed that only *.png images are inlined (default value), could that value be set to *.png, *.jpg, *gif ? Regarding the patches at 3.1/3.2, are you providing them? (just to look into them, most probably next week, or wait 'til woas is ready to be merged into trunk) Only found a minor nit, the JSPWiki hyperlink at http://localhost:9627/ is missing a colon, i.e. it shows http//jspwiki.a.o instead of http://jspwiki.a.o Other than that, it rocks :-) br, juan pablo On Sun, Mar 2, 2014 at 11:08 PM, Siegfried Goeschl sgoes...@gmx.at wrote: Hi folks, many hours later I’m an expert for Mac OS Java 6 7 launchers - I learned more things that I wanted to know ;-) Anyone with a Mac OS X or Linux wants to test and download http://people.apache.org/~sgoeschl/download/wikionastick/jspwiki-portable-2.10.1-SNAPSHOT-woas.tar.gz * It contains a “woas.app which should launch cleanly assuming that Apple JDK 1.6 is on the box * It contains a “woas.sh” which should launch cleanly on a Unix/Linux box assuming that a JDK is found * open http://localhost:9627 and forgive my HTML/CSS skills * you should have two wiki spaces - “private “public” I pushed the stuff to https://github.com/sgoeschl/jspwiki-on-a-stick/tree/master/jspwiki-portablebut it is not in a state to be merged with the JSPWiki SVN trunk Feedback appreciated Siegfried Goschl On 02 Mar 2014, at 11:21, Siegfried Goeschl siegfried.goes...@willhaben.at wrote: Hi folks, I started to work last weekend and it was a lot harder than expected :) 1. Native Launchers = Native launchers for Mac OS are difficult nowadays due to the fact the Apple is not longer shipping Java build tools. My current tool chain is stuck to Apple’s JDK 1.6 2. Jetty versus Tomcat = After some frustration with Jetty I kicked it out and replaces it with Tomcat 7.0.52 * Jetty is getting bigger and bigger with every major release (the same is true for me) and the small memory foot print was my initial motivation to stick with Jetty * I had some strange class loader issues which is fine since I did strange things but I feel more at home with Tomcat * Adding GZIP compression requires tinkering with web.xml 3. Portable Wiki Setup = I tried to put all libraries to $CATALINA_HOME/lib and simulate multiple wikis using a light-weight web archive - this is a bit dangerous but it worked for 2.9x. It stopped workig with 2.10 due to * class loader issued in PropertyReader * class loader issues with page caching 3.1 Ad PropertyReader —— propertyStream = PropertyReader.class.getResourceAsStream( CUSTOM_JSPWIKI_CONFIG ); tries to read the property file from the same class loader which fails if the libs are placed on $CATALINA_HOME/lib whereas the following statement uses the class loader of the deployed web app propertyStream = context.getResourceAsStream(/WEB-INF/classes + CUSTOM_JSPWIKI_CONFIG); I prepare a patch for it 3.2 Ad Page Caching —— Found a similar issue here - due to my setup there is ONLY ONE cache and as cache key the page name is used I have the following options * jspwiki.usePageCache=false is a work around * use the context name or appId as additional key for the cache The current state * I can build a ready-to-use JSP Wiki using Tomcat using Maven Ant plugin * I setup two pre-configured wiki instances * Eating my own dog food - migrate all my existing wiki to 2.10 Cheers, Siegfried Goeschl
Re: Current progress on jspwiki-portable (aka Wiki On A Stick)
Hi folks, many hours later I’m an expert for Mac OS Java 6 7 launchers - I learned more things that I wanted to know ;-) Anyone with a Mac OS X or Linux wants to test and download http://people.apache.org/~sgoeschl/download/wikionastick/jspwiki-portable-2.10.1-SNAPSHOT-woas.tar.gz * It contains a “woas.app which should launch cleanly assuming that Apple JDK 1.6 is on the box * It contains a “woas.sh” which should launch cleanly on a Unix/Linux box assuming that a JDK is found * open http://localhost:9627 and forgive my HTML/CSS skills * you should have two wiki spaces - “private “public” I pushed the stuff to https://github.com/sgoeschl/jspwiki-on-a-stick/tree/master/jspwiki-portable but it is not in a state to be merged with the JSPWiki SVN trunk Feedback appreciated Siegfried Goschl On 02 Mar 2014, at 11:21, Siegfried Goeschl siegfried.goes...@willhaben.at wrote: Hi folks, I started to work last weekend and it was a lot harder than expected :) 1. Native Launchers = Native launchers for Mac OS are difficult nowadays due to the fact the Apple is not longer shipping Java build tools. My current tool chain is stuck to Apple’s JDK 1.6 2. Jetty versus Tomcat = After some frustration with Jetty I kicked it out and replaces it with Tomcat 7.0.52 * Jetty is getting bigger and bigger with every major release (the same is true for me) and the small memory foot print was my initial motivation to stick with Jetty * I had some strange class loader issues which is fine since I did strange things but I feel more at home with Tomcat * Adding GZIP compression requires tinkering with web.xml 3. Portable Wiki Setup = I tried to put all libraries to $CATALINA_HOME/lib and simulate multiple wikis using a light-weight web archive - this is a bit dangerous but it worked for 2.9x. It stopped workig with 2.10 due to * class loader issued in PropertyReader * class loader issues with page caching 3.1 Ad PropertyReader —— propertyStream = PropertyReader.class.getResourceAsStream( CUSTOM_JSPWIKI_CONFIG ); tries to read the property file from the same class loader which fails if the libs are placed on $CATALINA_HOME/lib whereas the following statement uses the class loader of the deployed web app propertyStream = context.getResourceAsStream(/WEB-INF/classes + CUSTOM_JSPWIKI_CONFIG); I prepare a patch for it 3.2 Ad Page Caching —— Found a similar issue here - due to my setup there is ONLY ONE cache and as cache key the page name is used I have the following options * jspwiki.usePageCache=false is a work around * use the context name or appId as additional key for the cache The current state * I can build a ready-to-use JSP Wiki using Tomcat using Maven Ant plugin * I setup two pre-configured wiki instances * Eating my own dog food - migrate all my existing wiki to 2.10 Cheers, Siegfried Goeschl
Re: Building WOAS (was Re: JSPWiki Support for Multiple Wikis and Hosting Solutions)
Hi Dave, I think the best is to minimize build dependencies - I will change the ./extensions/woas/build.xml so that it builds JSPWiki as very first task * no need to tinker with ./build.xml * woas would be build directly from ./extensions/woas * I will push the required changes next week since I'm already late with my daily work :-( Furthermore I should be able to use jetty-7 (in a perfect world the same version being used as in JSPWiki) but that also needs some tinkering Thanks in advance Siegfried Goschl On 17.10.13 14:38, Dave Koelmeyer wrote: On 17/10/13 06:59 PM, Siegfried Goeschl wrote: Looks like a mess with the buid.xml - i overwrite the jspwiki ./build.xml file which allows calling the woas build.xml - i have a separate woas/buid.xml wich is invoked by ./build.xml I think you are missing my ./build.xml Hi Siegfried, Thanks, - I managed to get this built and it seems to work well. However there were a couple of deviations from the README which I had to make. First, the WOAS build will fail at the point the JSPWiki.war file is to be unpacked (line 68 of ./extensions/woas/build.xml). This implied that not only does JSPWiki source code have to be checked out, but it also has to be first built (I simply ran ant war in the checkout directory) before building WOAS - is this correct? If so perhaps this should be noted in the README. Second, the README makes reference to overwriting the build.xml file contained within the checkout directory with ./extensions/woas/build.xml. However, after first running ant war on the checkout directory to build JSPWiki, I then went to ./extensions/woas/ and executed ant '-Dbuild.properties=woas.properties -Djspwiki.test.skip=true woas-clean woas-dist'. WOAS built fine without errors. So I'm a little confused in which order copying/overwriting build.xml files should take place. There is also the presence of a third build.xml file (along with a woas.properties file) within the extracted jspwiki-on-a-stick-master directory which contains the extensions sub-directory - I don't know how or if these two files are supposed to be used, as the README only makes reference to using the extensions directory from the extracted WOAS zip file. Long story short, I created some self-documentation (in JSPWiki, naturally) which details what worked for men - do you see any problems with this? http://ubuntuone.com/6gXroBn1roKD97zd20enEb Last, WOAS will throw an error when navigating to the User Preferences page - I can raise this as an issue in Github if you like? Cheers, Dave Am 16.10.2013 um 10:14 schrieb Dave Koelmeyerdave.koelme...@davekoelmeyer.co.nz: On 15/10/13 09:20 PM, Dave Koelmeyer wrote: On 15/10/13 06:36 PM, Siegfried Goeschl wrote: Hi Dave, upgraded to JSPWiki 2.9.1 and it should work for Linux and Mac OS X - not sure for Windows native launcher since I don't use it Hi Siegfried, Just trying to build WOAS on an Ubuntu 12.04 system. When attempting to run the ant command I get the following build error: $ ant -Dbuild.properties=woas.properties -Djspwiki.test.skip=true woas-clean woas-dist Buildfile: /home/dave/JSPWiki/jspwiki_2_9_1_incubating_rc2/build.xml BUILD FAILED Target woas-clean does not exist in the project woas. Any idea what I'm doing wrong? Cheers, Dave -- Dave Koelmeyer http://blog.davekoelmeyer.co.nz
Re: Building WOAS (was Re: JSPWiki Support for Multiple Wikis and Hosting Solutions)
Hi Juan Pablo, I think it would be easier for now to stick to extensions/woas a M2 module since it allows to test the Ant M2 build using the GitHub repo Some thoughts along the line * I can contribute with the M2 build but not this week * If that works out we need to check licensing stuff - e.g. launch4j-maven-plugin is GPLed whereas launch4j is partly MIT and BSD license * Not sure about MacOS application skeleton file in woas/resources/macos/ * Looking at the licensing questions regarding installer we might consider to get a free license of a commercial tool - suggestions out there? I' using a commercial license of install4j (and there are actually good reasons to do that) Thanks in advance Siegfried Goeschl On 22.10.13 21:19, Juan Pablo Santos Rodríguez wrote: Hi, was doing some tests to see if we could add up another module to the SVN, capable of mimicking WOAS, but I'm thinking I'm hit by http://sourceforge.net/p/launch4j/bugs/66/ would anyone mind doing a quick test to see if it's me or the previous bug? launch4j log isn't specially descriptive.. steps: 1.- on trunk, create a new folder, jspwiki-portable, next to jspwiki-war and jspwiki-it-tests 2.- on trunk, edit base pom.xml and add modulejspwiki-portable/module on line 57 3.- on trunk/jspwiki-portable create src/main/resources/icon and place there jspwiki.ico included in $WOAS/extensions/woas/resources/windows 4.- on trunk/jspwiki-portable create pom.xml and add the contents from https://paste.apache.org/ecrN 5.- on trunk, mvn clean install 6.- that should generate trunk/jspwiki-portable/target/jspwiki-portable.exe (right as a POC, only windows executable) I haven't committed this to trunk yet b/c I'm not sure if the generated executable is well-formed.. As additional information regarding the module, it uses launch4j-maven-plugin 1.5.2, [#1] which seems to use launchj 3.0.2 (as per github comments on [#1]/tree/master/src/main). The jar generated by tomcat7-maven-plugin is executable via java -jar target/jspwiki-portable-2.10.0-SNAPSHOT.jar, which enables a working http://localhost:8080/JSPWiki thanks br, juan pablo [#1]: https://github.com/lukaszlenart/launch4j-maven-plugin On Thu, Oct 17, 2013 at 2:38 PM, Dave Koelmeyer dave.koelme...@davekoelmeyer.co.nz mailto:dave.koelme...@davekoelmeyer.co.nz wrote: On 17/10/13 06:59 PM, Siegfried Goeschl wrote: Looks like a mess with the buid.xml - i overwrite the jspwiki ./build.xml file which allows calling the woas build.xml - i have a separate woas/buid.xml wich is invoked by ./build.xml I think you are missing my ./build.xml Hi Siegfried, Thanks, - I managed to get this built and it seems to work well. However there were a couple of deviations from the README which I had to make. First, the WOAS build will fail at the point the JSPWiki.war file is to be unpacked (line 68 of ./extensions/woas/build.xml). This implied that not only does JSPWiki source code have to be checked out, but it also has to be first built (I simply ran ant war in the checkout directory) before building WOAS - is this correct? If so perhaps this should be noted in the README. Second, the README makes reference to overwriting the build.xml file contained within the checkout directory with ./extensions/woas/build.xml. However, after first running ant war on the checkout directory to build JSPWiki, I then went to ./extensions/woas/ and executed ant '-Dbuild.properties=woas.properties -Djspwiki.test.skip=true woas-clean woas-dist'. WOAS built fine without errors. So I'm a little confused in which order copying/overwriting build.xml files should take place. There is also the presence of a third build.xml file (along with a woas.properties file) within the extracted jspwiki-on-a-stick-master directory which contains the extensions sub-directory - I don't know how or if these two files are supposed to be used, as the README only makes reference to using the extensions directory from the extracted WOAS zip file. Long story short, I created some self-documentation (in JSPWiki, naturally) which details what worked for men - do you see any problems with this? http://ubuntuone.com/6gXroBn1roKD97zd20enEb Last, WOAS will throw an error when navigating to the User Preferences page - I can raise this as an issue in Github if you like? Cheers, Dave Am 16.10.2013 um 10:14 schrieb Dave Koelmeyer dave.koelme...@davekoelmeyer.co.nz mailto:dave.koelme...@davekoelmeyer.co.nz: On 15/10/13 09:20 PM, Dave Koelmeyer wrote: On 15/10/13 06:36 PM, Siegfried Goeschl wrote: Hi Dave, upgraded to JSPWiki 2.9.1 and it should work for Linux and Mac OS X - not sure for Windows native
