Yes, I just noticed this myself [dev oct 11], it seems to have started
very recently. I think it is a core problem; agree with P1 assessment.

Most of the time Ant scripts are not being recognized for me, only as
XML. E.g. run a build with a clean userdir and just the Ant module,
and mount ..../nb_all/jarpackager/. The build.xml is not recognized.
Sometimes it still works. Some investigation showed that Lookup has
the MIMEResolver from the Ant module's XML present; but the MIME type
of the file is given as text/xml. So I assume something is wrong in
the MIME resolution system (not sure which part).

A note for Chris: while cumbersome, you are not prevented from
reloading modules because of this. If you have your test target split
into one half that builds the module, and one that depends on the
first and just runs <nbinstaller> (see apisupport or ant build scripts
for examples), then you can from the command line run the first half;
then under Tools | Options turn the module off and back on (assuming
it is already installed in test mode from that location, else Modules
| New | Module for Testing... to begin). A bit more of a pain, but
still far faster than restarting the IDE or similar things. And
testing using the JAR Packager should be unaffected.

You probably made your custom build, because it's not reproducible in
"oficial" 200110110100 build. But of course I can reproduce it in
todays build dev-200110120100. Ant module is therefore completly unusable.

this has something to do with Crimson.  If you delete crimson.jar from
lib/ext, the IDE will fall back to Xerces, then everything works fine.

Yesterday we discovered a defect in our XMLFileSystem exposed by
Crimson.  Not sure if this is a similar case or a bug in Crimson.

Going to investigate it.

I can confirm that this is an XML parser issue. If you insert the
following line into the beginning of
org.netbeans.core.filesystems.MIMEResolverImplTest.setup():

    org.netbeans.core.xml.NbSAXParserFactoryImpl.install();

then the tests fail:

testDeclarativeMIME(org.netbeans.core.filesystems.MIMEResolverImplTest)junit.framework.AssertionFailedError:
ns rule failureroot/ns.xml => null

testParseFailures(org.netbeans.core.filesystems.MIMEResolverImplTest)junit.framework.AssertionFailedError:
build1.xml recognized as Ant script expected:<text/x-ant+xml> but
was:<null>

MIME resolution process use a parser instance per process. Just hope
that there can be more Crimson intances alive at same time. Problem
lies somewhere in file sniffing as templates (smells) are parsed
correctly.

So the bug is in startElement() callback handling: 

<cite from="SAX 2.0 specs">
the Namespace URI and local name are required when the namespaces
property is true (the default), and are optional when the namespaces
property is false (if one is specified, both must be);
 
the qualified name is required when the namespace-prefixes property is
true, and is optional when the namespace-prefixes property is false
(the default). 
</cite>

If parser does not support optionals it must pass "" as parameter.
Xerces passes null. The code was written against Xerces.

I have updated code so it is written right along the specs but is also
relax Xerces bug.



I have also introduced RememberingReader because otherwise I got very
often  shallowed (I expect that reason is that file starts with some
WS or so that is why leading <?xml is interpresed as illegal PI)
exception:

org.xml.sax.SAXParseException: Illegal processing instruction name, or
missing whitespace.
        at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3182)
        at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3170)
        at org.apache.crimson.parser.Parser2.maybePI(Parser2.java:987)
        at
org.apache.crimson.parser.Parser2.maybeMisc(Parser2.java:1092)
        at
org.apache.crimson.parser.Parser2.parseInternal(Parser2.java:487)
        at org.apache.crimson.parser.Parser2.parse(Parser2.java:305)
        at
org.apache.crimson.parser.XMLReaderImpl.parse(XMLReaderImpl.java:442)
        at
org.netbeans.core.filesystems.DefaultParser.parse(DefaultParser.java:108)
        at
org.netbeans.core.filesystems.XMLMIMEComponent$SniffingParser.sniff(XMLMIMEComponent.java:234)
        at
org.netbeans.core.filesystems.XMLMIMEComponent.acceptFileObject(XMLMIMEComponent.java:55)
        at
org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.resolve(MIMEResolverImpl.java:392)
        at
org.netbeans.core.filesystems.MIMEResolverImpl$FileElement.access$000(MIMEResolverImpl.java:375)
        at
org.netbeans.core.filesystems.MIMEResolverImpl$Impl.findMIMEType(MIMEResolverImpl.java:107)
        at
org.openide.filesystems.MIMESupport$CachedFileObject.resolveMIME(MIMESupport.java:138)
        at
org.openide.filesystems.MIMESupport$CachedFileObject.getMIMEType(MIMESupport.java:127)
        at
org.openide.filesystems.MIMESupport.findMIMEType(MIMESupport.java:51)       
at org.openide.filesystems.FileUtil.getMIMEType(FileUtil.java:543)
        at
org.openide.filesystems.AbstractFileObject.getMIMEType(AbstractFileObject.java:147)
        at
org.openide.filesystems.MultiFileObject.getMIMEType(MultiFileObject.java:430)
        at
org.openide.filesystems.MultiFileObject.getMIMEType(MultiFileObject.java:430)
        at
org.openide.loaders.ExtensionList.isRegistered(ExtensionList.java:130)
        at
org.openide.loaders.UniFileLoader.findPrimaryFile(UniFileLoader.java:62)
        at
org.apache.tools.ant.module.loader.AntProjectDataLoader.findPrimaryFile(AntProjectDataLoader.java:111)
        at
org.openide.loaders.MultiFileLoader.findPrimaryFileImpl(MultiFileLoader.java:232)
        at
org.openide.loaders.MultiFileLoader.handleFindDataObject(MultiFileLoader.java:65)
        at
org.openide.loaders.DataLoader.findDataObject(DataLoader.java:221)
        at
org.openide.loaders.DataLoaderPool.findDataObject(DataLoaderPool.java:362)
        at
org.openide.loaders.FolderList.createBoth(FolderList.java:569)
        at
org.openide.loaders.FolderList.getObjects(FolderList.java:390)
        at
org.openide.loaders.FolderList.access$200(FolderList.java:42)
        at
org.openide.loaders.FolderList$ListTask.run(FolderList.java:735)
        at org.openide.util.Task.run(Task.java:152)
        at
org.openide.util.RequestProcessor$ProcessorThread.run(RequestProcessor.java:611)

Not RESOLVED yet as there is a problem with above exception if not
using Remembering reader.

Created attachment 2986 [details]
Please review attached patch (we need to get rid of RememberingReader).

Please use ErrorManager thruout when you have the time...

What does the exception here really mean? Note that it is illegal for
an XML file to have the <?xml?> not at the very beginning of the file
(if there is one), so the parser *should* fail and reject the file if
this is not true.

Is there a reason to comment out the setting of the feature
external-parameter-entities=false?

Further investigation of thrown exception using modified Crimson
parser showed that input stream sometimes contains multiple copies of
original file content. It means that in the middle of file is present
XML prolog...

Anyway this particular bug is FIXED.

DefaultParser.java new revision: 1.7
XMLMIMEComponent.java new revision: 1.6

I'll provide a copy of modified Crimson to Radek so he can investigate
why the input stream returns such content.

Setting unsupported feature may break parser internal state.

In some cases I intentionaly do not use ErrorManager. I think you mean
the code under: //this should be commented out. But at this case there
should be really no error reporting because the error can be reported
for any broken (even user's) XML documents. If I use ErrorManager
there then I would get tons of bugs reports. So I rather decided to
shallow the exception. But, OK I am going to try to do not shallow the
exception using ErrorManager.INFORMATIONAL level.

"Setting unsupported feature may break parser internal state." -
really? Wouldn't that be a bug in the parser (should just throw
SAXException)? Have you reported it if so?

Re. ErrorManager--mainly I meant not to use System.err.println when
ErrorManager will do. Whether or not to use anything--I'm not sure. I
agree that it is odd to log exceptions for user problems. It could be
useful to help users figure out why their file is not recognized
correctly. On the other hand, running an XML validator is not very
difficult and ought to catch problems in normal cases (unless
someone's parser is too strict or too forgiving).

Thanks for the quick fix...

*** Issue 16565 has been marked as a duplicate of this issue. ***

verified

Resolved for 3.4.x or earlier, no new info since then -> closing.