2007/3/7, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>:
I was finally able to checkout the source and have a look into it. To be
honest, I'm a little bit worried about it.
There is no distinction between API and internal code.
Some classes seem to exist twice in different packages (for example,
org.eclipse.ecf.provider.jxta.JXTAClient.java) They look similar but
they aren't. This is really confusing.
I have to clean up code , yes
There is obviously a lot of code that should be refactored into its own
plug-in (for example, the complete chat package). I mean, JXTA is not
only about chat, isn't it?
The whole container is in org.eclipse.ecf.provider.jxta
chat classes are not part of container, just here as helper code
The plug-in doesn't compile out of the box because its classpath is
broken. I get an error message saying "Project
org.eclipse.ecf.provider.jxta is missing required library: 'bin'". Looks
like you got come weird classpath setup there.
Have you updated recently ? It's fixed now
I'm missing some Javadoc comments at least for the main API classes
about what they do and how to use them. Together with the huge amount of
code that is laying around there and doesn't seem to be used it makes it
really hard to understand it. It would be nice if someone can point me
to some documentation that describes the architecture of this plug-in.
I will doc it, I promise
I also wonder why it needs the Servlet API and Jetty.
It's used by the core jxta, and the main reason is for EPL licensing
I intended to use JXTA for remote communication (remote services),
sharing objects and distributing tasks/jobs to remote workers (see
jngi.jxta.org). But I really wonder if the JXTA provider will support
this or was only developed as a chat service.
You can register any service you implement as a JXTA service and publish using the container.
I will soon make a sample of how to do that.
If you could launch the jxta.rcpexample app - as others guys from this list, it would help to debug the container.