まず下記にて古いxalanと書いてしまいましたが，xalan2.7.0は現行のバージョンですね．
Apache側の記事を見るとバグの報告からQuickHackが今年の3月に提供されていますが，修正方法に異議が出ています．
たぶんまだ修正されていないでしょう．
Netbeansのソースを追っかけてみました．
該当のメッセージは，
ant/project/src/org/netbeans/modules/project/ant/Bundle.properties
にありました．
このメッセージのキーはLBL_Incompatible_Xalanになります．
これを使用しているソースがチェックも行っていました．
ant/project/src/org/netbeans/modules/project/ant/AntProjectModule.java
です．
チェックのアルゴリズムは以下の通りになります．
org.apache.xalan.Versionはバージョン番号を提供するクラスです．（例：2.6.0）
しかし，このバージョン番号は利用していません．
SunのJDK5.0は先日書いたようにxalanをcom.sun.org.apacheに置いています．先日の説明は悪かったのですが，どうやら別にapacheを入れた場合にJAXPの挙動が変わらないように考慮しているようです．
com.sun.org.apahce.xalanにはVersionがないのですが，変わりにcom.sun.org.apache.xalan.internal.Versionがあります．これは2.6.0を返します．
なぜにSunのJDK5.0はバグがないのかはよくわかりません．
さて，IBMのJDK5.0は現在，org.apache.xalanにxalanがあります．
org.apache.xalan.Versionが存在し，バージョンは2.7.3です．*1
上のチェックで引っかかるということはバグが存在するようです．
このような複雑な状況のため，現在，netbeansはIBMの虎さん上では動きません．
これを修正するには次の方法が考えられます．
- IBM製JDK5.0のxml.jarからxalanを消す
- Sun製JDK5.0のrt.jarからxalanを取り出す
- IBM製JDK5.0のjaxp.propertiesを編集し，JAXPの実装をSun製に変更する
以上．*2
別解としてApacheがxalanを修正したら，xalanをクラスパスの先頭に入れてIBMの虎さんの中の人よりも優先的にしてしまえば問題は解決されると思います．
ということで，Apacheの修正待ちですね．
Apacheの中の人に期待しましょう．
しかし，IBMのxalanの扱いは議論が必要かもしれませんね．
Sunの目的は理解できるのでIBMもcom.ibm.org.apacheにでも入れてしまったほうが良いかもしれません．
いっそのこと，XMLはJavaの標準から外してしまったほうが良いのかもしれません．
先日のCPANが必要かもというのはそういう意味で書きました．
ライブラリのバージョン管理，依存性管理をどこかでやる必要がJavaでも出てきているのかもしれません．
