Re: Packaging JSPWiki (Re: [Recalled] RFS: libservlet2.4-java (supersedes libservlet2.3-java))
On Sat, Jul 24, 2010 at 4:45 PM, Niels Thykier <niels@thykier.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 2010-07-22 18:52, Onkar Shinde wrote:
>> On Fri, Jul 9, 2010 at 4:38 PM, Niels Thykier <niels@thykier.net> wrote:
>> <snip>
>>> [...]
>>
>> I deployed jspwiki at work for our team's internal use. So I am still
>> exploring it.
>
>
> Hey,
>
> Good to hear, I have no practical experience with this package. :)
>
> I noticed that jspwiki is moving to Apache and that 2.8.4 is tagged on
> their (new) SVN, so I have upgraded that on the git.
As per their wiki JSPWiki will become official Apache package only
with 3.0 version. But I don't think that makes much difference for us.
>> What I found out that jrcs used to be a component of Apache Commons
>> project. But it is now moved to codehaus. [1] But looking at the
>> project on codehaus [2] it is clear that the project is not being
>> maintained at all.
>>
>> Looking at some pages on jspwiki wiki it seems that jrcs is not being
>> used now and the old rcs mechanism is deprecated. [3] The wiki also
>> states that java's internal diff routines are being used now. So it
>> should be possible to get read of jrcs. I will check at work tomorrow
>> to see what page versioning mechanism is used by default.
>>
>>
>> [1] https://svn.apache.org/repos/asf/commons/dormant/jrcs/trunk/STATUS.html
>> [2] http://xircles.codehaus.org/projects/jrcs
>> [3] http://www.jspwiki.org/wiki/RCSFileProvider
>>
>
> JSPWiki has a funny way of deprecating things -> removal of jrcs means
> that we have to discard src/com/ecyrd/jspwiki/filters/SpamFilter.java
> (or heavily patch it).
Apologies that I spoke too early. jrcs is not used by RCSFileProvider
at all. Rather it is used by diff providers and spam filter as you
noted.
> On the git I have decided to build without it for now, but I think we
> should re-enable it before uploading because the SpamFilter appears to
> be responsible for validating users or at least rejecting some of them[1].
Correct.
> Since upstream also uses tests/lib as classpath it turns out that we
> need net.sourceforge.stripes.util, which appears to be some Base64
> encoding/decoding stuff. That or disable the "Exporter". For now the
> build fails due to this issue.
>
> Here is a list of things we build without plus why/what we need to
> enable it:
>
> com/ecyrd/jspwiki/rpc/atom:
> Needs org.intabulas.sandle
>
> org/apache/commons/jrcs,
> com/ecyrd/jspwiki/diff/ContextualDiffProvider.java
> com/ecyrd/jspwiki/diff/TraditionalDiffProvider.java
> com/ecyrd/jspwiki/filters/SpamFilter.java:
> Due to "deprecated" jrcs-diff.
As I said jrcs is not deprecated. I was mistaken about that.
> com/ecyrd/jspwiki/xmlrpc:
> org.apache.xmlrpc.AuthenticationFailed cannot be found
> (tried all 3 libmlrpc3-*-java packages)
xmlrpc has changed package names and class names between 2.x and 3.x.
The closes I could find that sounds similar is
org.apache.xmlrpc.common.XmlRpcNotAuthorizedException in
/usr/share/java/xmlrpc-common-3.1.jar.
> Note: the removal of the diff providers means that we currently have to
> use ExternalDiffProvider (using the diff command); I am not sure it is
> set up correctly for that.
This will need us to patch the source to provide default diff command,
make ExternalDiffProvider the only one available. These things could
be mentioned in README.Debian.
> There should be a different diff provider[2] as well, but I am not
> sure how to enable it. It looks to me as if it is in the wrong package
> for it to be loaded. Admittedly I did not dig too deep into it.
RCSFileProvider is not a diff provider. It is mechanism to maintain
versions of the page. It is deprecated and VersioningFileProvider is
the default provider as I found out from my office installation.
I will try to put some time in the package over weekend.
Onkar
--
Passion - Some people climb mountains - others write Free software.
Don't ask why - the reason is the same.
Reply to: