About Subversion
The Sourceforge Repository browser allows to browse the source code. You can also use a program called Tortoise SVN for development - with that program you can download a copy of the repository, work on it, and then check in your changes.
Subversion allows locking of file, but it is not the default behaviour. Normally, subversion follows the chockout-edit-merge paradigm. if two people are working on the same file at the same time the software can usually automatically deal with any conflicts.
CVS has some limitations that subversions has overstepped. Namely, subversion can version directories, file rename and deletion.
Subversion does not work with a TAG dimension. In PVCS or CVS you can tag files, to label them or create branches. Subversion, on the other hand, allows you to do "smart" copies of files. Most people find this approach simpler and more natural (when you don't have a SCM, and want to archive a version of file, you copy to a new location) We have a branch called "trunk" which is where core development happens. Each developer can then create their own branch, work on changes and test them, and merge individual changes back to the trunk when they are ready. It's really nice software actually.
At the moment everyone has read-only access, so using Tortoise (or any other Subversion client) you can download a copy of the full source. I'd like to keep access to the trunk branch restricted, but if you're interested in doing development work I can create a development branch for you, just let me know. -- Ryan 15-Jul-2006 21:17 PDT
- What is the goal of ROOT in the subversion root? What is the goal of wiki?
Current trunk broken?
Seems that you've changed the logger but for these files from the current trunk I get compile errors:
Severity and Description Path Resource Location Creation Time IdLogger cannot be resolved JAMWiki/src/java/org/jamwiki/parser JAMWikiPostProcessor.java line 302 Logger cannot be resolved JAMWiki/src/java/org/jamwiki/parser JAMWikiPreProcessor.java line 722 Logger cannot be resolved JAMWiki/src/java/org/jamwiki/parser JAMWikiPreSaveProcessor.java line 266 Logger cannot be resolved JAMWiki/src/java/org/jamwiki/parser JAMWikiSpliceProcessor.java line 271 Logger cannot be resolved JAMWiki/src/java/org/jamwiki/parser/alt VQWikiFormatLex.java line 359 Logger cannot be resolved JAMWiki/src/java/org/jamwiki/parser/alt VQWikiLayoutLex.java line 340 Logger cannot be resolved JAMWiki/src/java/org/jamwiki/parser/alt VQWikiLinkLex.java line 533 Logger cannot be resolved to a type JAMWiki/src/java/org/jamwiki/parser JAMWikiPostProcessor.java line 302 Logger cannot be resolved to a type JAMWiki/src/java/org/jamwiki/parser JAMWikiPreProcessor.java line 722 Logger cannot be resolved to a type JAMWiki/src/java/org/jamwiki/parser JAMWikiPreSaveProcessor.java line 266 Logger cannot be resolved to a type JAMWiki/src/java/org/jamwiki/parser JAMWikiSpliceProcessor.java line 271 Logger cannot be resolved to a type JAMWiki/src/java/org/jamwiki/parser/alt VQWikiFormatLex.java line 359 Logger cannot be resolved to a type JAMWiki/src/java/org/jamwiki/parser/alt VQWikiLayoutLex.java line 340 Logger cannot be resolved to a type JAMWiki/src/java/org/jamwiki/parser/alt VQWikiLinkLex.java line 533
- All of those classes are generated during the ANT build using JFlex - has the "ant jflex" task been run prior to attempting to build? That should resolve the issue. Let me know if you continue to have any problems or if that doesn't solve the issue. -- Ryan 25-Sep-2006 11:19 PDT
- Yes that resolved the compiler errors. I'd thought that all files in the repository are are up-to-date. Thanks. -- Axel Kramer
- All files in the repository should be up-to-date, but the parser Java files are not in Subversion. Instead, the /src/jflex/ directory contains the files from which the parser Java files are generated. During the build process ("ant war") the "ant jflex" task is called to convert the Jflex files into the required Java source files. -- Ryan 25-Sep-2006 13:45 PDT
- Yes that resolved the compiler errors. I'd thought that all files in the repository are are up-to-date. Thanks. -- Axel Kramer
Problem while setup project with version from trunk.
I have tried to add an import of my existing personal tiddly wiki. Therefore I have added an additional Import Page. I compiled and would like to deploy. However after entering details in page "http://localhost:8080/jamwiki-0.6.0/en/Special:Setup" I get this message:
"A connection could not be established with the database; please re-check the settings:Cannot get a connection, pool error: Could not create a validated object, cause: ValidateObject failed"
In my log files I can see this message:
INFO: Deploying web application archive jamwiki-0.6.0.war
Exception in thread "HSQLDB Timer @1dd9891" java.lang.NullPointerException
at org.hsqldb.lib.HsqlTimer.nextTask(Unknown Source)
at org.hsqldb.lib.HsqlTimer$TaskRunner.run(Unknown Source)
at java.lang.Thread.run(Thread.java:619)
Any idea what's probably wrong? Can I enable more logging information somehow? I have already set all levels in logging.properties to ALL. Should trunk work currently? Mike 12-Jul-2007 13:34 PDT
- This is the second similar report - see Feedback#MORE INSTALL PROBLEMS, which involved the same HSQL error (failure to retrieve connection). I'm not sure why these are occurring (I've never experienced it personally) - what JDK version are you using to compile? Perhaps there's some weird interaction somewhere. -- Ryan 12-Jul-2007 22:57 PDT
- It works on my system with version 0.5.4. Some important changes since that? Mike 13-Jul-2007 08:39 PDT
Ubuntu Feisty 7.04. java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)
-
-
- I don't know if I've tried doing an internal database install since branching for 0.6.0, so if no one else figures it out I'll try to see if I can figure out what might have broken. Thanks for narrowing down the problem! -- Ryan 13-Jul-2007 21:51 PDT
- I've found the problem (I didn't think through revision 1489 enough) and will try to get a fix in place soon. -- Ryan 15-Jul-2007 01:14 PDT
- This should be fixed in trunk now. There are a few remaining setup issues that will put some errors in the logs, but they shouldn't stop setup from completing successfully and I'll try to address them in the next few days. Thanks for the bug report, and sorry about the breakage - let me know if you continue seeing any problems. -- Ryan 15-Jul-2007 02:16 PDT
- Works for me. Thanks. Mike 15-Jul-2007 02:45 PDT
- This should be fixed in trunk now. There are a few remaining setup issues that will put some errors in the logs, but they shouldn't stop setup from completing successfully and I'll try to address them in the next few days. Thanks for the bug report, and sorry about the breakage - let me know if you continue seeing any problems. -- Ryan 15-Jul-2007 02:16 PDT
- I've found the problem (I didn't think through revision 1489 enough) and will try to get a fix in place soon. -- Ryan 15-Jul-2007 01:14 PDT
- I don't know if I've tried doing an internal database install since branching for 0.6.0, so if no one else figures it out I'll try to see if I can figure out what might have broken. Thanks for narrowing down the problem! -- Ryan 13-Jul-2007 21:51 PDT
-
Test fails
I have Ubuntu Feisty. Testcase org.jamwiki.test.utils.UtilitiesTest.testGetClassLoaderFileThrowsNullPointerException fails, because I get this Exception
java.lang.NullPointerException
at sun.misc.MetaIndex.mayContain(MetaIndex.java:225)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:744)
at sun.misc.URLClassPath.getResource(URLClassPath.java:168)
at sun.misc.URLClassPath.getResource(URLClassPath.java:220)
at java.lang.ClassLoader.getBootstrapResource(ClassLoader.java:1113)
at java.lang.ClassLoader.getResource(ClassLoader.java:974)
at org.jamwiki.utils.Utilities.getClassLoaderFile(Utilities.java:524)
at org.jamwiki.test.utils.UtilitiesTest.
testGetClassLoaderFileThrowsNullPointerException(UtilitiesTest.java:890)
The NullpointerException doesn't contain any message, therefore
fails. Mike 14-Jul-2007 16:35 PDT
- The test case is probably wrong, although it seems to pass on my local box using JDK 1.4. A lot of the current test cases were auto-generated and may be of limited use, so feel free to commit a patch that updates or deletes anything that appears to be incorrect. -- Ryan 15-Jul-2007 00:21 PDT
- Committed revision 1532 Mike 15-Jul-2007 01:00 PDT
JDK 1.4 vs. JDK 1.5
I'm getting another error, and after a quick search of the Maven documentation I'm not seeing an obvious resolution, so hopefully this is one that you may be able to fix easily (if not let me know and I'll investigate further, but I didn't want to spend hours on something that someone else could fix in minutes):
[INFO] [antrun:run {execution: generate-flex}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Compiling 153 source files to D:\code\workspace\wiki\trunk\jamwiki\target
\classes
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
D:\code\workspace\wiki\trunk\jamwiki\src\main\java\org\jamwiki\taglib\EnabledTag
.java:[19,-1] cannot access javax.servlet.jsp.JspException
bad class file: C:\Documents and Settings\Ryan\.m2\repository\javax\servlet\jsp\
jsp-api\2.0\jsp-api-2.0.jar(javax/servlet/jsp/JspException.class)
class file has wrong version 49.0, should be 48.0
D:\code\workspace\wiki\trunk\jamwiki\src\main\java\org\jamwiki\taglib\EnabledTag
.java:[19,-1] cannot access javax.servlet.jsp.JspException
bad class file: C:\Documents and Settings\Ryan\.m2\repository\javax\servlet\jsp\
jsp-api\2.0\jsp-api-2.0.jar(javax/servlet/jsp/JspException.class)
class file has wrong version 49.0, should be 48.0
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6 seconds
[INFO] Finished at: Sat Jul 21 11:01:07 PDT 2007
[INFO] Final Memory: 10M/28M
[INFO] ------------------------------------------------------------------------
Previously JAMWiki included an appropriate version of servlet.jar, but it looks like Maven has now pulled in a JDK 1.5 version? That's my best guess at the moment. Is there a quick and easy way in the POM to ensure that it gets the right version? -- Ryan 21-Jul-2007 10:47 PDT
- Never mind, the POM specified servlet 2.4 instead of 2.3. Fixed now. -- Ryan 21-Jul-2007 10:49 PDT
test fail because of internationalization
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.jamwiki.test.JAMWikiTestSuite
22 juil. 2007 18:23:25 org.jamwiki.utils.WikiLogger warning
ATTENTION: Property file /home/pub/users/regis/workspaces/workspace/jamwiki/target/classes/jamwiki.properties does not exist
22 juil. 2007 18:23:25 org.jamwiki.utils.WikiLogger warning
ATTENTION: No character encoding specified to convert from, using UTF-8
22 juil. 2007 18:23:25 org.jamwiki.utils.WikiLogger warning
ATTENTION: No character encoding specified to convert to, using UTF-8
22 juil. 2007 18:23:25 org.jamwiki.utils.WikiLogger warning
ATTENTION: No character encoding specified to convert to, using UTF-8
22 juil. 2007 18:23:25 org.jamwiki.utils.WikiLogger warning
ATTENTION: Unable to convert value testUtilitiesText from testUtilitiesFromEncoding to testUtilitiesToEncoding
java.io.UnsupportedEncodingException: testUtilitiesFromEncoding
at java.lang.StringCoding.encode(StringCoding.java:269)
at java.lang.String.getBytes(String.java:947)
at org.jamwiki.utils.Utilities.convertEncoding(Utilities.java:187)
at org.jamwiki.test.utils.UtilitiesTest.testConvertEncoding3(UtilitiesTest.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
Are these tests units test or integration tests?
Do you need jamwiki.properties to run the tests? Is there a default jamwiki.properties file?
- That unit test is bogus - it's trying to convert using invalid encodings, and should be removed from the tests. I suspect that because it throws an exception it never showed up as a failure in the test result reports. For what it's worth, many of the unit tests were created from a tool that automatically generated unit tests from the source code - see Feedback#Automated unit tests. Some of them are of limited value, but the thinking was that it was better to have some of the coverage provided by the automated tool rather than no unit tests. None of the unit tests should require a jamwiki.properties file, although if there is some way to create unit tests that are intelligent enough to know where to look for their properties file then that would be a nice cleanup. -- Ryan 22-Jul-2007 09:22 PDT
- Thos units tests are actually ignored.
There is actually only one problem
Results :Tests run: 276, Failures: 1, Errors: 0, Skipped: 0 [INFO] ------------------------------------------------------------------------ [ERROR] BUILD FAILURE [INFO] ------------------------------------------------------------------------
And the test report is as follow
--------------------------------------------------------------------------------
Test set: org.jamwiki.test.JAMWikiTestSuite
-------------------------------------------------------------------------------
Tests run: 276, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.678 sec <<< FAILURE!
testHeading(org.jamwiki.test.parser.jflex.WikiHeadingTagTest) Time elapsed: 0.057 sec <<< FAILURE!
junit.framework.ComparisonFailure: expected:<...§ion=1">Edit[]</a>]</div><a name="...> but was:<...§ion=1">Edit[er]</a>]</div><a name="...>
at junit.framework.Assert.assertEquals(Assert.java:81)
at junit.framework.Assert.assertEquals(Assert.java:87)
at org.jamwiki.test.parser.jflex.WikiHeadingTagTest.testHeading(WikiHeadingTagTest.java:39)
Of course "Editer" means "to edit" in French. Now, the question is: why is this test run in Frenchwhen JFlexParserTest has
parserInput.setLocale(Utilities.buildLocale("en_US"));and...
regis ~/pub/workspaces/workspace/jamwiki % env | grep LANG [kro64]LANG=C LANGUAGE=C LC_LANG=C LC_LANGUAGE=C
- That looks like a valid error in the unit test code (but not in JAMWiki), and since most of the people that have been using the unit tests have English as the default language it's likely you're the first person who hit it. The unit test framework is pretty basic right now, and I'm not sure that it actually tests different languages properly. For now if you want to comment that particular test out and add a "FIXME" comment we can disable it and return to it in the future. Nice catch! -- Ryan 22-Jul-2007 09:37 PDT
- I dugg the source code. The locale is properly set to the JAMWikiProcessor. I don't know why it produces French for me.
bugs from unit tests
I have written some unit/functionnal tests for the Utilies class, and I have found two 'bugs' (the parser does not strictly respect mediawiki syntax)
My question is: when I reach somethink like this,
- should I comment the unit test (with a FIXME tag for instance)
- or should I leave the bug fail
The best of course is to leave the unit test, and fix the bug (but in this particular case, it seems to complicated for me). -- Regis Decamps
- The best solution is probably to leave the failed test case, and I'll see if I can update the parser code to resolve the issue. I generally don't have much time to work on JAMWiki during the week, so it may have to wait a bit before I get to it - hopefully that doesn't cause too much inconvenience. -- Ryan 23-Jul-2007 14:18 PDT
- I just tried on Wikitravel (Mediawiki version 1.10.1) and here's what I'm seeing:
'1' '1' ''2'' <i>2</i> '''3''' <b>3</b> ''''4'''' '<b>4'</b> '''''5''''' <i><b>5</b></i> ''''''6'''''' '<i><b>6'</b></i> '''''''7''''''' ''<i><b>7''</b></i>
-
- ...and on JAMWiki:
- '1' → '1'
- ''2'' → 2
- '''3''' → 3
- ''''4'''' → '4'
- '''''5''''' → 5
- ''''''6'''''' → '6'
- '''''''7''''''' → 7
-
- Although the behavior with 6 and 7 apostrophes is different, that behavior isn't defined for Mediawiki, so based on the tables at http://meta.wikimedia.org/wiki/Help:Wikitext_reference#Basic_text_formatting I think that JAMWiki's current behavior is correct. -- Ryan 23-Jul-2007 22:33 PDT
- Oops, my mystake. I misunderstood the "4 apostrophes doesn't do anything special". They are actually bold + one apostrophe left apart on each side.
- Although the behavior with 6 and 7 apostrophes is different, that behavior isn't defined for Mediawiki, so based on the tables at http://meta.wikimedia.org/wiki/Help:Wikitext_reference#Basic_text_formatting I think that JAMWiki's current behavior is correct. -- Ryan 23-Jul-2007 22:33 PDT
Hot deployment
When I do a hot deployment in Tomcat (wimply by updating the war), Jamwiki cannot restart:
javax.servlet.jsp.JspException: The database is already in use by another process:org.hsqldb.persist.NIOLockFile@9aa86479[file =/tmp/jamwiki/database/jamwiki.lck, exists=true, locked=false, valid=false, fl =null]:
Have you seen something similar? How do you correct it? -- Regis Decamps
- There have been a few similar reports, but yours is the first that indicated hot deployment. This will probably be tough to fix, so maybe add a comment on Bug Reports#Only one time to edit on jamwiki 0.5.2. -- Ryan 23-Jul-2007 14:19 PDT
context.xml in wiki/local-files
Archived from the Feedback page:
I need to deploy in a tomcat 5.5 including a context.xml in war's META-INF directory. The following patch to build.xml could be usefull to someone. Fell free to merge to main source if you wish.
Index: build.xml
===================================================================
--- build.xml (revisione 1488)
+++ build.xml (copia locale)
@@ -115,6 +115,11 @@
<include name="*.jar" />
</fileset>
</copy>
+ <copy todir="${dir.build}/war/META-INF" overwrite="yes">
+ <fileset dir="${dir.local}">
+ <include name="context.xml" />
+ </fileset>
+ </copy>
<war destfile="${dir.build}/${war.name}-${app.version}.war" basedir="${dir.build}/war" webxml="${dir.src.webapp}/WEB-INF/web.xml" />
<delete dir="${dir.build}/war" />
</target>
-- mnencia 02-Jun-2007 10:22 PDT
- I never responded to this comment (sorry!) but thanks for contributing! The current Maven pom.xml has replaced the old ANT build.xml file so this patch no longer applies, but contributions are always appreciated. -- Ryan 02-Dec-2007 11:54 PST