You'll need to include several jars from the third_party dir. For example, the error about "Nullable" can be resulved by including the contents of "third_party\runtime\jsr305\jsr305-src.jar" in your jar. Also, you are including too much source files in your jar. You need to exclude all of "proto_src". Yo also need to exclude any source files not covered by a gwt.xml file.
-Tad On Tue, Jun 15, 2010 at 6:23 AM, alona.oz <[email protected]> wrote: > Hi! > > I am new in all related to wave development and rich editor usage. > I've just checked out the code of fedone and the rich editor. I try > now to use the rich editor, but the provided build doesn't create any > GWT jar file that I can use in my project. So far I tried to create > the jar that includes all GWT code and modules XML files and use it in > my project, but when I compile my project with created jar I receive a > lot of dependency errors, so probably I am doing something wrong. Do > you have any idea what's wrong? Or how can I can use rich editor and > wave model (for GWT) in my project? > > Thanks. > > Here is my target for jar file: > > <target name="gwt_jar" > depends="compile,proto_compile,proto_gwt_compile"> > <!--create jar file --> > > <jar destfile="${gwt.classes}/gwt.jar"> > <fileset dir="${gwt.classes}"> > <include name="**/*.class"/> > </fileset> > <fileset dir="${core.classes}"> > <include name="**/*.class"/> > </fileset> > <fileset dir="proto_src"> > <include name="**/*.java"/> > <include name="**/*.xml"/> > </fileset> > <fileset dir="src"> > <include name="**/*.java"/> > <include name="**/*.xml"/> > </fileset> > <fileset dir="proto_gwt_src"> > <include name="**/*.java"/> > <include name="**/*.xml"/> > </fileset> > <fileset dir="gwt_src"> > <include name="**/*.java"/> > <include name="**/*.xml"/> > </fileset> > </jar> > </target> > > I receive the following when I try to use the jar file in my project: > > [ERROR] Errors in 'jar:file:/C:/Downloads/Wave-Devel-io2010/wave- > protocol/build/gwt/gwt.jar!/org/waveprotocol/wave/model/util/ > Preconditions.java' > [ERROR] Line 22: The import javax.annotation cannot be > resolved > [ERROR] Line 112: Nullable cannot be resolved to a type > > [ERROR] Errors in 'jar:file:/C:/Downloads/Wave-Devel-io2010/wave- > protocol/build/gwt/gwt.jar!/org/waveprotocol/wave/federation/ > FederationErrorProto.java' > [ERROR] Line 12: No source code is available for type > com.google.protobuf.GeneratedMessage; did you forget to inherit a > required module? > [ERROR] Line 33: No source code is available for type > com.google.protobuf.GeneratedMessage.FieldAccessorTable; did you > forget to inherit a required module? > [ERROR] Line 39: No source code is available for type > com.google.protobuf.ProtocolMessageEnum; did you forget to inherit a > required module? > > > On Jun 10, 9:57 am, Dan <[email protected]> wrote: > > Sure, you can just provide a different DocumentSchema. You'll have to > > register renderers and event handlers for the various types of > > elements you plan to support. The reason we use <line> tags is so that > > the operational transform behavior gives a slick collaborative editing > > experience. And, also, so we don't have to worry about what it means > > to edit HTML with random position absolute divs etc as part of the > > editable content - though you said you have a strict XML schema. > > > > The editor itself is basically an event router. The model is > > arbitrary, and semantic. All the functionality, from paragraphs, > > bullets, headings, to gadgets, image thumbnails, spell annotations, > > and so forth is defined as a set of renderers and event handlers that > > you register against different element and annotation types. So you > > could have, e.g., a <my-widget> element with its own schema defining > > its state, and render that to arbitrarily complex HTML. The purpose of > > our editor is to give you great control and flexibility over your > > model, and confidence that your HTML rendering won't turn into a > > mangled mess as often happens with vanilla HTML text editors. > > > > If you want to inter-operate with wave, you must use our schema. > > Though we plan on fixing this, so people will be able to define their > > own. If you're just using the editor, you can go ahead and define > > whatever schema and rendering behaviors you wish. > > > > As part of open sourcing, we've also released a bunch of basic > > behaviors which you can find inside the editor.content package. For > > example, the editor.content.paragraph package contains the logic for > > rendering self-closing <line/> tags, with content following, to > > regular <p> tags in the html with contained content. I'm skipping over > > a bunch of details, but the rough flow is like this: > > * LineContainerParagraphiser (great name I know) converts <line> > > elements into local <l:p> elements within the model (the document > > supports "local" nodes that are not represented by operations. This is > > similar to the shadow dom used by browsers like webkit to render > > widgets from simple html). This is an intermediate step, purely for > > convenience. > > * ParagraphRenderer renders the <l:p> elements in the model to <p> > > elements in the HTML > > * LocalParagraphEventHandler handles behavior like what happens when > > the user presses enter. In that example, it would create a <line/> > > element at the given location, which would then be rendered > > accordingly. > > For a much simpler example, see ImgDoodad which basically defines a > > very html-like <img> element. > > > > We used to use regular <p> elements in our model as well. If you want > > to do this (say if your model is more HTML-like), then you could use > > ParagraphRenderer or something very similar to it, and the unused > > class ParagraphEventHandler which is a remnant from our old ways of > > doing things. It throws UnsupportedOperationException in some places > > where you'd need to fill in the gaps, but you get the idea. > > > > Unfortunately the only documentation of how renderers and event > > handlers work is in the code. We should fix this. I hope the above is > > helpful as a starting point regardless. > > > > Dan > > > > On Jun 10, 12:44 am, Jason Terk <[email protected]> wrote: > > > > > > > > > Dan, > > > > > Thanks for your response, it was most certainly helpful. One thing, > however, > > > isn't yet clear for me: is there a way to use a different schema for > the > > > editor? It looks to me like the editor expects documents using the > <line/> > > > tag for line separators and outputs the same. I need to be able to > process > > > arbitrary HTML - the editable content is not necessarily coming from my > > > application's editor (although it does conform to a strict XML schema, > if > > > that helps). > > > > > Thanks again, > > > -Jason Terk- Hide quoted text - > > > > - Show quoted text - > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
