jtidy-devel — JTidy mailing list for developers

[Jtidy-devel] [ jtidy-Bugs-1029155 ] org.w3c.tidy.DOMNodeImpl does not work with cocoon 2.1.5

[SourceForge.net <no...@so...>]

Bugs item #1029155, was opened at 2004-09-16 05:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1029155&group_id=13153

Category: DOM Support
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: org.w3c.tidy.DOMNodeImpl does not work with cocoon 2.1.5

Initial Comment:
after installing r8-snapshot-13sep in place of old r7 
version i'm unable to run jtidy at all

HTMLGenerator class utilizing jtidy [included below] 
crashes [log output below]
i browsed the error/failure list, and saw many DOM 
related problems, but not one exact as this

my java knowledge is to small to judge what is the 
reason, but i thought i should mention it, as i see not 
many people uses cocoon with jtidy and it might go 
unnoticed

my mail adress:
przymkow[_at_]netventure.pl

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1029155&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1027375 ] getParseErrors() and getParseWarnings() are 0

[SourceForge.net <no...@so...>]

Bugs item #1027375, was opened at 2004-09-13 13:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1027375&group_id=13153

Category: Tidy functionality
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vlad Skarzhevskyy  (vlads)
Assigned to: Nobody/Anonymous (nobody)
Summary: getParseErrors() and getParseWarnings() are 0

Initial Comment:
jtidy-r8-SNAPSHOT-src.zip    10-Sep-2004 10:07

I'm using Tidy to validate the pages created by JSPs.

In the build from August it was working fine.
now Nightly builds has getParseWarnings 0 all the time.

This is part of my code:

Tidy tidy = new Tidy();
        tidy.setQuiet(true);
	    tidy.setSmartIndent(false);
        tidy.setIndentContent(false);
        tidy.setHideEndTags(true);
        tidy.setTabsize(1);

ByteArrayOutputStream mesage_buffer = new 
ByteArrayOutputStream();
        
        PrintWriter pw = new PrintWriter(mesage_buffer);
        tidy.setErrout(pw);

tidy.parse(in, null);

System.out.println(tidy.getParseWarnings());


PS
 Also I'm goind to make Filter that could be included to 
any project to validate or change the JSP output for 
example on Tomcat.

 Do you think it would be valuable contribution to the 
project?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1027375&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-658665 ] it dose not support BIG5(MS950) encoding

[SourceForge.net <no...@so...>]

Feature Requests item #658665, was opened at 2002-12-26 14:03
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=658665&group_id=13153

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: fabrizio giustina (fgiust)
Summary: it dose not support BIG5(MS950) encoding

Initial Comment:
well~~
i come from taiwan
i want to parse chinese HTML pages by jtidy but doesn't support big5
will it support big5 or other western language ecncoding ?
:)

----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-13 00:26

Message:
Logged In: YES 
user_id=798060

a new implementation of in/out classes using built-in java
character encoding support is now used by default by jtidy.
Will be released in r8

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2003-04-21 13:08

Message:
Logged In: NO 

you can setCharEncoding to raw. i do it success in gbk

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=658665&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-646539 ] More control over warnings and errors

[SourceForge.net <no...@so...>]

Feature Requests item #646539, was opened at 2002-12-01 18:40
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=646539&group_id=13153

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Mark Diekhans (diekhans)
Assigned to: fabrizio giustina (fgiust)
Summary: More control over warnings and errors

Initial Comment:
When using JTidy as a parser it is not always desirable to
have it modify the document, as the results can be
difficult for the user to predict.   It would be very useful
to be able to have control over what is considered a
warning vs an error.  A plugable error handler, in place
of the static Report class, would be one way to implement
this.   Since are individually identified by a constant,
the error handler could make the decision on warning
vs error.   Optionally preventing modification of the
internal representation of document would also be useful.

----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-13 00:26

Message:
Logged In: YES 
user_id=798060

Now you can attach a message listener to tidy to be notified
for warning or errors. Note that Tidy internally needs to
fix bad documents in order to produce a parseable tree (so
you will be notified, but you can't disable this behaviour)

----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-04-02 23:52

Message:
Logged In: YES 
user_id=798060

a jtidy error handler will be added in r8. Part of the work is 
already done in CVS, but not yet completed

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=646539&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-532445 ] check

[SourceForge.net <no...@so...>]

Feature Requests item #532445, was opened at 2002-03-20 13:42
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=532445&group_id=13153

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Marcel Huijkman (mhuijkman)
>Assigned to: fabrizio giustina (fgiust)
Summary: check

Initial Comment:
I would like to know what tidy would change, or find as an error, 
before it changes my code.
This would be a kind of validator 
function.

----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-13 00:23

Message:
Logged In: YES 
user_id=798060

Now you can attach a message listener to tidy to be notified
for any warning or errors. After that, you can decide if you
want to write the output back to the file or not

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=532445&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-460882 ] Add JDK supported encodings

[SourceForge.net <no...@so...>]

Feature Requests item #460882, was opened at 2001-09-12 15:37
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=460882&group_id=13153

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Hideo Takahashi (hideo-t)
>Assigned to: fabrizio giustina (fgiust)
Summary: Add JDK supported encodings

Initial Comment:
I crafted a patch for JTidy to utilize
java.io.InputStreamReader and
java.io.OutputStreamWriter classes to increase
supported encodings to everything that JDK supports. 
The modification will cause a lot of the existing
encoding handling code that handles iso-2022 stuff to
be bypassed.  Sorry for that.

Since I am a casual visitor to this project, I will
attach a zip archive of the files I modified and leave
it to the core developers to decide if they want to
incorporate it or not in some reasonable fashion.

I was instructed in the forum to post a new 'feature
request' here so I am doing this and I am attaching the
files.

The modified version of JTidy worked fine for me on an
experimental proxy server that does some xslt work on
html pages. Thanks for the nice tool!

----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-13 00:21

Message:
Logged In: YES 
user_id=798060

a new implementation of in/out classes using built-in java
character encoding support is now used by default by jtidy.
Will be released in r8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=460882&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-443234 ] Additional encodings

[SourceForge.net <no...@so...>]

Feature Requests item #443234, was opened at 2001-07-21 02:06
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=443234&group_id=13153

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: fabrizio giustina (fgiust)
Summary: Additional encodings

Initial Comment:

Microsoft CP1252 characters that aren't ISO-8859-1 often wind up in HTML as numeric character 
references, like — for a bullet.  JTidy treats these characters as if the document encoding 
was UTF-8.  This makes the bullet turn into a Unicode control character (MESSAGE WAITING).

I think, especially if Tidy's charset is set to LATIN1, that if a byte is not in Latin 1, it should be 
assumed to be CP1252 and converted to the proper Unicode character.

Also, why doesn't JTidy parse from a Readers and use InputStreamReaders internally so that a 
wider range of character encodings could be used?

----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-13 00:21

Message:
Logged In: YES 
user_id=798060

a new implementation of in/out classes using built-in java
character encoding support is now used by default by jtidy.
Will be released in r8

----------------------------------------------------------------------

Comment By: Gary L Peskin (garypeskin)
Date: 2001-07-23 04:41

Message:
Logged In: YES 
user_id=91501

The current version of Tidy does not support Cp1252, as you point out.  I think you meant • which is 
the character for a bullet.  This -is- a Latin1 (ie iso-8859-1) character.  It is, as you point out, the 
"message waiting" character so your second paragraph would be inapplicable.

I agree that Tidy should support Cp1252, as well as additional encodings.  I have moved this from the Bugs 
datatype to a Feature Request.  As far as using Readers, these get very confusing when interacting with 
the Tidy char-encoding attribute since Tidy would not have access to the char encoding embedded in the 
Reader.

After the next release of Tidy has been incorporated into JTidy,  we will look into enhancing the encoding 
support in JTidy.

Thanks for the suggestion.
Gary

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=443234&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-860984 ] Support Java character sets

[SourceForge.net <no...@so...>]

Feature Requests item #860984, was opened at 2003-12-16 14:38
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=860984&group_id=13153

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Chris Bitmead (chrisbitmead)
>Assigned to: fabrizio giustina (fgiust)
Summary: Support Java character sets

Initial Comment:
jtidy uses customized character set handling that is a
left over from the C++ implementation. With Java's much
more powerful built-in character set support, it is
missing out on a lot.

Here we have a new class that implements Java character
sets, inheriting from StreamIn. Jtidy wasn't really
designed to support this, but this is as neat as it can
be without changing much in jtidy....

package org.w3c.tidy;

import java.io.*;

public class JavaStreamIn extends StreamIn {
	InputStreamReader isr;

	public JavaStreamIn(InputStream stream, String
encoding) throws UnsupportedEncodingException {
		this.stream = stream;
		isr = new InputStreamReader(stream, encoding);
	}

	public int readCharFromStream() {
		try {
			int rtn = isr.read();
			if (rtn < 0) {
				endOfStream = true;
			}
			return rtn;
		} catch (IOException e) {
			e.printStackTrace();
			endOfStream = true;
			return -1;
		}
	}

	public int readChar() {
		if (pushed) {
			pushed = false;
			return c;
		} else {
			return readCharFromStream();
		}
	}

	public void ungetChar(int c) {
		pushed = true;
		this.c = c;
	}

	public boolean isEndOfStream() {
		return endOfStream;
	}

}

Now we modify the Configuration class...
	protected String javaCharset = null;    /* Java
Character set decoder */

Now, in the parseProps function....

		value = _properties.getProperty("java-charset");
		if (value != null)
			javaCharset = parseName(value, "java-charset");

Now in the Tidy class itself we add....

	public void setJavaCharset(String charset)
	{
		configuration.javaCharset = charset;
	}

	public String getJavaCharset()
	{
		return configuration.javaCharset;
	}

And in the Tidy.parse function we change it to....

	StreamIn sii = null;
	if (getJavaCharset() != null) {
		sii = new JavaStreamIn(in, getJavaCharset());
	} else {
		sii = new StreamInImpl(in,
                     configuration.CharEncoding,
                       configuration.tabsize);
	}

Now, if we do a Tidy.setJavaCharset("CharSetName");

Jtidy will use Java charsets for input. Otherwise it
uses the old jtidy mechanism.














----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-13 00:20

Message:
Logged In: YES 
user_id=798060

a new implementation of in/out classes using built-in java
character encoding support is now used by default by jtidy.
Will be released in r8

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=860984&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1020806 ] NPE when PPPrint'ing changed DOM tree

[SourceForge.net <no...@so...>]

Bugs item #1020806, was opened at 2004-09-02 01:07
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

Category: DOM Support
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: fabrizio giustina (fgiust)
Summary: NPE when PPPrint'ing changed DOM tree

Initial Comment:
I get a NPE when printing a DOM tree I changed.  I
traced it down to the 'lexer' variable being null at
PPrint.class, method pprintTree (sorry, lost the stack
trace).  Can't seem to 

ByteArrayOutputStream modifiedContent = new
ByteArrayOutputStream(clipping.getContent().length());
Tidy parser = new Tidy();
Document node = parser.parseDOM(new
ByteArrayInputStream(content.getBytes()), null);
processNode(contentURI, node);
parser.pprint(node, modifiedContent);



----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-10 13:59

Message:
Logged In: YES 
user_id=798060

another testcase added and fixed in CVS. The bug was related
to content of script elements; please always provide a
document showing the error while reporting bugs to help
creating a valid testcase.

(BTW, all occurrences of lexer.lexbuf in pprint have been
replaced with node textarray as appropriate)

----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-07 21:47

Message:
Logged In: YES 
user_id=269024

Different area and probably slightly different error:
----
...
java.lang.NullPointerException
	java.lang.String.checkBounds(String.java:286)
	java.lang.String.<init>(String.java:319)
	org.w3c.tidy.Lexer.getString(Lexer.java:575)
	org.w3c.tidy.PPrint.hasCDATA(PPrint.java:1781)
	org.w3c.tidy.PPrint.printScriptStyle(PPrint.java:1848)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2122)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2021)
	org.w3c.tidy.Tidy.pprint(Tidy.java:1676)
	org.w3c.tidy.Tidy.pprint(Tidy.java:1634)
        ....DefaultRetriever.retrieve(DefaultRetriever.java:100)
-----

  The problem is still the same, it is trying to use the
Lexer for deciding on an input that is null (unless JTidy is
setting it). This is being called on a modified document, so
I'm calling pprint directly.  I've changed the code in a
couple of functions to test if lexer.lexbuf was not null,
seems to be working for now.


----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-03 00:02

Message:
Logged In: YES 
user_id=798060

testcase added and fixed in cvs (along with other related
problems when pprinting a doctype changed by tidy).


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 17:50

Message:
Logged In: YES 
user_id=269024

There we go, more info:
this is the piece of code that throws the exception:

// #603128 tidy adds newslines after </html> tag
// Fix by Fabrizio Giustina 12-02-2004
// fix is different from the one in original tidy
if (!lexer.seenEndHtml)
{
	flushLine(fout, indent);
}

It throws a NPE because Tidy.pprint invokes the method with
an explicit null as the argument for the lexer, as seen
below (its reformatted to use less space here):

/**
 * Pretty-prints a tidy Node.
 * @param node org.w3c.tidy.Node
 * @param out output stream
 */
private void pprint(Node node, OutputStream out) {
	Out o = new OutImpl(this.configuration);
	PPrint pprint;
	o.setState(StreamIn.FSM_ASCII);
	o.setEncoding(configuration.outCharEncoding);
	if (out != null) {
		pprint = new PPrint(configuration);
		o.setOut(out);
		if (configuration.xmlTags) {
			pprint.printXMLTree(o, (short) 0, 0, null, node);
		} else {
			pprint.printTree(o, (short) 0, 0, null, node);
		}
		pprint.flushLine(o, 0);
	}
}

For now I'm going to change the lines locally on the PPrint
class to:
if ((lexer != null) && !lexer.seenEndHtml)
{
    flushLine(fout, indent);
}

That should solve the NPE, but I don't know about the bug
#603128 annotated before that code.


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 17:37

Message:
Logged In: YES 
user_id=269024

Here is the stack trace.  The version is the 30/Aug/03
snapshot. 


java.lang.NullPointerException
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2257)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2021)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1669)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1626)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetriever.retrieve(DefaultRetriever.java:100)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetrieverTest.testCompleteClipping(DefaultRetrieverTest.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1024661 ] Error Parsing duplicate style

[SourceForge.net <no...@so...>]

Bugs item #1024661, was opened at 2004-09-08 22:43
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1024661&group_id=13153

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Vlad Skarzhevskyy  (vlads)
>Assigned to: fabrizio giustina (fgiust)
Summary: Error Parsing duplicate style

Initial Comment:
try to pars this not valid HTML:

<table style="font-size: 1pt" style="font-size: 1pt">
<tr>
   <td>...</td>
</tr>
</table>

Got this Exception:

java.lang.StringIndexOutOfBoundsException: String 
index out of range: 14
     at java.lang.String.charAt(String.java:444)
     at org.w3c.tidy.Node.repairDuplicateAttributes
(Node.java:420)
     at org.w3c.tidy.Lexer.getToken(Lexer.java:2469)
     at org.w3c.tidy.ParserImpl$ParseBlock.parse
(ParserImpl.java:2047)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseRow.parse
(ParserImpl.java:3015)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseTableTag.parse
(ParserImpl.java:2613)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseBlock.parse
(ParserImpl.java:2459)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseRow.parse
(ParserImpl.java:3015)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseTableTag.parse
(ParserImpl.java:2613)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseBlock.parse
(ParserImpl.java:2459)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseRow.parse
(ParserImpl.java:3015)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseTableTag.parse
(ParserImpl.java:2613)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseBody.parse
(ParserImpl.java:971)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseHTML.parse
(ParserImpl.java:477)
     at org.w3c.tidy.ParserImpl.parseDocument
(ParserImpl.java:3388)
     at org.w3c.tidy.Tidy.parse(Tidy.java:1350)
     at org.w3c.tidy.Tidy.parse(Tidy.java:1240)

----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-10 13:39

Message:
Logged In: YES 
user_id=798060

testcase added and fixed in CVS
thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1024661&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-1021346 ] Maven not working

[SourceForge.net <no...@so...>]

Feature Requests item #1021346, was opened at 2004-09-02 19:50
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

Category: None
Group: None
>Status: Pending
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: fabrizio giustina (fgiust)
Summary: Maven not working

Initial Comment:
  Plese consider rolling back to whatever previous
build process you had.  Maven might work for you in
your local environment, but it's quite pesky to setup
anywhere else.  I had to download & install (instead of
just unzipping).  Then I got all sorts of broken link
problems with many dependencies, like the FindBugs
plugin, clover, etc.  I tried downloading the
dependencies, it doesn't seem to find them anywhere, I
tried the lib dir in the main Maven install dir, I
tried putting it in the project dir (which makes no
sense to me).  Finally I removed the links to FindBugs
and put clover everywhere.  It seemed to compile fine,
but then I got a huge stacktrace for a plugin that I
don't think I touched:

BUILD FAILED
com.werken.werkz.NoSuchGoalException: No goal
[maven-xhtml-plugin:register]
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:190)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)


BOTTOM-LINE:
  Maven sucks.  Please consider a simple ant file or
even a shell script!



----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-10 14:37

Message:
Logged In: YES 
user_id=798060

ok, got it. You obviously were using the downloadable source
snapshot: I found that the checkstyle.xml file was not
included there.
I'm fixing the build script to include the checkstyle rule
file. You can test it as soon as a new snapshot build is
produced (please note that due to problems on sourceforge
compile farm servers nightly snapshot have not been produced
in the latest days)

I'm sure everything will work fine and you will enjoy maven
now ;)


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-07 21:27

Message:
Logged In: YES 
user_id=269024

Same:

----
... lots and lots...

license:transfer:

license:


    [echo] Generating the Checkstyle...
checkstyle:init:

checkstyle:report:
checkstyle:run:
    [echo] Using file:checkstyle.xml for checkstyle ...

BUILD FAILED
Unable to create a Checker: unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:319)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.execute(CheckStyleTask.java:259)
        at org.apache.tools.ant.Task.perform(Task.java:341)
        at
org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634)
        at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:266)
        at org.apache.maven.cli.App.doMain(App.java:486)
        at org.apache.maven.cli.App.main(App.java:1215)
        at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at com.werken.forehead.Forehead.run(Forehead.java:551)
        at com.werken.forehead.Forehead.main(Forehead.java:581)
Caused by:
com.puppycrawl.tools.checkstyle.api.CheckstyleException:
unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:253)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:291)
        ... 78 more
Caused by: java.io.FileNotFoundException: checkstyle.xml
(The system cannot find the file specified)
        at java.io.FileInputStream.open(Native Method)
        at
java.io.FileInputStream.<init>(FileInputStream.java:106)
        at
java.io.FileInputStream.<init>(FileInputStream.java:66)
        at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69)
        at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156)
        at java.net.URL.openStream(URL.java:913)
        at
com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:241)
        ... 79 more
--- Nested Exception ---
com.puppycrawl.tools.checkstyle.api.CheckstyleException:
unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:253)
... lots more...


----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-04 19:57

Message:
Logged In: YES 
user_id=798060

uhm... the checkstyle file is there and I can't understand
the reason for this error.
I've tried changing the checkstyle rule file in
project.properties to:
maven.checkstyle.properties=${basedir}/checkstyle.xml
and forcing the build to use version 2.4.1 of the plugin
(added in dependencies)

Could you give it another try and see if everything works now? 


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-03 18:51

Message:
Logged In: YES 
user_id=269024

Hey! Seems to be working a lot better.  It generated the
.jar file, which is what I needed.   Just for the purposes
of documentation, it still failed on the checkstyle task.

checkstyle:run:
    [echo] Using file:checkstyle.xml for checkstyle ...

BUILD FAILED
Unable to create a Checker: unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:319)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.execute(CheckStyleTask.java:259)
        at org.apache.tools.ant.Task.perform(Task.java:341)
        at
org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)

----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-02 23:05

Message:
Logged In: YES 
user_id=798060

if you are used to ant maven probably requires some time at
the begininning, bu it's a lot more than a simple build tool...

I now checked the dependencies and update them to only use
versions available on maven central repository (or in other
repositories added to project.properties), to simplify the
project setup.
It should work fine, just download and unzip maven 1.0 (no
need to install anything) and run it with a working internet
connection. All the dependencies should be resolved, please
report here any addictional problem.

I will also add back to the source distribution a plain
build.xml (maven generated) for ant users.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1024661 ] Error Parsing duplicate style

[SourceForge.net <no...@so...>]

Bugs item #1024661, was opened at 2004-09-08 16:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1024661&group_id=13153

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Vlad Skarzhevskyy  (vlads)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error Parsing duplicate style

Initial Comment:
try to pars this not valid HTML:

<table style="font-size: 1pt" style="font-size: 1pt">
<tr>
   <td>...</td>
</tr>
</table>

Got this Exception:

java.lang.StringIndexOutOfBoundsException: String 
index out of range: 14
     at java.lang.String.charAt(String.java:444)
     at org.w3c.tidy.Node.repairDuplicateAttributes
(Node.java:420)
     at org.w3c.tidy.Lexer.getToken(Lexer.java:2469)
     at org.w3c.tidy.ParserImpl$ParseBlock.parse
(ParserImpl.java:2047)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseRow.parse
(ParserImpl.java:3015)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseTableTag.parse
(ParserImpl.java:2613)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseBlock.parse
(ParserImpl.java:2459)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseRow.parse
(ParserImpl.java:3015)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseTableTag.parse
(ParserImpl.java:2613)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseBlock.parse
(ParserImpl.java:2459)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseRow.parse
(ParserImpl.java:3015)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseTableTag.parse
(ParserImpl.java:2613)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseBody.parse
(ParserImpl.java:971)
     at org.w3c.tidy.ParserImpl.parseTag
(ParserImpl.java:197)
     at org.w3c.tidy.ParserImpl$ParseHTML.parse
(ParserImpl.java:477)
     at org.w3c.tidy.ParserImpl.parseDocument
(ParserImpl.java:3388)
     at org.w3c.tidy.Tidy.parse(Tidy.java:1350)
     at org.w3c.tidy.Tidy.parse(Tidy.java:1240)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1024661&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1020806 ] NPE when PPPrint'ing changed DOM tree

[SourceForge.net <no...@so...>]

Bugs item #1020806, was opened at 2004-09-01 23:07
Message generated for change (Comment added) made by hexsel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

Category: DOM Support
Group: None
>Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: fabrizio giustina (fgiust)
Summary: NPE when PPPrint'ing changed DOM tree

Initial Comment:
I get a NPE when printing a DOM tree I changed.  I
traced it down to the 'lexer' variable being null at
PPrint.class, method pprintTree (sorry, lost the stack
trace).  Can't seem to 

ByteArrayOutputStream modifiedContent = new
ByteArrayOutputStream(clipping.getContent().length());
Tidy parser = new Tidy();
Document node = parser.parseDOM(new
ByteArrayInputStream(content.getBytes()), null);
processNode(contentURI, node);
parser.pprint(node, modifiedContent);



----------------------------------------------------------------------

>Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-07 19:47

Message:
Logged In: YES 
user_id=269024

Different area and probably slightly different error:
----
...
java.lang.NullPointerException
	java.lang.String.checkBounds(String.java:286)
	java.lang.String.<init>(String.java:319)
	org.w3c.tidy.Lexer.getString(Lexer.java:575)
	org.w3c.tidy.PPrint.hasCDATA(PPrint.java:1781)
	org.w3c.tidy.PPrint.printScriptStyle(PPrint.java:1848)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2122)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	org.w3c.tidy.PPrint.printTree(PPrint.java:2021)
	org.w3c.tidy.Tidy.pprint(Tidy.java:1676)
	org.w3c.tidy.Tidy.pprint(Tidy.java:1634)
        ....DefaultRetriever.retrieve(DefaultRetriever.java:100)
-----

  The problem is still the same, it is trying to use the
Lexer for deciding on an input that is null (unless JTidy is
setting it). This is being called on a modified document, so
I'm calling pprint directly.  I've changed the code in a
couple of functions to test if lexer.lexbuf was not null,
seems to be working for now.


----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-02 22:02

Message:
Logged In: YES 
user_id=798060

testcase added and fixed in cvs (along with other related
problems when pprinting a doctype changed by tidy).


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 15:50

Message:
Logged In: YES 
user_id=269024

There we go, more info:
this is the piece of code that throws the exception:

// #603128 tidy adds newslines after </html> tag
// Fix by Fabrizio Giustina 12-02-2004
// fix is different from the one in original tidy
if (!lexer.seenEndHtml)
{
	flushLine(fout, indent);
}

It throws a NPE because Tidy.pprint invokes the method with
an explicit null as the argument for the lexer, as seen
below (its reformatted to use less space here):

/**
 * Pretty-prints a tidy Node.
 * @param node org.w3c.tidy.Node
 * @param out output stream
 */
private void pprint(Node node, OutputStream out) {
	Out o = new OutImpl(this.configuration);
	PPrint pprint;
	o.setState(StreamIn.FSM_ASCII);
	o.setEncoding(configuration.outCharEncoding);
	if (out != null) {
		pprint = new PPrint(configuration);
		o.setOut(out);
		if (configuration.xmlTags) {
			pprint.printXMLTree(o, (short) 0, 0, null, node);
		} else {
			pprint.printTree(o, (short) 0, 0, null, node);
		}
		pprint.flushLine(o, 0);
	}
}

For now I'm going to change the lines locally on the PPrint
class to:
if ((lexer != null) && !lexer.seenEndHtml)
{
    flushLine(fout, indent);
}

That should solve the NPE, but I don't know about the bug
#603128 annotated before that code.


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 15:37

Message:
Logged In: YES 
user_id=269024

Here is the stack trace.  The version is the 30/Aug/03
snapshot. 


java.lang.NullPointerException
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2257)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2021)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1669)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1626)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetriever.retrieve(DefaultRetriever.java:100)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetrieverTest.testCompleteClipping(DefaultRetrieverTest.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-1021346 ] Maven not working

[SourceForge.net <no...@so...>]

Feature Requests item #1021346, was opened at 2004-09-02 17:50
Message generated for change (Comment added) made by hexsel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: fabrizio giustina (fgiust)
Summary: Maven not working

Initial Comment:
  Plese consider rolling back to whatever previous
build process you had.  Maven might work for you in
your local environment, but it's quite pesky to setup
anywhere else.  I had to download & install (instead of
just unzipping).  Then I got all sorts of broken link
problems with many dependencies, like the FindBugs
plugin, clover, etc.  I tried downloading the
dependencies, it doesn't seem to find them anywhere, I
tried the lib dir in the main Maven install dir, I
tried putting it in the project dir (which makes no
sense to me).  Finally I removed the links to FindBugs
and put clover everywhere.  It seemed to compile fine,
but then I got a huge stacktrace for a plugin that I
don't think I touched:

BUILD FAILED
com.werken.werkz.NoSuchGoalException: No goal
[maven-xhtml-plugin:register]
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:190)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)


BOTTOM-LINE:
  Maven sucks.  Please consider a simple ant file or
even a shell script!



----------------------------------------------------------------------

>Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-07 19:27

Message:
Logged In: YES 
user_id=269024

Same:

----
... lots and lots...

license:transfer:

license:


    [echo] Generating the Checkstyle...
checkstyle:init:

checkstyle:report:
checkstyle:run:
    [echo] Using file:checkstyle.xml for checkstyle ...

BUILD FAILED
Unable to create a Checker: unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:319)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.execute(CheckStyleTask.java:259)
        at org.apache.tools.ant.Task.perform(Task.java:341)
        at
org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.IfTag.doTag(IfTag.java:88)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
        at com.werken.werkz.Goal.attain(Goal.java:573)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
        at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
        at com.werken.werkz.Goal.fire(Goal.java:639)
        at com.werken.werkz.Goal.attain(Goal.java:575)
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
        at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:634)
        at
org.apache.maven.MavenSession.attainGoals(MavenSession.java:266)
        at org.apache.maven.cli.App.doMain(App.java:486)
        at org.apache.maven.cli.App.main(App.java:1215)
        at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at com.werken.forehead.Forehead.run(Forehead.java:551)
        at com.werken.forehead.Forehead.main(Forehead.java:581)
Caused by:
com.puppycrawl.tools.checkstyle.api.CheckstyleException:
unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:253)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:291)
        ... 78 more
Caused by: java.io.FileNotFoundException: checkstyle.xml
(The system cannot find the file specified)
        at java.io.FileInputStream.open(Native Method)
        at
java.io.FileInputStream.<init>(FileInputStream.java:106)
        at
java.io.FileInputStream.<init>(FileInputStream.java:66)
        at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69)
        at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156)
        at java.net.URL.openStream(URL.java:913)
        at
com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:241)
        ... 79 more
--- Nested Exception ---
com.puppycrawl.tools.checkstyle.api.CheckstyleException:
unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.ConfigurationLoader.loadConfiguration(ConfigurationLoader.java:253)
... lots more...


----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-04 17:57

Message:
Logged In: YES 
user_id=798060

uhm... the checkstyle file is there and I can't understand
the reason for this error.
I've tried changing the checkstyle rule file in
project.properties to:
maven.checkstyle.properties=${basedir}/checkstyle.xml
and forcing the build to use version 2.4.1 of the plugin
(added in dependencies)

Could you give it another try and see if everything works now? 


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-03 16:51

Message:
Logged In: YES 
user_id=269024

Hey! Seems to be working a lot better.  It generated the
.jar file, which is what I needed.   Just for the purposes
of documentation, it still failed on the checkstyle task.

checkstyle:run:
    [echo] Using file:checkstyle.xml for checkstyle ...

BUILD FAILED
Unable to create a Checker: unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:319)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.execute(CheckStyleTask.java:259)
        at org.apache.tools.ant.Task.perform(Task.java:341)
        at
org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)

----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-02 21:05

Message:
Logged In: YES 
user_id=798060

if you are used to ant maven probably requires some time at
the begininning, bu it's a lot more than a simple build tool...

I now checked the dependencies and update them to only use
versions available on maven central repository (or in other
repositories added to project.properties), to simplify the
project setup.
It should work fine, just download and unzip maven 1.0 (no
need to install anything) and run it with a working internet
connection. All the dependencies should be resolved, please
report here any addictional problem.

I will also add back to the source distribution a plain
build.xml (maven generated) for ant users.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1022561 ] HTML in textarea

[SourceForge.net <no...@so...>]

Bugs item #1022561, was opened at 2004-09-05 09:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1022561&group_id=13153

Category: Tidy functionality
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Terence Jacyno (tjacyno)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTML in textarea

Initial Comment:
Applies to: jtidy2 - org.w3c.tidy.TagTable, revision 1.29

When parsing HTML containing a textarea field where a
user has entered HTML data, the textarea tag is closed
before the first markup element. The entered HTML
appears as regular HTML on the page.

The solution that seems to work best is to modify line
299 of the TagTable class so that ParserImpl.BLOCK is
used instead of ParserImpl.TEXT.

    new Dict("textarea", Dict.VERS_ALL, (Dict.CM_INLINE
| Dict.CM_FIELD), ParserImpl.BLOCK, null),

Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1022561&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-1021346 ] Maven not working

[SourceForge.net <no...@so...>]

Feature Requests item #1021346, was opened at 2004-09-02 19:50
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: fabrizio giustina (fgiust)
Summary: Maven not working

Initial Comment:
  Plese consider rolling back to whatever previous
build process you had.  Maven might work for you in
your local environment, but it's quite pesky to setup
anywhere else.  I had to download & install (instead of
just unzipping).  Then I got all sorts of broken link
problems with many dependencies, like the FindBugs
plugin, clover, etc.  I tried downloading the
dependencies, it doesn't seem to find them anywhere, I
tried the lib dir in the main Maven install dir, I
tried putting it in the project dir (which makes no
sense to me).  Finally I removed the links to FindBugs
and put clover everywhere.  It seemed to compile fine,
but then I got a huge stacktrace for a plugin that I
don't think I touched:

BUILD FAILED
com.werken.werkz.NoSuchGoalException: No goal
[maven-xhtml-plugin:register]
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:190)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)


BOTTOM-LINE:
  Maven sucks.  Please consider a simple ant file or
even a shell script!



----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-04 19:57

Message:
Logged In: YES 
user_id=798060

uhm... the checkstyle file is there and I can't understand
the reason for this error.
I've tried changing the checkstyle rule file in
project.properties to:
maven.checkstyle.properties=${basedir}/checkstyle.xml
and forcing the build to use version 2.4.1 of the plugin
(added in dependencies)

Could you give it another try and see if everything works now? 


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-03 18:51

Message:
Logged In: YES 
user_id=269024

Hey! Seems to be working a lot better.  It generated the
.jar file, which is what I needed.   Just for the purposes
of documentation, it still failed on the checkstyle task.

checkstyle:run:
    [echo] Using file:checkstyle.xml for checkstyle ...

BUILD FAILED
Unable to create a Checker: unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:319)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.execute(CheckStyleTask.java:259)
        at org.apache.tools.ant.Task.perform(Task.java:341)
        at
org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)

----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-02 23:05

Message:
Logged In: YES 
user_id=798060

if you are used to ant maven probably requires some time at
the begininning, bu it's a lot more than a simple build tool...

I now checked the dependencies and update them to only use
versions available on maven central repository (or in other
repositories added to project.properties), to simplify the
project setup.
It should work fine, just download and unzip maven 1.0 (no
need to install anything) and run it with a working internet
connection. All the dependencies should be resolved, please
report here any addictional problem.

I will also add back to the source distribution a plain
build.xml (maven generated) for ant users.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-1021346 ] Maven not working

[SourceForge.net <no...@so...>]

Feature Requests item #1021346, was opened at 2004-09-02 17:50
Message generated for change (Comment added) made by hexsel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

Category: None
Group: None
>Status: Open
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: fabrizio giustina (fgiust)
Summary: Maven not working

Initial Comment:
  Plese consider rolling back to whatever previous
build process you had.  Maven might work for you in
your local environment, but it's quite pesky to setup
anywhere else.  I had to download & install (instead of
just unzipping).  Then I got all sorts of broken link
problems with many dependencies, like the FindBugs
plugin, clover, etc.  I tried downloading the
dependencies, it doesn't seem to find them anywhere, I
tried the lib dir in the main Maven install dir, I
tried putting it in the project dir (which makes no
sense to me).  Finally I removed the links to FindBugs
and put clover everywhere.  It seemed to compile fine,
but then I got a huge stacktrace for a plugin that I
don't think I touched:

BUILD FAILED
com.werken.werkz.NoSuchGoalException: No goal
[maven-xhtml-plugin:register]
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:190)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)


BOTTOM-LINE:
  Maven sucks.  Please consider a simple ant file or
even a shell script!



----------------------------------------------------------------------

>Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-03 16:51

Message:
Logged In: YES 
user_id=269024

Hey! Seems to be working a lot better.  It generated the
.jar file, which is what I needed.   Just for the purposes
of documentation, it still failed on the checkstyle task.

checkstyle:run:
    [echo] Using file:checkstyle.xml for checkstyle ...

BUILD FAILED
Unable to create a Checker: unable to find file:checkstyle.xml
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.createChecker(CheckStyleTask.java:319)
        at
com.puppycrawl.tools.checkstyle.CheckStyleTask.execute(CheckStyleTask.java:259)
        at org.apache.tools.ant.Task.perform(Task.java:341)
        at
org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:232)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)

----------------------------------------------------------------------

Comment By: fabrizio giustina (fgiust)
Date: 2004-09-02 21:05

Message:
Logged In: YES 
user_id=798060

if you are used to ant maven probably requires some time at
the begininning, bu it's a lot more than a simple build tool...

I now checked the dependencies and update them to only use
versions available on maven central repository (or in other
repositories added to project.properties), to simplify the
project setup.
It should work fine, just download and unzip maven 1.0 (no
need to install anything) and run it with a working internet
connection. All the dependencies should be resolved, please
report here any addictional problem.

I will also add back to the source distribution a plain
build.xml (maven generated) for ant users.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1020806 ] NPE when PPPrint'ing changed DOM tree

[SourceForge.net <no...@so...>]

Bugs item #1020806, was opened at 2004-09-02 01:07
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

>Category: DOM Support
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
>Assigned to: fabrizio giustina (fgiust)
Summary: NPE when PPPrint'ing changed DOM tree

Initial Comment:
I get a NPE when printing a DOM tree I changed.  I
traced it down to the 'lexer' variable being null at
PPrint.class, method pprintTree (sorry, lost the stack
trace).  Can't seem to 

ByteArrayOutputStream modifiedContent = new
ByteArrayOutputStream(clipping.getContent().length());
Tidy parser = new Tidy();
Document node = parser.parseDOM(new
ByteArrayInputStream(content.getBytes()), null);
processNode(contentURI, node);
parser.pprint(node, modifiedContent);



----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-03 00:02

Message:
Logged In: YES 
user_id=798060

testcase added and fixed in cvs (along with other related
problems when pprinting a doctype changed by tidy).


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 17:50

Message:
Logged In: YES 
user_id=269024

There we go, more info:
this is the piece of code that throws the exception:

// #603128 tidy adds newslines after </html> tag
// Fix by Fabrizio Giustina 12-02-2004
// fix is different from the one in original tidy
if (!lexer.seenEndHtml)
{
	flushLine(fout, indent);
}

It throws a NPE because Tidy.pprint invokes the method with
an explicit null as the argument for the lexer, as seen
below (its reformatted to use less space here):

/**
 * Pretty-prints a tidy Node.
 * @param node org.w3c.tidy.Node
 * @param out output stream
 */
private void pprint(Node node, OutputStream out) {
	Out o = new OutImpl(this.configuration);
	PPrint pprint;
	o.setState(StreamIn.FSM_ASCII);
	o.setEncoding(configuration.outCharEncoding);
	if (out != null) {
		pprint = new PPrint(configuration);
		o.setOut(out);
		if (configuration.xmlTags) {
			pprint.printXMLTree(o, (short) 0, 0, null, node);
		} else {
			pprint.printTree(o, (short) 0, 0, null, node);
		}
		pprint.flushLine(o, 0);
	}
}

For now I'm going to change the lines locally on the PPrint
class to:
if ((lexer != null) && !lexer.seenEndHtml)
{
    flushLine(fout, indent);
}

That should solve the NPE, but I don't know about the bug
#603128 annotated before that code.


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 17:37

Message:
Logged In: YES 
user_id=269024

Here is the stack trace.  The version is the 30/Aug/03
snapshot. 


java.lang.NullPointerException
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2257)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2021)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1669)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1626)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetriever.retrieve(DefaultRetriever.java:100)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetrieverTest.testCompleteClipping(DefaultRetrieverTest.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-1021346 ] Maven not working

[SourceForge.net <no...@so...>]

Feature Requests item #1021346, was opened at 2004-09-02 19:50
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

Category: None
Group: None
>Status: Pending
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
>Assigned to: fabrizio giustina (fgiust)
Summary: Maven not working

Initial Comment:
  Plese consider rolling back to whatever previous
build process you had.  Maven might work for you in
your local environment, but it's quite pesky to setup
anywhere else.  I had to download & install (instead of
just unzipping).  Then I got all sorts of broken link
problems with many dependencies, like the FindBugs
plugin, clover, etc.  I tried downloading the
dependencies, it doesn't seem to find them anywhere, I
tried the lib dir in the main Maven install dir, I
tried putting it in the project dir (which makes no
sense to me).  Finally I removed the links to FindBugs
and put clover everywhere.  It seemed to compile fine,
but then I got a huge stacktrace for a plugin that I
don't think I touched:

BUILD FAILED
com.werken.werkz.NoSuchGoalException: No goal
[maven-xhtml-plugin:register]
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:190)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)


BOTTOM-LINE:
  Maven sucks.  Please consider a simple ant file or
even a shell script!



----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-02 23:05

Message:
Logged In: YES 
user_id=798060

if you are used to ant maven probably requires some time at
the begininning, bu it's a lot more than a simple build tool...

I now checked the dependencies and update them to only use
versions available on maven central repository (or in other
repositories added to project.properties), to simplify the
project setup.
It should work fine, just download and unzip maven 1.0 (no
need to install anything) and run it with a working internet
connection. All the dependencies should be resolved, please
report here any addictional problem.

I will also add back to the source distribution a plain
build.xml (maven generated) for ant users.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1021354 ] DOM Elements are always generic

[SourceForge.net <no...@so...>]

Bugs item #1021354, was opened at 2004-09-02 18:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1021354&group_id=13153

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: Nobody/Anonymous (nobody)
Summary: DOM Elements are always generic

Initial Comment:
  DOM elements are never HTMLLinkElement's, or
HTMLImageElement (is this from a different DOM spec?).
 They are always the generic DOMElementImpl.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1021354&group_id=13153

[Jtidy-devel] [ jtidy-Feature Requests-1021346 ] Maven not working

[SourceForge.net <no...@so...>]

Feature Requests item #1021346, was opened at 2004-09-02 17:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Maven not working

Initial Comment:
  Plese consider rolling back to whatever previous
build process you had.  Maven might work for you in
your local environment, but it's quite pesky to setup
anywhere else.  I had to download & install (instead of
just unzipping).  Then I got all sorts of broken link
problems with many dependencies, like the FindBugs
plugin, clover, etc.  I tried downloading the
dependencies, it doesn't seem to find them anywhere, I
tried the lib dir in the main Maven install dir, I
tried putting it in the project dir (which makes no
sense to me).  Finally I removed the links to FindBugs
and put clover everywhere.  It seemed to compile fine,
but then I got a huge stacktrace for a plugin that I
don't think I touched:

BUILD FAILED
com.werken.werkz.NoSuchGoalException: No goal
[maven-xhtml-plugin:register]
        at
com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:190)
        at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:127)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
        at
org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
        at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
        at
org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
        at
org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)


BOTTOM-LINE:
  Maven sucks.  Please consider a simple ant file or
even a shell script!



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=363153&aid=1021346&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1020806 ] NPE when PPPrint'ing changed DOM tree

[SourceForge.net <no...@so...>]

Bugs item #1020806, was opened at 2004-09-01 23:07
Message generated for change (Comment added) made by hexsel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: Nobody/Anonymous (nobody)
Summary: NPE when PPPrint'ing changed DOM tree

Initial Comment:
I get a NPE when printing a DOM tree I changed.  I
traced it down to the 'lexer' variable being null at
PPrint.class, method pprintTree (sorry, lost the stack
trace).  Can't seem to 

ByteArrayOutputStream modifiedContent = new
ByteArrayOutputStream(clipping.getContent().length());
Tidy parser = new Tidy();
Document node = parser.parseDOM(new
ByteArrayInputStream(content.getBytes()), null);
processNode(contentURI, node);
parser.pprint(node, modifiedContent);



----------------------------------------------------------------------

>Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 15:50

Message:
Logged In: YES 
user_id=269024

There we go, more info:
this is the piece of code that throws the exception:

// #603128 tidy adds newslines after </html> tag
// Fix by Fabrizio Giustina 12-02-2004
// fix is different from the one in original tidy
if (!lexer.seenEndHtml)
{
	flushLine(fout, indent);
}

It throws a NPE because Tidy.pprint invokes the method with
an explicit null as the argument for the lexer, as seen
below (its reformatted to use less space here):

/**
 * Pretty-prints a tidy Node.
 * @param node org.w3c.tidy.Node
 * @param out output stream
 */
private void pprint(Node node, OutputStream out) {
	Out o = new OutImpl(this.configuration);
	PPrint pprint;
	o.setState(StreamIn.FSM_ASCII);
	o.setEncoding(configuration.outCharEncoding);
	if (out != null) {
		pprint = new PPrint(configuration);
		o.setOut(out);
		if (configuration.xmlTags) {
			pprint.printXMLTree(o, (short) 0, 0, null, node);
		} else {
			pprint.printTree(o, (short) 0, 0, null, node);
		}
		pprint.flushLine(o, 0);
	}
}

For now I'm going to change the lines locally on the PPrint
class to:
if ((lexer != null) && !lexer.seenEndHtml)
{
    flushLine(fout, indent);
}

That should solve the NPE, but I don't know about the bug
#603128 annotated before that code.


----------------------------------------------------------------------

Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 15:37

Message:
Logged In: YES 
user_id=269024

Here is the stack trace.  The version is the 30/Aug/03
snapshot. 


java.lang.NullPointerException
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2257)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2021)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1669)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1626)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetriever.retrieve(DefaultRetriever.java:100)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetrieverTest.testCompleteClipping(DefaultRetrieverTest.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1020806 ] NPE when PPPrint'ing changed DOM tree

[SourceForge.net <no...@so...>]

Bugs item #1020806, was opened at 2004-09-01 23:07
Message generated for change (Comment added) made by hexsel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: Nobody/Anonymous (nobody)
Summary: NPE when PPPrint'ing changed DOM tree

Initial Comment:
I get a NPE when printing a DOM tree I changed.  I
traced it down to the 'lexer' variable being null at
PPrint.class, method pprintTree (sorry, lost the stack
trace).  Can't seem to 

ByteArrayOutputStream modifiedContent = new
ByteArrayOutputStream(clipping.getContent().length());
Tidy parser = new Tidy();
Document node = parser.parseDOM(new
ByteArrayInputStream(content.getBytes()), null);
processNode(contentURI, node);
parser.pprint(node, modifiedContent);



----------------------------------------------------------------------

>Comment By: Gustavo Hexsel (hexsel)
Date: 2004-09-02 15:37

Message:
Logged In: YES 
user_id=269024

Here is the stack trace.  The version is the 30/Aug/03
snapshot. 


java.lang.NullPointerException
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2257)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2231)
	at org.w3c.tidy.PPrint.printTree(PPrint.java:2021)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1669)
	at org.w3c.tidy.Tidy.pprint(Tidy.java:1626)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetriever.retrieve(DefaultRetriever.java:100)
	at
com.sagebrushcorp.oberon.clipping.server.dependency.DefaultRetrieverTest.testCompleteClipping(DefaultRetrieverTest.java:169)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:31)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at
com.intellij.rt.execution.application.AppMain.main(AppMain.java:78)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1020806 ] NPE when PPPrint'ing changed DOM tree

[SourceForge.net <no...@so...>]

Bugs item #1020806, was opened at 2004-09-01 23:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Hexsel (hexsel)
Assigned to: Nobody/Anonymous (nobody)
Summary: NPE when PPPrint'ing changed DOM tree

Initial Comment:
I get a NPE when printing a DOM tree I changed.  I
traced it down to the 'lexer' variable being null at
PPrint.class, method pprintTree (sorry, lost the stack
trace).  Can't seem to 

ByteArrayOutputStream modifiedContent = new
ByteArrayOutputStream(clipping.getContent().length());
Tidy parser = new Tidy();
Document node = parser.parseDOM(new
ByteArrayInputStream(content.getBytes()), null);
processNode(contentURI, node);
parser.pprint(node, modifiedContent);



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020806&group_id=13153

[Jtidy-devel] [ jtidy-Bugs-1020691 ] Problem with AttrCheckImpl$CheckColor.check

[SourceForge.net <no...@so...>]

Bugs item #1020691, was opened at 2004-09-01 22:02
Message generated for change (Comment added) made by fgiust
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020691&group_id=13153

Category: Tidy functionality
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Terence Jacyno (tjacyno)
>Assigned to: fabrizio giustina (fgiust)
Summary: Problem with AttrCheckImpl$CheckColor.check

Initial Comment:
Applies to: jtidy2 - org.w3c.tidy.AttrCheckImpl,
revision 1.31

Parsing certain HTML pages gives the following error:

java.lang.StringIndexOutOfBoundsException: String index
out of range: 0 at java.lang.String.charAt(String.java:444)
at
org.w3c.tidy.AttrCheckImpl$CheckColor.check(AttrCheckImpl.java:905)
at org.w3c.tidy.AttVal.checkAttribute(AttVal.java:226)
...

Replacing line 905 by

if ((given.length() > 0) && (given.charAt(0) == '#'))

and line 923 by

else if ((given.length() > 0) &&
Lexer.isLetter(given.charAt(0)))

solves the problem.

Thanks.

----------------------------------------------------------------------

>Comment By: fabrizio giustina (fgiust)
Date: 2004-09-01 22:26

Message:
Logged In: YES 
user_id=798060

fixed in cvs (a 0 length string is considered a missing value).

thanks

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113153&aid=1020691&group_id=13153