jamwiki-devel — JAMWiki development mailing list.

Re: [Jamwiki-devel] Surefire test quirks

[<jam...@li...>]

> While trying to improve the build process I came across the JUnit test
> cases which setup I do not understand at all.

That code definitely needs commenting, sorry for the confusion! 
Basically, what's happening is that prior to running the unit tests a 
"test" JAMWiki instance is installed in the "target" folder with all 
test topics loaded into it.  That way when the unit tests run there will 
be an HSQL instance with topics available, and a valid properties file 
with appropriate test settings.

> First of all, why is a clean always autoperformed? What is the need for?
> It imposes a severe performance penality on the builds.
> I disabled that and all tests started to fail.

The "clean" is done because the "test" install sets itself up in the 
Maven "target" folder, so each unit test run wipes out any old instance 
and sets up a new one.  If there is a better way to do that then I'd be 
in favor of making a change, although it's worth noting that the "test" 
setup itself is useful for unit testing purposes since it exercises the 
default JAMWiki setup paths.

> I started digging and found JAMWikiUnitTest#setup.
> Why the heck do you manually copy the resources? This is Maven's task.
> Doesn't matter what I started to change in the setup method, test still
> failed.

This is partially a legacy thing - "src/test/resources/data/files" 
contains expected output for several parser unit tests, and in the past 
these were copied so that lookups could find the result files.  That may 
not be needed any longer and could probably benefit from some 
re-examination.

> Every package run costs 4 minutes, this makes really hard to improve the
> POM interatively.

If it helps, for now feel free to disable unit tests by default and I 
can try to help out with speeding this up.  I agree that the build is 
really slow - as the number of unit tests has grown things have gotten 
progressively worse, but since it wasn't causing serious issues for 
anyone it wasn't an issue I was looking into.  It sounds like it may now 
be time to try to speed things up :)

> 1. ParserTest#parseResult: There is no need to retrieve the file at all.
> A input stream should suffice.

Sounds good to me.

> 2. TestFileUtil#retrieveFileContent: Why do you do that manually? There
> is Commons IO! Plus, you did not specify the file encoding which might
> cause errors in the test run.

This is probably a legacy issue, or just an oversight from the initial 
implementation.  Feel free to swap this for the Commons IO version, or I 
can do so next time I sit down to write code.

Thanks for the detailed analysis, and let me know what I can do to make 
this easier to work with.

Ryan

Re: [Jamwiki-devel] JAMWiki 1.0.0 Plans

[<jam...@li...>]

Hi Mike,

> if I understood you correct, the release is going to happen sometime in Feb?
> I am in progress of some ground-breaking changes in the Maven build.
> This will ease the build process tremendously compared to the trunk.
> Beside that I will fix other Maven releated bugs if they come across. I
> guess, most fixes will be ready by Jan.

I'm hoping for a late-January or early-February release, but I'm really 
bad at predicting release dates and usually try to release only when I 
feel confident that enough testing has been done to avoid any truly 
embarrassing bugs from being included, so it's probably 50-50 whether 
the release is done by then or not.  In the past I've tried to limit 
major release cycles to 6-8 months in order to keep the code fresh and 
prevent release cycles from dragging on, and since JAMWiki 0.9.0 came 
out in late June that would mean that the target for JAMWiki 1.0.0 would 
late December through late February.

As to your Maven changes, they've all looked good so far, and since they 
are changing the build process rather than core code it should be OK to 
make any changes you feel necessary right up until the final release - 
I'm not worried about these changes introducing bugs that would require 
additional testing.  Additionally, since I don't want you to feel 
rushed, if the Maven changes aren't done by late-January / 
early-February then would it be OK to just continue the work as part of 
the JAMWiki 1.1.0 release cycle?

> Anyway, I not mentioning these changes in the CHANGELOG because they
> have nothing to do with JAMWiki itself.

Feel free to add at least one line to the CHANGELOG since doing so is 
one of the few ways that people can publicly get credit for their 
contributions, and I've been very grateful for the contributions you've 
made thus far :)

> JIRA? What a great idea! Are you planning to run it on the same Tomcat
> which hosts jamwiki? Did you get a free license by Atlassian?

I've got it installed on the same physical server that runs jamwiki.org, 
but it's using the Jira standalone install since I've already got 
several webapps running off of the same Tomcat instance, and I've run 
into some issues as a result.  I haven't yet gotten email notifications 
working, and I need to do some additional configuration, but hopefully 
when I get back from this roadtrip I'll get that finished.  And yes, 
Atlassian provides free licenses for open source projects (see 
http://www.atlassian.com/opensource/).

As to your followup question about using Sourceforge's Trac offerings, I 
personally like the interface and features of Jira better, but if there 
is a strong preference for Trac let me know and I'll give it a second look.

Ryan

[Jamwiki-devel] Surefire test quirks

[<jam...@li...>]

While trying to improve the build process I came across the JUnit test 
cases which setup I do not understand at all.

First of all, why is a clean always autoperformed? What is the need for? 
It imposes a severe performance penality on the builds.
I disabled that and all tests started to fail.

I started digging and found JAMWikiUnitTest#setup.
Why the heck do you manually copy the resources? This is Maven's task.
Doesn't matter what I started to change in the setup method, test still 
failed.

There is something seriously wrong with the test setup imho. Since I do 
not know the structure of the test suite, I am not able to fix this.

Please enlighten me! :-(

Every package run costs 4 minutes, this makes really hard to improve the 
POM interatively.

Moreover, there are some other quirks like:
1. ParserTest#parseResult: There is no need to retrieve the file at all. 
A input stream should suffice.
2. TestFileUtil#retrieveFileContent: Why do you do that manually? There 
is Commons IO! Plus, you did not specify the file encoding which might 
cause errors in the test run.

Mike

Re: [Jamwiki-devel] JAMWiki 1.0.0 Plans

[<jam...@li...>]

sorry, I am struggling with spelling today..

Re: [Jamwiki-devel] JAMWiki 1.0.0 Plans

[<jam...@li...>]

jam...@li... schrieb:
> Also, on a slightly related note, I'm working on getting a Jira bug 
> tracker set up.  While I like the idea of keeping all bug reports and 
> other wiki-related discussions on the wiki, the reality is that a bug 
> tracker will make it much easier to track and organize bug reports, so 
> barring objections I think it's time to move to one.

Just another thought: SourceForge provided Trac instances. Wouldn't this 
suffice? I worked with Trac (over at FCKeditor) for more than I year and 
was happy with.

Mike

Re: [Jamwiki-devel] JAMWiki 1.0.0 Plans

[<jam...@li...>]

jam...@li... schrieb:
> Hi,
> 
> [snipping release timeline]
> 
> Hopefully that makes sense.  Mike, if you have additional Maven changes 
> (or anything else) that won't be ready before the first week of January 
> let me know and we can talk about pushing dates out further, but 
> otherwise I'd like to start wrapping up this release cycle so that the 
> 1.0.0 release can be finished up.

Ryan,

if I understood you correct, the release is going to happen sometime in Feb?
I am in progress of some ground-breaking changes in the Maven build. 
This will ease the build process tremendously compared to the trunk. 
Beside that I will fix other Maven releated bugs if they come across. I 
guess, most fixes will be ready by Jan.
Anyway, I not mentioning these changes in the CHANGELOG because they 
have nothing to do with JAMWiki itself.

> Also, on a slightly related note, I'm working on getting a Jira bug 
> tracker set up.  While I like the idea of keeping all bug reports and 
> other wiki-related discussions on the wiki, the reality is that a bug 
> tracker will make it much easier to track and organize bug reports, so 
> barring objections I think it's time to move to one.

JIRA? What a great idea! Are you planning to run it on the same Tomcat 
which hosts jamwiki? Did you get a free license by Atlassian?

Mike

[Jamwiki-devel] JAMWiki 1.0.0 Plans

[<jam...@li...>]

Hi,

In the hope that it might useful to others, here are some thoughts on 
the release plans for the upcoming 1.0.0 release:

1. The first beta is out - see 
http://jamwiki.org/wiki/en/Latest_News#JAMWiki_1.0.0_Beta_1

2. http://jamwiki.org/wiki/en/Tech:JAMWiki_1.0.0 has an overview of what 
has been implemented and a few of my personal remaining TODO items.  My 
guess is that most of the remaining TODOs will be deferred in the 
interest of getting a release done, but I'd at least like to get the 
locale-specific date issue, the separate directory for resized images, 
and the pagination for categories implemented.

3. By the first week of January I'd like to have a second beta ready 
that will (hopefully) mark a feature freeze.  From that point onwards 
I'm planning on writing additional unit tests and doing some testing on 
different databases and app servers to flush out remaining bugs.

4. A third beta with bug fixes will probably go out 2-3 weeks after the 
second beta.

5. Assuming all goes well, 2-3 weeks after the third beta JAMWiki 1.0.0 
should be ready for release and trunk can be opened for development work 
for 1.1.0.  If all does not go well then as many additional beta 
releases as needed would go out.

Hopefully that makes sense.  Mike, if you have additional Maven changes 
(or anything else) that won't be ready before the first week of January 
let me know and we can talk about pushing dates out further, but 
otherwise I'd like to start wrapping up this release cycle so that the 
1.0.0 release can be finished up.

Also, on a slightly related note, I'm working on getting a Jira bug 
tracker set up.  While I like the idea of keeping all bug reports and 
other wiki-related discussions on the wiki, the reality is that a bug 
tracker will make it much easier to track and organize bug reports, so 
barring objections I think it's time to move to one.

Cheers,

Ryan

Re: [Jamwiki-devel] Subversion repo format need to upgraded at least to version 1.5

[<jam...@li...>]

The Subversion repository has been upgraded to 1.5 - please let me know 
if there are any further problems.

For future reference here are the steps that were followed (partly from 
http://marcus.bointon.com/archives/85-Subversion-1.5-repository-upgrade-on-SourceForge.html):


1. Repository backed up 
(https://sourceforge.net/apps/trac/sourceforge/wiki/Using%20rsync%20for%20backups). 
  I actually just ran my weekly JAMWiki backup script, but the steps in 
this URL reference the rysnc backup steps.

2. Connect via SSH 
(https://sourceforge.net/apps/trac/sourceforge/wiki/Shell%20service):

    ssh -t USER,ja...@sh... create

3. Dump & restore the repository:

    adminrepo --checkout svn
    svnadmin dump /svnroot/jamwiki > svn.dump
    rm -rf /svnroot/jamwiki/*
    svnadmin create /svnroot/jamwiki
    svnadmin load /svnroot/jamwiki < svn.dump
    adminrepo --save svn



On 12/5/2010 6:16 AM, jam...@li... wrote:
> Hi Ryan,
>
> I tried to reintegrate my java-diff branch and it failed. I am suffering
> from this: http://sourceforge.net/apps/trac/sourceforge/ticket/7500
>
> Please upgrade to 1.5 at least as described. I won't be able to use the
> recorded mergeinfo properties.
>
> Miek

Re: [Jamwiki-devel] Subversion repo format need to upgraded at least to version 1.5

[<jam...@li...>]

For some reason I thought that the repository was upgraded ages ago, but 
obviously not - perhaps that was a 1.3 to 1.4 upgrade.  In any case, I'm 
currently in a coffee shop that will be closing in twenty minutes, so 
this may not be the best time to attempt a restore of the repository - 
I'll get to this as soon as I've got a reliable internet connection for 
a couple of hours, hopefully tomorrow night but if not then definitely 
by Tuesday evening.  As a workaround I think you can do a "record-only" 
merge of problem changesets, but that's obviously a last resort type of 
option.  Sorry for the inconvenience.


On 12/5/2010 6:16 AM, jam...@li... wrote:
> Hi Ryan,
>
> I tried to reintegrate my java-diff branch and it failed. I am suffering
> from this: http://sourceforge.net/apps/trac/sourceforge/ticket/7500
>
> Please upgrade to 1.5 at least as described. I won't be able to use the
> recorded mergeinfo properties.
>
> Miek

[Jamwiki-devel] Subversion repo format need to upgraded at least to version 1.5

[<jam...@li...>]

Hi Ryan,

I tried to reintegrate my java-diff branch and it failed. I am suffering 
from this: http://sourceforge.net/apps/trac/sourceforge/ticket/7500

Please upgrade to 1.5 at least as described. I won't be able to use the 
recorded mergeinfo properties.

Miek

Re: [Jamwiki-devel] Java Diff has been promoted to Maven Central

[<jam...@li...>]

Hi Mike,

 > Java Diff is now a separate project hosted in Maven Central.

Thanks for doing this!  The changes on your branch look good, so feel 
free to merge to trunk whenever you're comfortable doing so.  I'm on an 
extended road trip so I may not be able to respond as quickly as normal, 
but please let me know if you have any questions or concerns and I'll 
try to respond as quickly as possible.

Ryan

Re: [Jamwiki-devel] JAMWiki's versioning system is ill-conceived

[<jam...@li...>]

Hi Mike,

 > I recently ran into this article [1]. Some of the versioning concepts
 > are ill-conceived and contradict common versioning schemes escpecially
 > to those of Maven and Apache.

I've updated the FAQ to more correctly reflect what is going on.  I've 
gotten questions in the past such as "when will the JAMWiki production 
release happen" from people who assumed any version earlier than "1.x" 
meant beta software, so I think it's past time to bump the version to 
1.x for marketing and psychological reasons, but I also wanted to set 
expectations that the release that will be named "1.0.0" won't be any 
more "major" than past major releases.  Hopefully the FAQ is clearer now.

If people are interested in a larger discussion about version naming 
then I'm more than willing to entertain alternative proposals.  At the 
moment version numbering is much like the Linux kernel in that JAMWiki 
has a "major" number that is essentially meaningless while the "minor" 
number indicates a feature release, and the "bugfix" number indicates 
bugfixes.  I suppose the "major" number could be tied to whatever 
minimum JDK is supported or some other factor if people want to see it 
updated occasionally, although I'm not sure using it for the 2-3 yearly 
feature releases makes sense as the "minor" number field would then be 
essentially unused, and that's the field that other projects that 
release on a similar timeline use to indicate feature releases.

Any thoughts or suggestions are welcome.

Ryan

[Jamwiki-devel] Java Diff has been promoted to Maven Central

[<jam...@li...>]

Guys,

Java Diff is now a separate project hosted in Maven Central. This means 
that it will be separated out of JAMWiki and it can now be used by 
everyone else in his Java code.
I'll will integrate this in my branch in the first place and will then 
merge back into trunk.

Check this out: http://uk.maven.org/maven2/org/incava/java-diff/
The bundle contains signed binaries by me + sources and javadoc.

Mike

[Jamwiki-devel] JAMWiki's versioning system is ill-conceived

[<jam...@li...>]

Hi folks,

I recently ran into this article [1]. Some of the versioning concepts 
are ill-conceived and contradict common versioning schemes escpecially 
to those of Maven and Apache.

If you stick to a 3 number versionining scheme, you always have major, 
minor and bugfix. There cannot be 2 major versions. Especially if you 
use Maven you are dictated by the convention over configuration. And 
because Maven is an Apache project, it follows the Apache versioning 
scheme [2] or [3] which guarantees a reliable upgrade path.

Some projects break this rule with their custom versioning scheme. Most 
without knowing that or maybe just ignorance, like LogBack but they 
should not be taken as an example.

Bottom line: if you stick to common conventions, you should follow them 
to make life easier for everyone else using your software.

JAMWiki should embrace this concept starting version 1.0 and stick with it.

To rephrase the issue with LogBack. It is an awesome project but Ceki 
sticks with zillions of patch versions introducing serious breaking 
changes. No one should be afraid of increasing the minor version in such 
a case. Numbers are cheap.

Mike

[1] http://jamwiki.org/wiki/en/FAQ#How_are_releases_numbered%3F
[2] http://apr.apache.org/versioning.html
[3] 
http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html#pom-reationships-sect-versions

Re: [Jamwiki-devel] [POM improvement] Modifications in javadiff

[<jam...@li...>]

jam...@li... schrieb:
>  >has anything been modified in javadiff?
> 
> The Javadiff code in the JAMWiki archive is an exact copy of the code 
> found at http://www.incava.org/releases/1041874499.  The author licenses 
> the code under the BSD license.  I don't know if it's standard practice 
> or not to contact an author prior to pushing code to Maven, but 
> unfortunately Jeff no longer lists any contact information on his web 
> site - I have an email address for him that worked in 2006, so if you 
> need to get in touch with him first let me know and I'll send it to you 
> privately.

The standard practice would be to contact the author but there is no 
contact information. Even if, the project is Ant-based, I guess the 
author won't do any extra work. the Maven wiki says that if the author 
does not want to do the work, any third party call raise a request.
This is what I will do.

I have already done this for this library: 
https://repository.sonatype.org/index.html#nexus-search;gav~~imageinfo~1.9~~

Mike

Re: [Jamwiki-devel] [POM improvement] Modifications in javadiff

[<jam...@li...>]

 >has anything been modified in javadiff?

The Javadiff code in the JAMWiki archive is an exact copy of the code 
found at http://www.incava.org/releases/1041874499.  The author licenses 
the code under the BSD license.  I don't know if it's standard practice 
or not to contact an author prior to pushing code to Maven, but 
unfortunately Jeff no longer lists any contact information on his web 
site - I have an email address for him that worked in 2006, so if you 
need to get in touch with him first let me know and I'll send it to you 
privately.

Ryan

[Jamwiki-devel] [POM improvement] Modifications in javadiff

[<jam...@li...>]

Hi folks,

has anything been modified in javadiff? I'd like to remove it completely
from the JAMWiki source code and issue a upload request to Maven Central.
The reason for this has been depicted by me here [1].

Mike

[1]
http://jamwiki.org/wiki/en/Bug_Reports#javadiff_breaks_build_process_under_certain_circumstances

[Jamwiki-devel] [POM improvement] Modifications in javadiff

[<jam...@li...>]

Hi folks,

has anything been modified in javadiff? I'd like to remove it completely 
from the JAMWiki source code and issue a upload request to Maven Central.
The reason for this has been depicted by me here [1].

Mike

[1] 
http://jamwiki.org/wiki/en/Bug_Reports#javadiff_breaks_build_process_under_certain_circumstances

[Jamwiki-devel] Mailinglist in Action

[<jam...@li...>]

should work now