Created attachment 65315 [details]
stacktrace

Probably <public-packages> is being written too early in the document.

This needs to be fixed for 6.5.

Fixed in core-main #1c292820cd93

The patch looks wrong to me. findElement is intended to be used when exactly one (or either zero or one) elements of a
given name can be found beneath a given parent according to the schema. It should never be used for elements which can
have multiple occurrences.

It's not exactly clear from the changelog comment what the relationship of this is to the SAXParseException (whose
immediate cause is that apisupport.project code is trying to write invalid content), but I am guessing that some element
ordering logic is breaking when >1 <c-p-e> must be added. Fine, but if so, do not break findElement; use findSubElements.

In particular, I do not want findElement to have some special logic distinct from the general method which will be
introduced in issue #136595.

The patch is also missing a unit test.

Integrated into 'main-golden', will be available in build *200809300201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/1c292820cd93
User: Richard Michalsky <rmichalsky@netbeans.org>
Log: #141277: fixed SAXParseException, caused by o.n.m.a.p.Util#findElement returning null when more than node of given name found. Semantics changed to return first found node. Seems it should not break other uses of the method.

The most direct cause of failed validation is that ProjectXMLManager#insertPublicOrFriend tries to insert
<public-packages> in front of any present <c-p-e> or <e-c-u> and it uses findElement to locate them. Since there are two
wrapped libraries, it returns null and inserts <p-p> at the wrong position.

I considered using findSubElements or the like, but since findElement is not a public API I searched all occurences and
AFAIK that particular feature (returning null on more than one found element) is never explicitly used - most searched
for elements can appear only once anyway, the only exception is search for <e-c-u> also in insertPublicOrFriend, where
it exhibited the same buggy behavior as described here. So I decided to change semantics of findElement instead. Javadoc
is updated.

Regarding issue #136595, I didn't notice you're making it an API, so let me know if I should revert this change and use
different approach or keep it there and add the test instead.

Please add a test *and* restore the original findElement, perhaps adding a List<Element> findElements(...) to handle the
cases where multiple occurrences are expected.