Re: [VOTE] Move to github as the primary repo
+1 Thanks in advance, Siegfried Goeschl > On 29.11.2017, at 00:33, Juan Pablo Santos Rodríguez > wrote: > > Hi all, > > As noted else-thread, we're currently using ASF's git repo as the canonical > repo with a read-only copy at github, but infra offers from a while back > now the opposite possibility: work with github repo, which sends the > commits automatically to the ASF's repo, which gets then read-only. It > woukd treat Github as the canonical source (a copy on ASF's repo would > still be made), which allows the PRs and issues to be a bit more convenient > (there are still some things not supported due to the Github's coarse > permission structure). It would be required all committers to use Github's > 2FA [ > https://help.github.com/articles/providing-your-2fa-authentication-code/] > > This is the formal VOTE required by infra to set github as the primary repo > for Apache JSPWiki, and as such subject to the usual voting guidelines: it > will be open for at least 72 hours, everybody is encouraged to vote, > although only PMC ones are binding. > > [+1] yes, move to github as the primary repo > [0] don't mind > [-1] we are fine as it is now > > > best regards, > juan pablo
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 > 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: Open Discussion - How to increasing JSPWiki publicity ...
Hi folks, regarding Personal Distributed Wiki - I’m syncing my JSPWiki contents over DropBox Cheers, Siegfried Goeschl > On 12.02.2016, at 08:49, Derek Hohls wrote: > > Adrien > > Excellent points - but I still do not think a wiki is a tool that can/should > be installed locally for "casual" end-users (maybe my biases from 20+ years > in IT are showing here). Casual end users can - possibly - be trained to > contribute towards a shared wiki; but I am doubtful that they will really be > able to handle / manage / appreciate a locally installed version all on their > own. > > My own bias, because I work on multiple machines in different locations, all > with good network access, is towards hosted solutions; for example - > bitbucket repo can be used as just a wiki (with different syntax options if > desired) - public or private - with all of the revision options that that > entails (plus you can clone it to work locally & then push back changes if > really needed). > > We all have different needs - so I understand that in some situations a > "personal" wiki is desirable. > > Derek > >>>> Adrien Beau 02/10/16 6:30 PM >>> > Derek Hohls wrote: >> >> I am very curious as to why people would even want to install a wiki on > their own machines (Windows or otherwise). > > You get a note-taking tool with text formatting, file attachments, > hyperlinks between notes, a full-text search engine, and no dependency on > network connectivity. You also get to keep past revisions, and can easily > backup the data (or even read it if the software fails): it's just > plain-text files. > > I've used JSPWiki this way for a few years (and was using MoinMoin in a > similar way before). Network connectivity was a major factor in choosing to > use a local instance: data connections in high-speed trains were quite > flaky, and clients often had restrictions on which web sites could be > accessed. Not storing client data on a remote server was also seen as a > bonus; the data is encrypted on my laptop. Network latency is also a bit > irritating when you've gotten used to a local server. > > The full-text search engine was not much of a criteria when I selected > JSPWiki, but it turned out to be much more useful than I envisioned, > especially on a local instance (no latency, very fast results). > > By the way, I selected JSPWiki based on its syntax. I wanted to use a wiki > that had a syntax close to what CollabNet TeamForge has, and it turns out > JSPWiki is the only one that matches (to the point that I wonder if > CollabNet forked JSPWiki a while ago). > > On Wed, Feb 10, 2016 at 1:26 PM, Derek Hohls wrote: > >> I am very curious as to why people would even want to install a wiki on >> their own machines (Windows or otherwise). >> >> To me, the main benefit of a wiki is that it is a shared repository of >> knowledge to which everyone has access. Such a wiki would be installed and >> maintained by the IT support team (or local guru, perhaps) on a server. >> Access is then as simple as "open your browser"! No barrier to entry at all. >> >> I think that for private note taking people are already using tools like >> Evernote or OneNote and I cannot see a "local" wiki replacing them. >> >>>>> Jason Morris 02/08/16 10:22 AM >>> >> >> I tried (without success) to get people using JSPWiki internally in our >> faculty (Agriculture and Environment at the University of Sydney). At >> first, the majority were all gung-ho about using a wiki.. that was no >> problem. The barrier to entry was that they expected it to install like >> installing MS Word or something. Just a "one-shot and it just works" >> experience. As soon as I explained that they had to first install a servlet >> container (what's a servlet??!?!!) and fill out all this configuration >> stuff, they quickly lost interest. >> >> -- >> This message is subject to the CSIR's copyright terms and conditions, >> e-mail legal notice, and implemented Open Document Format (ODF) standard. >> The full disclaimer details can be found at >> http://www.csir.co.za/disclaimer.html. >> >> >> This message has been scanned for viruses and dangerous content by >> *MailScanner* <http://www.mailscanner.info/>, >> and is believed to be clean. >> >> >> Please consider the environment before printing this email. >> >> > > -- > This message is subject to the CSIR's copyright terms and conditions, e-mail > legal notice, and implemente
Re: Open Discussion - How to increasing JSPWiki publicity ...
Hi folks, there is some “multiple instance support” which can also work around the “no department support” - I’m running for years 10 wikis on a single Tomcat instance :-) On my wish list * Markdown support * Ease of embedding images * Mobile friendliness Cheers, Siegfried Goeschl PS: Maybe there is a JSPWiki presentation at ApacheCon North America 2016 :-) > On 06 Feb 2016, at 14:06, Jim Willeke wrote: > > I have been using JSPWiki for more than 10 years and I too think it has a > lot going for it. > > I agree with Dave. We need to answer "who is JSPWiki for?" > And what does Features does JSPWiki have that is not already present within > the market? > > These need to be one answered in one paragraph. > > I not see JSPWiki competing in a corporate environment: > > - Little (if any) support - SHOW STOPPER > - No Department Support (cannot be separated into different namespaces) > - SHOW STOPPER > - NOT mobile friendly > - Limited "pre-built" plugins to integrate with other Applications > (think source control or issue tracking) > - Limited Administration tools > - Need more GUI interfaces (like adding a photo or Excel embedded into > page) > > Personal Gripes > > - No markdown support > - No multiple instance support (Well at least poor) > > It is listed on some comparison sites > <http://www.wikimatrix.org/show/JSPWiki>, but not sure how current things > are. > > From a technical standpoint, of course, almost anything is possible. > From a market penetration standpoint, it is a different story. > > -jim > > > > > > > -- > -jim > Jim Willeke > > On Sat, Feb 6, 2016 at 1:13 AM, Dave Koelmeyer < > dave.koelme...@davekoelmeyer.co.nz> wrote: > >> On 30/11/15 11:21, Paul Uszak wrote: >>> I think that one of the initial points people should address, prior to >>> launching a publicity campaign, is: who is JSPWiki for? It's pretty >>> important to identify the market segment that efforts will then be made >>> towards. We could all just talk about it a lot, but it's more efficient >> if >>> someone actually has an idea as to what is to be achieved, for whom. >> >> Fair point, but some of this is already covered right on >> http://jspwiki.apache.org/ and >> http://www.ecyrd.com/JSPWiki/wiki/JSPWikiFeatures. Any organisation >> looking for the particular features listed there would be in the target >> market for JSPWiki, for instance. >> >>> From a personal perspective as a user, it appears that JSPWiki is only >>> suitable for a highly technical computer user. I use it because it meets >>> certain nerdy requirements. Most casual users don't know what a server >> is. >> >> I don't follow your logic at all. I don't think any organisation >> interested in choosing JSPWiki to host instead of say Confluence or >> MediaWiki expects their end users to install and run the product >> themselves (comparisons to a desktop app such as Thunderbird are >> completely apples to oranges). >> >>> Dave, you can get an impression of what I'm talking about by comparing >> the >>> ease of installation of Thunderbird to that of JSPWiki. Therefore, if >> you >>> think that we should be targeting developers /programmers, I would >> suggest >>> that perhaps those who want JSPWiki, know or can readily find out about >>> JSPWiki. There might be an inherent danger of diminishing returns by >>> publicising a highly technical product into the mainstream segment. >>> Marketing 101 tells us not to advertise AR15s during the Super Bowl half >>> time slot. >> >> I'm referring to volunteering free time and effort with a fair amount of >> existing expertise to a small project which suffers from a lack of >> visibility (the JSPWiki page even got yanked from Wikipedia due to a >> lack of notability) – not the Super Bowl. >> >> I use JSPWiki for a variety of product and project documentation tasks, >> and it largely excels at both. However, the legacy UI is getting long in >> the tooth in terms of ease-of-use, and the problem with HADDOCK as far >> as I am concerned is there are just not enough folks using it and >> providing feedback. It's a great start but is not there yet for >> full-time use (and I feel like a lone voice on JIRA). Hence why I'm in >> strong agreement with the original author of this post, and why I'd >> really like someone from the project to jump in here with some points of >> view. >>
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 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: 2.10.1 setup problems
Hi Eric, not sure if I can help you solving all problems * “com.ecyrd.jspwiki" was renamed to “org.apache.wiki” in the 2.8 release * Is it possible that mix & match a current JSPWIki with old JSP pages? * Are you just interested to get a JSPWiki running? We have a ready-to-use JSPWiki distribution Cheers, Siegfried Goeschl > On 14 Aug 2015, at 17:28, Eric Ladner wrote: > > I've had a bear of a time getting 2.10.1 set up. I started with a fresh > install on Tomcat 7 and got all kinds of logging problems > (slf4j-log4j12-1.7.2.jar not found, even though it's in the > webapp/JSPWiki/lib) > > So, then I dropped back to Tomcat 6. No problems with the install, except > none of the plugins work (jspwiki.log reports > "org.apache.wiki.parser.JSPWikiMarkupParser - Failed to insert plugin: > Could not find plugin com.ecyrd.jspwiki.plugin.RecentChangesPlugin)" > > Noting the old "com.ecyrd" I tried adding "jspwiki.plugin.searchPath = > org.apache.wiki.plugin" to the jspwiki-cusom.properties file but that > didn't help. > > Any idea on why this is being so difficult? > > Thanks, > > Eric
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 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 > 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 >>> 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 > 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 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 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 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
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 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: portable JSPwiki -PROBLEM PROBABLY SOLVED
Hi Bastiaan, difficult to say but * JAVA_HOME points to the installation directory and not to the “bin” folder * The “bin” folder is something you add to the PATH, e.g. “SET PATH=%PATH%;%JAVA_HOME%\bin;” * I give it a try on a Windows box tomorrow and document the steps (since I’m not using Windows it is a bit difficult to troubleshoot) So stay tuned Siegfried Goeschl > On 30 Nov 2014, at 18:51, Geelhoed, B (thorax) wrote: > > > > Dear Siegfried , > > Thank you for this suggestion (I am from now on going to use this newer > version). > > About my previous problem (woas-2.9.1.1-bin), however, it was not really > solved, I only thought it was solved. > > Here is what I did (woas-2.9.1.1-bin): > > 1A. I unzipped the files and put them on my memory stick. > 2A. In start (configuration file) I removed the "#" in front of the line: >-Dorg.apache.jasper.compiler.disablejsr199=true > 3A. I then double clicked on the file start.jar [this is probably not as it > is supposed] > 4A. Then, I double clicked on woas (Internet shortcut) > 5A. The browser was opened as a result of the above step. > 6A. In the browser I clicked on the hyperlink "Your Wiki-On-A-Stick" > 7A. The result of the above step was something that seemed to be the wiki, > fully functioning. > --> But I later wanted to edit a page (clicking on edit) and there came an > error: > > HTTP ERROR 500 > Problem accessing /wiki/Edit.jsp. Reason: > Server Error > Caused by: > org.apache.jasper.JasperException: PWC6033: Error in Javac compilation for > JSP > > Probably the installation of woas-2.9.1.1-bin is more complicated than my > above attempt. > > I therefore now want to try the newer version > jspwiki-portable-2.10.1-SNAPSHOT-woas.tar.gz. > > I did the following steps: > > 1B. I downloaded jspwiki-portable-2.10.1-SNAPSHOT-woas.tar.gz > 2B. Unzipped the files on my memory stick > 3B. To take into your account of the spaces in the folder name of Java, I > wanted to make sure this will not lead to an error so I re-installed Java jdk > and jre and put them respectively in the folders: > > C:\JAVA64\jdk > > and > > C:\JAVA64\jre > > (in these folders the relevant java applications are in bin folders) > 4B. In the command prompt I typed: > > Set JRE_HOME=C:\JAVA64\jre\bin > > and > > Set JAVA_HOME=C:\JAVA64\jdk\bin > > 5B. In > > > G:\jspwiki-portable-2.10.1-SNAPSHOT-woas.tar\jspwiki-portable-2.10.1-SNAPSHOT-woas\jspwiki-portable-2.10.1-SNAPSHOT > (this is the location where I unzipped the files to) > > I didn't see a configuration file. > > 6B. So I first double-clicked on the file woas (Internet link). This resulted > in the opening of the browser. > 7B. I clicked on the link "Your Wiki-On-A-Stick" in the browser. > 8B. This resulted in the message "This webpage is not available". > 9B. So I again looked in the folder > > > G:\jspwiki-portable-2.10.1-SNAPSHOT-woas.tar\jspwiki-portable-2.10.1-SNAPSHOT-woas\jspwiki-portable-2.10.1-SNAPSHOT > >and I found woas (application) > > 10B. I double-clicked on woas (application) > 11B. The firewall gave a message and I had to allow access. > 12B. A command-prompt like window appeared, displaying a lot of text, the > last line was: > "INFO: Server startup in 6742 ms" > 13B. I double-clicked on woas (Internet Shortcut) > 14B. The browser appeared again, I clicked on the link "Your > Wiki-On-A-Stick". > 15B. The result was an error message in the browser: > > HTTP Status 404 - /wiki/ > type Status report > message /wiki/ > description The requested resource is not available. > Apache Tomcat/7.0.52 > > 16B. I continued as follows: using CTRL-C I closed the window that was opened > in step 12B. > 17B. I double clicked on woas (batch file) > 18B. As a result of this a command-prompt like window appeared, but also > disappeared very fast. > 19B. Trying several times, I finally was able to get a screen capture of the > fast-disappearing window > The message there was: > "'.' is not recognized as an internal; or external command, operable > program or batch file." > > > So it still didn't work. > > Could you please give me a few suggestions with things I could try? > > Many thanks in advance. > > Kind regards, > Bastiaan > > Van: Siegfried Goeschl [siegfried.goes...@it20one.com] > Verzonden: zondag 30 november 2014 11:36 > Aan: Geelhoed, B (thorax) > CC: Siegfried Goeschl > Onderwerp: Re: portable JSPwiki -
Re: [ANNOUNCE] Siegfried Goeschl as new JSPWiki PMC/Committer
Hi folks, I think it is good time to finally introduce myself :-) * Living in Vienna, Austria * Doing Java backend development * Started my ASF career as Apache Turbine committer in 2004 * Came across JSPWiki when meeting Jane Jalkanen during an ApacheCon Europe in 2008 * Searched for a portable Java-based Wiki and tinkered with JSPWiki to create a “Wiki On A Stick” in 2010 * Became a mentor during the final stage of the incubation Cheers, Siegfried Goeschl On 21 Aug 2014, at 17:53, Juan Pablo Santos Rodríguez wrote: > Hi all, > > we are happy to announce that we've voted to invite Siegfried Goeschl as > PMC and committer, and he has gladly accepted, so welcome Siegfried! > > > cheers, > juan pablo
JSPWiki @ ApacheCon Europe 2014 ...
Hi folks, the presentation got accepted so we will be featuring JSPWiki in Budapest :-) http://events.linuxfoundation.org/events/apachecon-europe/program/schedule * Anyone (users/developers) coming to ApacheCon? Meetup, beer and/or hackathon? Markdown support is on my mind ... * Any developer eager to co-present with me - I’m just a contributor and would welcome a committer/PMD :-) * Any suggestions/improvement for the slides - http://people.apache.org/~sgoeschl/presentations/apachecon-2014/jspwiki.pdf Thanks in advance Siegfried Goeschl
Re: Wiki farming / multiple instances
Hi Florian, the jspwiki-portable setup is tuned for hosting multiple independent JSPWikis on a single Tomcat * each wiki is a separate web app consisting of JSPs and configuration files * JSPWiki libraries are shared across all JSPWiki web apps * I’m currently running 8 JSPWikis on a small Tomcat on my laptop (using 82 MByte of real memory according to Max OS) Cheers, Siegfried Goeschl On 10 Jul 2014, at 10:48, Florian Holeczek wrote: > Hi all, > > is anyone out there using JSPWiki for a wiki farm or multiple instances > within the same application server? > > Regards > Florian
Re: Error when building JSPWiki
Hi folks,
actually the following snippet is defined in jspwiki-war/pom.xml
maven-surefire-plugin
${project.build.directory}
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
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.(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.(WikiEngine.java:430)
>>at org.apache.wiki.TestEngine.(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
>>
>>
>>
>>
>>
>>
>>
>>
>>
Re: deploying JSPWiki on a JBoss EAP 5.1
Hi Enrico, can you remove the offending xmlrpc-2.0.1.jar and give it a try again? I get my JSPWiki running without XMLRPC and it is only needed if you would like to do remote procedure calls Cheers, Siegfried Goeschl On 15 Apr 2014, at 10:32, Érico wrote: > Hello > > I am trying to deploy the JSPWiki war file into a JBoss 5x EAP > > But I am getting the following error : > > WARN [ClassLoaderManager] Unexpected error during load > of:org.xml.sax.Parser > java.lang.LinkageError: loader constraint violation: loader (instance of > org/jboss/classloader/spi/base/BaseClassLoader) > previously initiated loading for a different type with name > "org/xml/sax/Parser" > > I can see in the war file that this class file is on xmlrpc-2.0.1.jar > > I need help with this so I can use JSPWiki on this JBoss > > I can not change my JBoss version ... > > Thks !! > Érico
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
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
Re: WikiOnAStick Success
Hi folks, since I love positive feedback I just need to post this :-) Regarding Java issue - you need to have a full-blown JDK (Java Development Kit) in your path in order to compile JSPs - you can play around with the batch file. With pre-compiled JSPs it is sufficient to have a JRE (Java Runtime Environment) Regarding markup conversion - I did something similar to convert from JSPWiki to TWiki markup but this script does not have production quality Cheers, Siegfried Goeschl On 09 Apr 2014, at 16:01, Richard Pogson wrote: > Afternoon, > > Thank you for your help earlier, I have it up and running on Windows, there > was a Java issue on the Debian VM I will work this out. > > Our main use case for JSPWiki would be replacement of or our decrepit > MediaWiki install. > So I will be looking at some sort of Python script to extract the current db > entries and output them to markup. > If you know of anyone who has done anything this stupid before let me know > otherwise I will let you know of progress. > > Kind regards, > > Richard Pogson > > > This message has been scanned for malware by Websense. www.websense.com >
Apache JSPWiki @ Cloudy Track at ApacheCon Denver
Hi folks, Apache JSPWiki is getting publicity - we have an Apache JSPWiki presentation at ApacheCon :-) Any developers and/or users around at the conference - we could organise a come-together and hackathon session Cheers, Siegfried Goeschl Begin forwarded message: > From: Melissa Warnkin > Subject: Cloudy Track at ApacheCon Denver > Date: 5 Mar 2014 17:39:50 GMT+1 > To: "user@jspwiki.apache.org" , > "us...@libcloud.apache.org" , > "us...@cloudstack.apache.org" > Reply-To: user@jspwiki.apache.org > Reply-To: Melissa Warnkin > > Hello Cloudy Track Enthusiasts, > > As you are no doubt aware, ApacheCon North America will be held in Denver, > Colorado starting on April 7th. The Cloudy Track has > 12 talks!! Check it out here: > http://apacheconnorthamerica2014.sched.org/overview/type/cloudy+track. > > We would love to see you in Denver next month. Register soon, as prices go > up on March 14th. http://na.apachecon.com/. > > Best regards, > > Melissa > ApacheCon Planning Team
Re: Current progress on jspwiki-portable (aka Wiki On A Stick)
Hi Harry,
1) multiple wikis - it is not a requirement but I NEED multiple wiki spaces
since I run around 10 wikis :-) - each customer gets his own wiki
2) ad VersioningFileProvider - good idea, I changed my configuration accordingly
3) log4j warning - any suggestions. I see a NotSerializableException due to
some JSON data
4) the waring you see is from the compression saying that you need a
GNU-compatible unzip to work with long file names - AFAIK I can mute the plugin
Basically I’m not finished yet - I try to upload an improved version on
Wednesday :-)
Cheers,
Siegfried Goeschl
On 03 Mar 2014, at 20:11, Harry Metske wrote:
> Siegried,
>
> I did some basic testing, and it works like a charm.
> A few notes :
> * having two wiki's isn't a requirement as far as I am concerned (but I can
> easily delete the webapps/private folder for example)
> * I would like to see the VersioningFileProvider as the default.
> * some tweaks to the configuration could get us rid of a few log4j warnings
> during startup. I git-cloned the repo, tried to build it, but got a lot of
> these warnings during "mvn clean package":
>
> [WARNING] Entry:
> jspwiki-portable-2.10.1-SNAPSHOT/webapps/private/META-INF/maven/org.apache.jspwiki/jspwiki-war/pom.xml
> longer than 100 characters.
>
> I could prepare a pull request to 2 and 3 if you like.
>
> regards,
> Harry
>
>
>
>
> On 2 March 2014 23:08, Siegfried Goeschl 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 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 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 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 >>> >>
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
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 folks,
in order to keep you in the loop - I played around with the integration
* no need to tinker with the JSPWiki build.xml - I'm triggering
everything from within ./extensions/woas/build.xml
* I upgraded to jetty-distribution-7.6.14.v20131031
Will have a look how to integrate into the M2 build found in trunk
Cheers,
Siegfried Goeschl
On 23.10.13 01:13, Juan Pablo Santos Rodríguez wrote:
Hi Siegfried,
some comments inline:
On Wed, Oct 23, 2013 at 12:32 AM, Siegfried Goeschl
mailto:siegfried.goes...@it20one.at>>
wrote:
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
That would be great! :-)
* 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
I have to admit that caught me off-guard, I saw launch4j was BSD/MIT,
which is fine, and automatically assumed the same for the maven
plugin. Luckily, it is ok for us to use GPL'd build tools:
http://www.apache.org/legal/resolved.html#prohibited
* Not sure about MacOS application skeleton file in
"woas/resources/macos/"
unsure too; however
https://github.com/lukaszlenart/launch4j-maven-plugin/tree/master/src/main/bin/mac,
https://github.com/lukaszlenart/launch4j-maven-plugin/pull/2 and
https://github.com/lukaszlenart/launch4j-maven-plugin/blob/master/src/main/assembly/assemble-mac.xml
seem to suggest that could be enough to build a mac executable..
However, I feel we'll know for sure when building the mac executable
through the maven plugin
* 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)
we could ask @infra if needed
Thanks in advance
Siegfried Goeschl
thanks for your time + br,
juan pablo
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
jspwiki-portable 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
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
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 jspwiki-portable 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 <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 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
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 Koelmeyer: 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)
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 Cheers, Siegfried Goeschl > Am 16.10.2013 um 10:14 schrieb Dave Koelmeyer > : > >> 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: JSPWiki "Support for Multiple Wikis" and Hosting Solutions
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 Cheers, Siegfried Goeschl On 14.10.13 05:05, Dave Koelmeyer wrote: On 23/09/13 08:50 AM, Siegfried Goeschl wrote: Hi Jim, under https://github.com/sgoeschl/jspwiki-on-a-stick I have a portable JSPWiki which I use to host up to 11 wiki (spaces) using an embedded Jetty * the JSPWiki libraries are shared across all wikis * each wiki is a separate webapp Hi Siegfried, Does your JSPWiki on a stick work with the current stable release of JSPWiki? Cheers, Dave
Contributing Wiki On A Stick - Re: JSPWiki "Support for Multiple Wikis" and Hosting Solutions
Hi Dave, let me check with http://svn.apache.org/repos/asf/jspwiki/tags/jspwiki_2_9_1_incubating_rc2/ General question - any objections to contribute it to JSPWiki? Last time the problem was that my stuff used a different version of jetty - I'm still on Jetty 6.1.10 for the distributable Cheers, Siegfried Goeschl On 14.10.13 05:05, Dave Koelmeyer wrote: On 23/09/13 08:50 AM, Siegfried Goeschl wrote: Hi Jim, under https://github.com/sgoeschl/jspwiki-on-a-stick I have a portable JSPWiki which I use to host up to 11 wiki (spaces) using an embedded Jetty * the JSPWiki libraries are shared across all wikis * each wiki is a separate webapp Hi Siegfried, Does your JSPWiki on a stick work with the current stable release of JSPWiki? Cheers, Dave
Re: JSPWiki "Support for Multiple Wikis" and Hosting Solutions
Hi Jim, under https://github.com/sgoeschl/jspwiki-on-a-stick I have a portable JSPWiki which I use to host up to 11 wiki (spaces) using an embedded Jetty * the JSPWiki libraries are shared across all wikis * each wiki is a separate webapp Cheers, Siegfried Goeschl On 21.09.13 12:10, Jim Willeke wrote: Currently we host 7 instances of JSPWiki and a couple of other WEB Sites on Linux server we own. We are moving and would like to have this all hosted by "someone else". As our instances are currently defined as HOSTS within Tomcat (not Virtual hosts), it appears we would require a dedicated host? Currently we utilize a firewall that performs port redirection to-from port 80 to the 8080 on Tomcat and then Tomcat performs the URL redirection. We noticed that the http://jspwiki.apache.org/ site shows "Support for Multiple Wikis" but, see nothing that expreses details as to what is supported. What are other people doing for "Multiple Wikis" What are providers are other people using for JSPWiki? Thanks! -- -jim Jim Willeke
