On Tue, Apr 14, 2009 at 07:30, Ashish <[email protected]> wrote:
>> Vysper has it's own naive pull parser implementation. See packages
>> o.a.vysper.mina
>> o.a.vysper.mina.codec
>> o.a.vysper.xmpp.decoder
>> o.a.vysper.xmpp.fragment
>>
>> No third party lib I looked at in 2007 worked for me.
>
> Have seen that. Infact, my first XML decoder was very similar.
> Check out this thread
> http://www.nabble.com/Continuous-XML-document-processing-td20802789.html#a20802789
>
> Openfire has similar implementation.
>
> Thinking about multiple implementations of XML Decoders, basically
> using different parsers.
> have it for XPP3, woodstox shall be ready guess by today (if time
> permits). Then we can try with
> JiBX, XStream etc
>
>
>> :-) Well, I can understand that. As soon as you take a closer look,
>> though, that's actually an advantage of XMPP: Being very modular on
>> the spec side, too.
>> The RFCs are big, but the XEPs are usually pretty handy.
>
> Well now you understand XMPP, so will take your help on this :-)
>
> One biggest TODO, is to migrate the code from MINA 1.1.0 to MINA 2.0
> A lot has changed since then.
I you or anybody else is happy to dive into it, go ahead. Every ASF
committer has Labs commit access... ;-)
> Couple of test cases related to Presence are failing.
Yes, see JIRA LABS-340. In progress.
> Regarding Spec package, was able to generate the report :-)
> Changed this apt-classpath
>
> <path id="apt-classpath">
> <path refid="classpath" />
> <pathelement location="${vysper.output.dir}" />
> <pathelement location="${java.home}/lib/" />
> </path>
>
> and here is the modified target
> <target name="generate-compliance-doc" description="generates the
> compliance document" >
> <apt
> factory="org.apache.vysper.compliance.reporting.DocumentSpecCompliantAnnotationFactory"
> debug="false" verbose="true"
> preprocessdir="${basedir}/build/ant/apidocs"
> compile="false">
> <classpath refid="apt-classpath" />
> <src refid="sourcepath"/>
> </apt>
> </target>
>
> See if it works for you.
Great! Now it works! Thanks.
Is this contributed, ASL-licensed code? ;-)
> For the compliance package, my expectation shall be a little
> different. We need to generate a summary report, which states what all
> we comply to, like a simple pdf. Users can pick it up and can see the
> compliance easily, rather than browsing all javadocs. Javadocs shall
> still retain this information.
+1. That'd be a goal for improvement. The current idea is to have an
easy pointer where in code to find the implementation(s) for a
specific part of the spec (you already mentioned it, the RFCs are big
:-). Some section you'd probably never implement, sometimes you have
to go down to paragraph- or bullet point-level granularity.
> I guess turning them into JIRA will make things more manageable and we
> can get a better picture of tasks at hand.
Ok, I'll take that todo.
Bernd
