First question is is this supposed to work. In other words is the VW framework capable of handling NetBeans non-Web
projects? Po-ting can answer that question. Assigning this to Po-ting.

Secondly is this a defect or a feature?

Quy can you look at the respective exception in:

org.netbeans.modules.visualweb.project.jsf.api.JsfDataObjectException: Can't find corresponding java folder for

Winston, we fixed the Theme exceptions correct?

The jsfloaders directly use the JSF project apis to determine the relative locations of jsp/java files.  This is a
hardcoded location, I believe, so the loaders expect the files to conform to the following directory structure:

$somepath/web/.../*.jsp
$somepath/src/java/.../*.java

That said, it looks like the jsfloaders were able to work correctly in this case, since the DataObject was instantiated
correctly and the designer opened.

> org.netbeans.modules.visualweb.project.jsf.api.JsfDataObjectException: Can't find corresponding java folder for

I think there is no issue for finding the corresponding java folder. We have already resolved that long before.

Sandip, this bug is created especially for insync and/or Theme.

Maven/VisualWeb projects already have bugs filed for this maven+visualweb support. Yes, we need to support this feature
for getting more developers from non-NetBeans environment and Milos has already reached the final stage. Please see
issue#106955 and issue#113284. He just needs some minor support from us here to resolve classloader issue that may be
coming from insync.

I rechecked the project and found that we have some kind of regression in jsfloader, the page is not recognized.

The jsfloader calls JsfProjectUtils.isJsfProjectFile(JSP FILE) to see whether it's a Visual Web project or not and the
result is NO! The problem is, isJsfProjectFile is searching "nbproject/project.xml" to find
"http://www.sun.com/creator/ns" and failed.

I need to extend the API to also search "$root/nb-configuration.xml".

My question is, how do I locate the file "nb-configuration.xml"? Is it always on the project root directory?

I have fixed the jsfloader issue. Now this Maven Visual Web JSF page is recognized.
    changeset 7988fe879235 in main
    details: http://hg.netbeans.org/main?cmd=changeset;node=7988fe879235

Now opening the sampleproject looks much better; you will see the multi-tab editor. No any error inside the Java editor.
But switch to the designer, you will get error from insync:
    Caused: java.lang.IllegalStateException: FacesModel was not loaded for DataObject,
dataObject=org.netbeans.modules.visualweb.project.jsfloader.JsfJspDataObject@1f97f92[D:\Projects\mavenproject64\src\main\webapp\Page1.jsp]

Passing to insync for further fix.

Created attachment 58008 [details]
Exception when opening the designer (after the jsfloader is fixed)

how do you access the http://www.sun.com/creator/ns you are looking for in nbproject/project.xml file? 
The fact if it's in the nbproject/project/xml file should not matter. The correct way of accessing your configuration is
through the AuxiliaryConfiguration class. That one should correctly delegate to nbproject/project.xml for ant projects
and to nb-configuration.xml file for maven projects..

Yes, it's a known limitation due to performance improvement! Originally in NB 5.5.*, Visual Web jsfloader did use
AuxiliaryConfiguration API to check whether the JSP object is under Visual Web or not. But since every check by using
this AuxiliaryConfiguration API will involve parsing an XML file which is pretty expensive. The jsfloader then
introduced a serious P1 performance issue when integrating into NB 6 (actually already in 5.5.*). We decided just simply
opening the XML file and scanning the keywork "http://www.sun.com/creator/ns".

Created attachment 58263 [details]
.java file errors

When I open Page1 I see errors in .java file. See the attached screenshot.

Did you also install the Visual Web Backward Compatible Kit as well? It's a JSF 1.1 project. Actually I got the warning
if I didn't.

JsfProjectUtils.hasLibraryReference(project, library, ClassPath.COMPILE) is failing for every library when the ModelSet
is using it in the getProjectClassLoader() method.

It seems to be because the maven projects classpath contains all .jar files from some 

user.home/.m2 folder

but the jars in the libraries refer to some path im modules/ext.

Milos, looks like the problem is caused by Maven project does not have matched pathname between the Library URL and the
ClassPath FileObject. Please see the following code that is not working for the Maven project:

    public static boolean hasLibraryReference(Project project, Library library, String type) {
        List lst = library.getContent("classpath");
        if (lst.isEmpty()) {
            return false;
        }

        URL url = (URL) lst.get(0);
        FileObject obj = URLMapper.findFileObject(url);
        if (obj == null) {
            return false;
        }

        // XXX NetBeans API not finished yet
        type = ClassPath.COMPILE;
        ClassPath cp = ClassPath.getClassPath(getSourceRoot(project), type);
        if (cp == null) {
            return false;
        }

        return cp.contains(obj);
    }

yes, it never actually will. the .m2/repository path jars are the ones from local repository. That's the only path the
maven project get. ever. that's how maven works. I can't possibly reference the jars from the IDE (BTW I assume the
library you pass in is coming from shared location in case of shared ant projects.. otherwise it can break as well).


The way similar check is done in spring integration for example is to check for a particular class from the library on
the classpath and not for the specific jar url itself. That might work for you as well, but I don't know the context of
your hasLibraryReference method so it's hard to judge.

FYI: Another thing Insync relies upon is the content of volumes ("classpath" and "designtim" volume etc) inside
libraries used by the project to determine which jars should be added to the designtime Classloader.

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

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

> The way similar check is done in spring integration for example is to check for a particular class from the library on
the classpath and not for the specific jar url itself.

Please provide more details, where the Spring's codes are, for me to look into. Thanks!

> The way similar check is done in spring integration for example is to check for a particular class from the library on
the classpath and not for the specific jar url itself.

Do you mean Spring uses ClassPath.findResource to check the existence of a particular class? If so, then this scheme may
not work for visualweb insync!

Insync grabs all IDE libraries and tests each to see whether the individual library is used in the project, then put it
under its own classloader for the design-time visual editor.

BTW, checking the resource name is not robust because the libraries got may have wrong version. E.g., class name for JSF
1.1 has the same resource name in JSF 1.2, and then grab a wrong library! (JSF 1.1 & 1.2 libraries can be coexisted in
the IDE) I was thinking of comparing the base jar name which is not robust either, but has similar issue as comparing
resource name.

org.netbeans.modules.spring.api.SpringUtilities

A rather quick check (maybe wrong) of jsf-api.jar for 1.1 and 1.2 reveals that both versions have
javax.faces.FacesException.class  but only the 1.2 version has javax.faces.TypedCollections.class. That way you can
distinguish if you dealing with jsf 1.1 or 1.2..

> Insync grabs all IDE libraries and tests each to see whether the individual library is used in the project, then put it
> under its own classloader for the design-time visual editor.

Please check your code, this might not work in 6.1 anymore with shared libraries implemented.

BTW: Why check libraries at all, why not put the complete runtime/compilation classpath of the project under the design
time classloader?

.