> 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.

Couple of test cases related to Presence are failing.

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.

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.

I guess turning them into JIRA will make things more manageable and we
can get a better picture of tasks at hand.

wdyt?

thanks
- ashish

Reply via email to