Created attachment 100593 [details]
stacktrace

On today's build if I try to create new Maven Enterprise Application the project instantiation fails with attached exception. I could not workaround it and looking into the code did not help either. Looks like DocumentModelAccessProvider impl is not in model source lookup and therefore default readonly version of model is used?

Created attachment 100640 [details]
stacktrace

Add JSF framework to the Maven Web App

Could this be caused by the fix for bug 180614?

FWIW I am unable to reproduce in a dev build (also on Linux).

This bug already has 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=171168

Created attachment 100709 [details]
stacktrace

happens always

This happens to me always. Tried it again on yesterday's fresh dev build with new userdir - all I did in IDE is created new Maven Enterprise Application project with all default values and it fail wit the same exception during instantiation. If you point me to a place in code where non-readonly model should be created I'm happy to debug it and look why it fails.

After reading Bug 184306 I think this is related and so passing to Nikita to have a look. There is also bug 188443 which I'm going to assign to Nikita as well - most likely the same problem although exception is different

QA should double check whether this works on 691.

Denis, you are quite experience with xam etc. Any opinion what might be wrong off hand?

I think I found the problem. Jesse, in http://hg.netbeans.org/web-main/rev/b3c6794116db you removed dependency on org.netbeans.modules.xml.xdm from several modules. If I add the dep back to web.jsf then both this and bug 188443 go away.

*** Bug 188443 has been marked as a duplicate of this bug. ***

Well it's harmless enough to readd the dependency on xml.xdm but the question is why is it there to begin with? web.jsf does not compile against xdm, so having a <build-prerequisite/> <compile-dependency/> is certainly wrong. Having just a <run-dependency/> is possible but odd for an autoload library. Perhaps the global services registered by XDM have to be present, and there are no other modules depending on it? If so, xml.xam could recommend a token which XDM provides, though again this is odd for something that looks like a "pure" library.

Again, I cannot reproduce so as to add better advice; creating an EAR project set works fine for me in dev builds. Is this perhaps only reproducible with ergonomics enabled? Can't the exception in this issue and bug #188443 say something more meaningful?

Hotfix in core-main #1242c0a83d2e (parented to original for ease of pulling into other repos); now need to determine why this dependency was expressed in a nonstandard way and why error messages were so unhelpful.

It seems that without the dep, the xdm module is not enabled at all; then in XAM, AbstractModelFactory.getAccessProvider() returns null (and probably same for AbstractDocumentModel.getAccessProvider()). Rather than failing promptly with a helpful error, some limited-functionality variant is used instead.

If, appears likely, the public Java API of XDM is not being used at all, yet published parts of XAM require that XDM to be enabled in order to function as documented, then that dependency should be made explicit. If all clients of XAM need XDM, then XAM should OpenIDE-Module-Needs it. If only certain ones do (which?), then XAM should document a module token which they should OpenIDE-Module-Requires, and should throw meaningful errors when not present but needed.

BTW when no DocumentModelAccessProvider is present:

java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1206)
        at org.netbeans.modules.xml.xam.dom.AbstractDocumentModel.getAccessProvider(AbstractDocumentModel.java:591)
        at org.netbeans.modules.xml.xam.dom.AbstractDocumentModel.getEffectiveAccessProvider(AbstractDocumentModel.java:584)
        at org.netbeans.modules.xml.xam.dom.AbstractDocumentModel.getAccess(AbstractDocumentModel.java:572)
        at org.netbeans.modules.xml.xam.dom.AbstractDocumentModel.syncStarted(AbstractDocumentModel.java:136)
        at org.netbeans.modules.xml.xam.AbstractModel.sync(AbstractModel.java:279)
        at org.netbeans.modules.xml.xam.AbstractModelFactory.getModel(AbstractModelFactory.java:140)
        at org.netbeans.modules.maven.model.pom.POMModelFactory.getModel(POMModelFactory.java:78)
        at org.netbeans.modules.maven.model.Utilities.performPOMModelOperations(Utilities.java:326)
        at org.netbeans.modules.maven.newproject.ArchetypeWizardUtils.addEARDeps(ArchetypeWizardUtils.java:570)
        at org.netbeans.modules.maven.newproject.ArchetypeWizardUtils.instantiate(ArchetypeWizardUtils.java:360)
        at org.netbeans.modules.maven.newproject.EAWizardIterator.instantiate(EAWizardIterator.java:105)

Created attachment 100718 [details]
stacktrace

Canceling properties dialog of a Maven web project.

Nikita writes:
> The XAM and XDM modules are very connected.
> The XAM is more like interface, but XDM is more implementation.
> I think there isn't another implementation rather then XDM now.
> So it definitely worth to import them both.

In this case the -Needs/-Provides pairing would make the most sense.

Created attachment 100729 [details]
Suggested patch (untested)

Integrated into 'main-golden', will be available in build *201007130001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/1242c0a83d2e
User: Jesse Glick <jglick@netbeans.org>
Log: Hotfix of #188363: add runtime-only dep web.jsf -> xml.xdm.

*** Bug 188437 has been marked as a duplicate of this bug. ***

Urgent (applies also to Java IDE builds), was not being addressed, so: core-main #7415d2e33594

Integrated into 'main-golden', will be available in build *201007140001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7415d2e33594
User: Jesse Glick <jglick@netbeans.org>
Log: #188363: make XAM require the presence of XDM.

*** Bug 188413 has been marked as a duplicate of this bug. ***

*** Bug 190428 has been marked as a duplicate of this bug. ***