There is a workaround. I move the class-path-extension element after the module-dependencies and public-packages elements.
This project works for 6.X, so, should work for 6.5 too.

Regards.

I've been hit the same a while back. It's caused by the fact that since 6.5 the project.xml files are validated against
xml schemas. (issue 42686)
the apisupport's schema doesn't allow to place the elements at will. The suggestion I got was to validate the xml file
upon saving :(

The "workaround" is just fixing the project file to be valid according to schema.

This has nothing to do with the Ant module.

How can you consider it as invalid since for previous versions it is a "valid" project.xml file? IMO it is a regression
about parsing project.xml, but I agree that a shema validation must be done. So, a warning about problems on xml file
must be showed to user. For example, when I open a suite module and try to open all the related projects, the incorrect
projects just are not opened without any warning. And it should be a friendly warning about this specific problem, not a
schema validation error as some days ago.

The schema has not changed; it was never valid, as A-S-F9 would have shown. 6.5 validates project.xml before allowing a
project to be opened (as well as before a modified project.xml is either loaded or saved). This solves a host of
problems in previous releases involving a project with malformed metadata being opened but then being unusable in
various ways due to code assuming that it was reading a processing project.xml. This particular validation error likely
resulted in no symptoms in previous releases, but it should be corrected nonetheless.

Problems loading component modules of a suite when you select Open Required Projects are sent to the log file only, as
this is not a critical function. The precise validation error is displayed in the Open Project dialog if you attempt to
open the module directly.

what is the purpose of validating the documents in the first place?

if it's just to figure if a certain project can be opened in a given version of the IDE, then we can just check for
presence of namespaces (as defined in document) in the catalog. Since the xml content is ten worked with using DOM, the
ordering or extra elements don't really matter.

Checking whether a given IDE supports a given namespace is one benefit of validation. More generally, it stops loading
of a project with arbitrary errors in project.xml at a predictable point. I have seen many reports of quite random
exceptions (NPEs, ...) caused ultimately by some mistaken content in project.xml that the code was not prepared to read:
missing required subelements, etc. Usually the root problem could be inferred from the stack trace. With validation, not
only will such problems be immediately apparent (error is in fact displayed in Open Project), but it is assured that IDE
code will never accidentally write a malformed project.xml due to a module bug. It also assures that published schemas
are actually accurate - previously, I found at least one schema which was not even well-formed, much less correct. Refer
to the original issue for full background.

Created attachment 66096 [details]
opening a "broken" project with default dialog size

Created attachment 66097 [details]
maximizing the dialog doesn't really help

well, going back from general designs to this particular scenario. We've traded better support for completely broken
project, for failing to load projects that were previously just fine.
Also see the attached screenshots that show what is shown to the user when the previously good project is shown.
The whole message is never shown and is amusingly cryptic.

Error parsing /home/mkleint/src/hg-working/main/maven.indexer/nbproject/project.xml: cvc-complex-type.2.4.a: Invalid
content was found starting with element 'class-path-extension'. One of
'{"http://www.netbeans.org/ns/nb-module-project/3":suite-component,
"http://www.netbeans.org/ns/nb-module-project/3":standalone,
"http://www.netbeans.org/ns/nb-module-project/3":module-dependencies}' is expected.

reopening the issue but downgrading to P2.
I would assume the fix involves a shorter and more descriptive message
and relaxing the schema to allow loading projects that were loaded in previous versions.

There is no clear set of "projects that were loaded in previous versions". Previous versions would go ahead and open
anything from perfect project.xml's, to project.xml's with minor errors, to complete trash, only throwing exceptions later.

Maximizing the dialog is unnecessary as the text field is scrollable. The exact error message is not exactly under NB's
control - it is generated by Xerces - but could be made at least shorter by mechanically trimming out some unnecessary
details and abbreviating some longer strings. This could only be handled by AntBasedProjectFactory, where the validation
of a newly opened project is done.

Producing a shorter message (core-main #89338b8b7637). Would now show

Error in project.xml: Invalid content was found starting with element 'class-path-extension'. One of
'{".../nb-module-project/3":suite-component, ".../nb-module-project/3":standalone,
".../nb-module-project/3":module-dependencies}' is expected.

Can't go much shorter without losing information. Of course you can always open project.xml using File > Open and use
Alt-Shift-F9 to see full error messages with hyperlinks.

Integrated into 'main-golden', available in build *200807310201* on http://bits.netbeans.org/dev/nightly/
Changeset: http://hg.netbeans.org/main/rev/89338b8b7637
User: Jesse Glick <jglick@netbeans.org>
Log: #142079: messages for invalid project.xml shortened considerably.

"There is no clear set of "projects that were loaded in previous versions". Previous versions would go ahead and open
anything from perfect project.xml's, to project.xml's with minor errors, to complete trash, only throwing exceptions later."

BUT this case is not about thrashed project data, it's only about ordering of elements. That's something that shall be
easily fixed (by relaxing the schema) and presents no thread to safety.

Unfortunately it is not possible to use <xsd:all> for the NBM project schema's top-level <data> element, and
<xsd:choice> would allow through documents missing mandatory sections (even just <data></data>). XML Schema can only
validate unordered collections in some very restricted circumstances. (No idea if RELAX-NG is more powerful here.)

Generally it is undesirable to offer arbitrary variations on a format; among other things, versioning is safer when
subelements occur in a predictable order. For cases where the IDE's GUI customizers historically wrote out project.xml
contents in the wrong order (due to the automatic lack of validation on write prior to 6.5 and the lack of unit tests in
some modules to check project.xml validity), there is no real choice but to loosen the schema, even at the expense of
permitting truly meaningless documents to be validated. Hand-edited files always were subject to the published schemas,
though.

I agree about validation is necessary. In my point of view, the only undesirable behaviour is when a tool change your
behaviour and don't tell to the user about it. Since now the files will be validated, user should to know about the
problems, and if possible, show most as possible information to user fix the problem. I always believe that tools should
help us instead create more problems than we already have.

Regards.

Take a look at issue #143966.