jamwiki-devel Mailing List for JAMWiki (Page 3)
Brought to you by:
wrh2
Menu
▾
▴
jamwiki-devel — JAMWiki development mailing list.
This list is closed, nobody may subscribe to it.
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(45) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(53) |
Feb
(23) |
Mar
(6) |
Apr
(2) |
May
(5) |
Jun
(1) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2012 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(5) |
Mar
(54) |
Apr
(7) |
May
(1) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas K. <th...@ko...> - 2013-03-16 14:58:45
|
Ryan Holliday: > Given that my experience with Git is solely as a user and not as an > admin, would either of you be willing to take the lead in the migration? I volunteer. > I can provide Sourceforge access and help out as much as possible, but > we'll need to at least do the following: My sourceforge account is thkoch2001 > > * Migrate the Subversion repository (hopefully with history) to Git. No problem. > * Update Maven to build and deploy to Git. Will have to learn it, but will do so. > * Update build instructions. Ok. > Let me know your thoughts. If you'd like to wait until after 1.3.1 then > I'll get that out this weekend - I still need to write up the release > notes and do a handful of sanity checks. I could work on the git migration in the next week. So it would be fine if 1.3.1 would be out then by the beginning of the week. Regards, Thomas Koch, http://www.koch.ro |
|
From: Ryan H. <rya...@gm...> - 2013-03-15 04:19:46
|
On 3/14/2013 8:39 AM, jam...@li... wrote: > Are you familiar with the Guava library? > http://code.google.com/p/guava-libraries I've actually been looking at replacing ehcache for caching, and don't have strong feelings about things like commons.io, so Guava is definitely worth considering. Have you used its caching functionality before? Any feedback? I've never used Guava before, so are there other libraries or custom functionality in the JAMWiki codebase that it could replace besides commons.io and ehcache? Ryan |
|
From: Ryan H. <rya...@gm...> - 2013-03-15 04:07:24
|
On 3/14/2013 2:48 AM, jam...@li... wrote: > I meant the 1.3.1 release. But of course the sooner the better. I can do an > import in an hour once you (ryan) give the go. I agree fully that Git is a better SCM - I use it daily for work - but after the switch is done (yeah, let's switch) I'll be leaning on you guys for help if things go wonky. Given that my experience with Git is solely as a user and not as an admin, would either of you be willing to take the lead in the migration? I can provide Sourceforge access and help out as much as possible, but we'll need to at least do the following: * Migrate the Subversion repository (hopefully with history) to Git. * Update Maven to build and deploy to Git. * Update build instructions. Let me know your thoughts. If you'd like to wait until after 1.3.1 then I'll get that out this weekend - I still need to write up the release notes and do a handful of sanity checks. Ryan |
|
From: Ryan H. <rya...@gm...> - 2013-03-15 03:52:01
|
The original sender email address should be maintained now, assuming I updated the right setting. Ryan |
|
From: <jam...@li...> - 2013-03-14 21:23:57
|
Am 14.03.2013 um 20:54 schrieb jam...@li...: > On 3/14/2013 2:50 AM, jam...@li... wrote: >> Is there any option in the administration interface that could be switched to >> see the sender of a message? > > I set it up that way for privacy purposes so that people's email > addresses won't be revealed. Since this might be a touchy issue, if > anyone would prefer not to have the sender shown please speak up, > otherwise it's a simple matter to change it. Me don't mind, just want to ask if you can make sure the reply-to is nevertheless set to the list after this change. Don't want to "reply to all" and throw personal addresses away in addressing; And no, my MUA sadly does not have "reply to list" :-/ -- Regards, Peter |
|
From: <jam...@li...> - 2013-03-14 19:56:40
|
On 3/14/2013 8:18 AM, jam...@li... wrote: >> I modified the class to use temporary directories by using the >> TemporaryFolder Rule of JUnit 4.7[1]. Running the jamwiki-core tests takes >> 14 seconds this way. My /tmp folder is mounted on a ramdisk. If this fixes an issue for you then please commit a fix. Getting the unit tests to run within a working "test" environment has always been a challenge, so anything that can be done to improve the process would be greatly appreciated. Ryan |
|
From: <jam...@li...> - 2013-03-14 19:54:47
|
On 3/14/2013 2:50 AM, jam...@li... wrote: > Is there any option in the administration interface that could be switched to > see the sender of a message? I set it up that way for privacy purposes so that people's email addresses won't be revealed. Since this might be a touchy issue, if anyone would prefer not to have the sender shown please speak up, otherwise it's a simple matter to change it. Ryan |
|
From: <jam...@li...> - 2013-03-14 15:39:54
|
Are you familiar with the Guava library? http://code.google.com/p/guava-libraries It contains a lot of basic, useful stuff. Once you started using it, you don't want to write any more java without it. It feels a bit like going back from git to svn if you don't have it on your classpath. :-) Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-03-14 15:18:30
|
jam...@li...: > I modified the class to use temporary directories by using the > TemporaryFolder Rule of JUnit 4.7[1]. Running the jamwiki-core tests takes > 14 seconds this way. My /tmp folder is mounted on a ramdisk. I'm sorry. I made a mistake and the datadir was actually still on disk and the same for all tests. I corrected this now, but observed that the tests start to fail if a new datadir is created for each tests. So instead I created a random datadir as a static property of the JAMWikiUnitTest class that gets reused for all tests. The execution time is basically the same whether the tests are run on disk or on ramdisk. Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-03-14 14:03:44
|
ryan: > Can you send me the stack trace and build execution output via private > message at ryan dot holliday at gmail dot com? Your issue is almost > certainly a classpath or similar issue, but I don't encounter it locally > (building from the command line) and I know that non-Eclipse users have > been able to run unit tests successfully. Hi Ryan, I found the issue. When I run the tests from eclipse, then the clean target is not called. So the data dir from the last test run still exists and the method setupDatabase() in JAMWikiUnitTest does not get called. I modified the class to use temporary directories by using the TemporaryFolder Rule of JUnit 4.7[1]. Running the jamwiki-core tests takes 14 seconds this way. My /tmp folder is mounted on a ramdisk. [1] http://www.catosplace.net/blogs/personal/2009/08/07/junit-4-7- temporaryfolder-core-rule/ Do you think it would be a good idea to have a shiny clean new database for each test? This would provide more isolation of tests. Do you develop on a linux system? Is your temporary folder also mounted on a ramdisk. Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-03-14 09:51:01
|
Hi, I'm reading this list with my mail reader, not on the sourceforge web site. And it's very annoying that sourceforge replaces the sender address with "jam...@li...". Is there any option in the administration interface that could be switched to see the sender of a message? Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-03-14 09:49:07
|
I wrote: > > since Peter is now also using git-svn, should we do the switch after the > > next release? I meant the 1.3.1 release. But of course the sooner the better. I can do an import in an hour once you (ryan) give the go. Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-03-14 08:37:02
|
Hello folks, Am 13.03.2013 um 10:32 schrieb jam...@li...: > Ryan Holliday: >> As to switching to Git, if enough people want to do so then I'm not >> opposed to the idea. My main issue with Git (vs Subversion) is that >> with Git it's much easier to screw up your repository in a way that is >> difficult to undo, such as with funky merges or rebases, Maybe this impression comes from suboptimal usage in the past, but in fact I found it much easier to "undo" a change with git than with subversion. I can commit locally and - if absolutely necessary - rearrange the commits before pushing. That's virtually impossible using Subversion. Never ever rebase a repository others might have fetched from, but until there you're free to reset soft, mixed and hard and rebase whatever you want to. Additionally I'm free to test and try in a local-only branch and (fast-forward, if appropriate) merge only the relevant changesets. >> while with >> Subversion you can always just undo the problem commit. Which results in another commit shown in history, while git supports "real" undo (git reset --hard) ;-) >> If there are enough active JAMWiki >> developers with Git knowledge who can fix any such issues then I'm happy >> to switch, Define "enough", but whatever this means: count me in :-D >> but if the responsibility is mostly on me to deal with any >> SCM problems then I'd prefer to continue using Subversion. I'd volunteer to deal with SCM related questions too. >> Again, any thoughts that anyone else has on Git vs. Subversion are >> welcome I personally prefer git for some reasons (and I have to work with SVN at work, so I "feel" the (pain of the) difference: - completely "offline" development: I fetch. I code. I test. I merge back and forth. I branch, I stash. I finish my work. Than I push. - "real" undo: I commit something (locally). I recognize this has been a PITA. I "git reset --hard". Or I was clever enough to "git branch ..." before and I just plainly "git branch -D". No trace left, no confusion anywhere else about "what's this been? WTF?" - easy and fast "feature" branches: branch, develop feature, see you fail, drop it. Restart from scratch. - easy and fast "got an idea" branches: work on A, get an idea about B, create new branch (form common root or if it fits in: where ever you currently are), test idea and drop, keep or modify it later. - easy idea sharing: fork the repo, create your own feature branches, give another developer repository access, ask him/her to fetch your feature testing change sets (e.g. branch) and merge it into his/her own local repository. Get feedback, deal with it. And if it's finished: merge it to real development branch that is pushed to "commonly declared: MAIN" repository. - want to test some Git stuff? Clone your clone! As there's no "technically defined" primary source, there's no hassle creating another copy to test something. And if your tests end up with something useable: it's pretty easy to get it merged into "your primary" repository. - get patches the easy way: people can easily create and send patches and you can easily merge them. It's more than just a "diff". And you can easily create a local branch, apply the patch and if it work simply merge it to your main developing branch. Else there's nothing more easy than throwing the change away without it having affected your current work. So all in all: Git made my development work much easier. It's sometimes hard to understand in it's inner techniques and for "unusual" needs a little more difficult to handle, but it's flexible and simply does it's job. And honestly: if I don't know, how to add a second remote source for fetching merges and find the documentation hard to read about it: SVN can't even deal with this requirement. So blaming Git for being not as easy as SVN in tasks SVN does not even cope with, is ... ;-) All in all: if JAMWiki repository would stay SVN I'd have to - and do - deal with it. - If it's switched to Git, I'd be happy. :-D > Hi Ryan, > > since Peter is now also using git-svn, should we do the switch after the next > release? I'm in! :-D > I'm currently on job search so there's a bit uncertaincy. But I think I can > promis to be available to solve any Git-related issue. (I'm also very > confident that there shouldn't be any...) Me too. Not about the search, but the availability and the confidence :-) > I think I might even know Peter from some course at Fernuni Hagen? :-) Do we? Which ones? :-) -- Best regards, Peter |
|
From: <jam...@li...> - 2013-03-13 13:11:14
|
Hallo Charles, greetings from lace constance / Kreuzlingen! I just finished reading about your impressive work on Email support for jamwiki[1]. Do you also plan to work on email notifications for page changes? Or is this already implemented? [1] http://jamwiki.org/wiki/en/Tech:Email If you're not planing to work on this, do you plan to work on some other email related topics? I want to avoid having merge conflicts if we should work in the same area. Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-03-13 10:00:54
|
Ryan Holliday: > As to switching to Git, if enough people want to do so then I'm not > opposed to the idea. My main issue with Git (vs Subversion) is that > with Git it's much easier to screw up your repository in a way that is > difficult to undo, such as with funky merges or rebases, while with > Subversion you can always just undo the problem commit. We use Git at > work, and have had to put a number of processes in place to ensure that > people don't do anything that's unexpected and thus cause a lot of work > for the repository owner to fix. If there are enough active JAMWiki > developers with Git knowledge who can fix any such issues then I'm happy > to switch, but if the responsibility is mostly on me to deal with any > SCM problems then I'd prefer to continue using Subversion. > > Again, any thoughts that anyone else has on Git vs. Subversion are > welcome - I don't want to stand in the way of people using their > preferred SCM tool, but I also don't want to be the only with > responsibility for resolving Git-related issues. Hi Ryan, since Peter is now also using git-svn, should we do the switch after the next release? I'm currently on job search so there's a bit uncertaincy. But I think I can promis to be available to solve any Git-related issue. (I'm also very confident that there shouldn't be any...) I think I might even know Peter from some course at Fernuni Hagen? :-) Regards, Thomas Koch, http://www.koch.ro |
|
From: <jam...@li...> - 2013-03-10 19:14:34
|
I think the Encryption.bytes2String method can be killed - if I had to guess that's probably just very old code and no one noticed the possible cleanup. One caveat if you're looking into the password salts is to ensure that any change will work for existing installations (or with an upgrade process). I haven't looked at that issue in a long time, but as I recall there was no easy way to upgrade existing installations to support password salts using Java 5, but the new encryption methods in Java 6 made it possible. With JAMWiki 2.0 dropping support for Java 5 it should now be feasible to support password salts and upgrades, although it has been so long since I looked at the issue that I don't remember what the specific issues requiring a new Java version were. Let me know if you run into any problems as this was one of the items I had on the TODO list once Java 5 support was dropped. Ryan On 3/10/2013 11:56 AM, jam...@li... wrote: > Hi, > > I stumbled about JAMWiki not using any salt for password hashing and > wanted to start a request about it. Than I figured JIRA exists and > found JAMWIKI-36 ... So now I'm trying to take care about it. > > While crawling through the code, to get an image about who's using > what, when and why I saw > > org.jamwiki.utils.Encryption.bytes2String(byte[]) > > and am wondering, what's the concrete intention behind it? I see what > it does and from it's usage I see what's it currently expected to > do. But to achieve the very same much simpler code would be > sufficient. [1] So I fear there's something else "implied", which I > don't see ... > > Anybody out there able to answer my question? > > Best regards, Peter > > [1]: 'new String(byteData, "US-ASCII")' or 'new String(byteData)' > because simply casting byte to char is only valid for the very > optimistic assumption every provided byte value represents a valid > US-ASCII (or system default charset) character. > > The concrete question that came up to me is: what, if this method > just returns a hex string representation of 'byte[]'? OTOH than > Encryption.decrypt64(String) might break ... |
|
From: <jam...@li...> - 2013-03-10 18:56:55
|
Hi, I stumbled about JAMWiki not using any salt for password hashing and wanted to start a request about it. Than I figured JIRA exists and found JAMWIKI-36 ... So now I'm trying to take care about it. While crawling through the code, to get an image about who's using what, when and why I saw org.jamwiki.utils.Encryption.bytes2String(byte[]) and am wondering, what's the concrete intention behind it? I see what it does and from it's usage I see what's it currently expected to do. But to achieve the very same much simpler code would be sufficient. [1] So I fear there's something else "implied", which I don't see ... Anybody out there able to answer my question? Best regards, Peter [1]: 'new String(byteData, "US-ASCII")' or 'new String(byteData)' because simply casting byte to char is only valid for the very optimistic assumption every provided byte value represents a valid US-ASCII (or system default charset) character. The concrete question that came up to me is: what, if this method just returns a hex string representation of 'byte[]'? OTOH than Encryption.decrypt64(String) might break ... |
|
From: <jam...@li...> - 2013-03-08 05:38:40
|
Thanks Peter, Everything you've committed so far has been merged to trunk and to 1.3.x, and I've added you in the credits (please let me know if you'd like anything changed). I'll probably push the 1.3.1 release in a week or two. Thanks again for the fixes and cleanups! Ryan |
|
From: <jam...@li...> - 2013-03-07 07:04:01
|
Hi Ryan, Am 07.03.2013 um 05:49 schrieb jam...@li...: > Your changes in Subversion all look straightforward to me. Glad to hear :-) > Do you mind if I merge them to trunk and also backport them to the 1.3.x branch? Nope, I don't. That's what I've committed it for :-) Beside the fact we can discuss every commit I do to my "private" branch before merging it to trunk (and/or backporting it), I hereby grant the explicit allowance to do so, without former request in the future ... Unless explicitly noted that a dedicated commit needs request or discussion before being merged :-) > And if so, how would you prefer to be credited? "Peter Palmreuther (pitpalme)" would be OK. If you want or need to give an e-mail address somewhere, please use my Sourceforge address. > Thanks for helping out! You're welcome. As you might have noticed I didn't hesitate to commit a few additional changesets. If you don't mind: more to come. Most are kind of cleanup commits. As they're all in "my" branch I don't see a real problem. If you don't like some or all of them, just don't merge and tell me what's inappropriate. If things diverge too much from official sources I'll simply delete and recreate my branch. -- Best regards, Peter PS: If at some point commits look "strange" with respect to their form, please let me know. I'm working on this SVN repository using "git svn", because I'm more familiar to, and prefer, using git - it's just more flexible for my needs. Sometimes I might not see the effects resulting from this bridging and therefore am thankful for input, if there's any reason to complain :-) |
|
From: <jam...@li...> - 2013-03-07 04:49:33
|
Hi Peter, Your changes in Subversion all look straightforward to me. Do you mind if I merge them to trunk and also backport them to the 1.3.x branch? And if so, how would you prefer to be credited? Most people use something like "Ryan Holliday (wrh2)", so I could add you as "Peter (pitpalme)", although I'd need to know your last name. Alternately, let me know if you prefer some other name for credit purposes. Thanks for helping out! Ryan On 3/4/2013 10:10 PM, Ryan Holliday wrote: > On 3/3/2013 10:33 PM, jam...@li... wrote: >> If submitting the code is preferred through SVN, I'd be happy to get >> added to the >> list of write access enabled people :-) > > The items you've mentioned so far seem relatively low-impact, so if > you've got code ready then putting them in Subversion and doing a code > review is probably the easiest way forward. I've added you with the > developer role, so you should be able to make a branch from trunk and > commit any changes for further review. > > Let me know if you encounter any issues, and thanks for helping out! > > Ryan > |
|
From: <jam...@li...> - 2013-03-05 06:11:06
|
On 3/3/2013 10:33 PM, jam...@li... wrote: > If submitting the code is preferred through SVN, I'd be happy to get added to the > list of write access enabled people :-) The items you've mentioned so far seem relatively low-impact, so if you've got code ready then putting them in Subversion and doing a code review is probably the easiest way forward. I've added you with the developer role, so you should be able to make a branch from trunk and commit any changes for further review. Let me know if you encounter any issues, and thanks for helping out! Ryan |
|
From: <jam...@li...> - 2013-03-04 06:34:10
|
Hi Ryan, Am 03.03.2013 um 23:26 schrieb jam...@li...: > See http://jamwiki.org/wiki/en/How_to_Help#Developers for instructions > on contributing patches. Thanks for pointing this out; I've actually already read this (although I think the URL changed to http://jamwiki.org/wiki/en/How_to_Help#Programmers), but ... > If you'd like I can give you write access to > Subversion so that you can create a branch, and we can then work to get > your changes integrated. ... I thought I'd work down the list - and first discuss on jamwiki-devel - before asking for Subversion write access ;-) If submitting the code is preferred through SVN, I'd be happy to get added to the list of write access enabled people :-) -- Best regards, Peter |
|
From: <jam...@li...> - 2013-03-03 22:26:37
|
Hi Peter, See http://jamwiki.org/wiki/en/How_to_Help#Developers for instructions on contributing patches. If you'd like I can give you write access to Subversion so that you can create a branch, and we can then work to get your changes integrated. Ryan On 3/3/2013 2:22 PM, jam...@li... wrote: > Hello, > > I've just stumbled across JAMWiki and gave it a try. > As I'm a native German speaker and evaluated setting up a wiki for > primarily German speaking people I set up a "Virtual Wiki" for > "/de/*". > > Beside some minor translation fixes, which I'd like to submit > separately, I had some struggle with question marks appearing at > several locations. > > "StartingPoints" and "JAMWiki:Footer" for example began with one. > > I figured it might be there because localized "/pages/*" files are > stored encoded UTF-8 and using BOM. > > I figured how these files are read during setup and figured it's > copying is done without BOM awareness. > > I wrote a very small patch (based on already used commons-io) that > circumvents this problem. > > How to provide it for discussion? > > Best regards, > Peter > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Jamwiki-devel mailing list > Jam...@li... > https://lists.sourceforge.net/lists/listinfo/jamwiki-devel > |
|
From: <jam...@li...> - 2013-03-03 22:22:51
|
Hello, I've just stumbled across JAMWiki and gave it a try. As I'm a native German speaker and evaluated setting up a wiki for primarily German speaking people I set up a "Virtual Wiki" for "/de/*". Beside some minor translation fixes, which I'd like to submit separately, I had some struggle with question marks appearing at several locations. "StartingPoints" and "JAMWiki:Footer" for example began with one. I figured it might be there because localized "/pages/*" files are stored encoded UTF-8 and using BOM. I figured how these files are read during setup and figured it's copying is done without BOM awareness. I wrote a very small patch (based on already used commons-io) that circumvents this problem. How to provide it for discussion? Best regards, Peter |
|
From: <jam...@li...> - 2013-02-23 21:11:33
|
Can you send me the stack trace and build execution output via private message at ryan dot holliday at gmail dot com? Your issue is almost certainly a classpath or similar issue, but I don't encounter it locally (building from the command line) and I know that non-Eclipse users have been able to run unit tests successfully. Ryan On 2/23/2013 11:29 AM, jam...@li... wrote: > Hi, > > I try to run the jamwiki unit tests in eclipse but get 40 errors. The stack > trace suggests that those failures are caused by a missing db connection. > > Could you add a Wiki page in the development section about how to setup the > unit tests? "testing"? > > Thank you, > > Thomas Koch, http://www.koch.ro > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Jamwiki-devel mailing list > Jam...@li... > https://lists.sourceforge.net/lists/listinfo/jamwiki-devel > |
