This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
In case of visualweb while constructing designtime classloader, we look for "classpath/packaged" classpath type, if it exists we use it get the classpath entries. Otherwise, we get the "classpath/compile" classpath and remove the app server jars ourselves. See http://www.netbeans.org/issues/show_bug.cgi?id=130231 and http://www.netbeans.org/issues/show_bug.cgi?id=131785 Now when I check for "classpath/packaged" classpath type for web project, I get classpath but its entries are empty, Because of this we have a P1 bug http://www.netbeans.org/issues/show_bug.cgi?id=135929 Initially I thought it could be because of incomplete implementation of classpath/packaged classpath type by web project. However after further discussion with dkonecny, I debugged further and found that it is due to changes for #134341. When I ask for a classpath type which doesn't exist, it simply creates a new empty one, see line 104 to 114 in org\netbeans\spi\java\project\support\ClassPathProviderMerger.java
I'm sorry. When writing the merger, I forgot about the contract we setup with visual web. I'll hotfix it until David writes the packaged classpath implementation.
hotfixed by creating a special merger for web projects that will return null for classpath/packaged. I assume that once webprojects support that classpath type, the workaround can be removed..
*** Issue 135951 has been marked as a duplicate of this issue. ***
Verified with build 080530.
Milos, your impl of ClassPathProviderMerger changes semantics. I cannot say whether it is relevant change or not and whether it can have further impact (Tomas may know better). All project files (regardless of their location within project) will now have a classpath. For example (just for sake of example) asking for classpath for "nbproject/project.xml" used to return null but now it will return a classpath instance with empty roots right? Why not to change ClassPathProviderMerger.CPProvider.findClassPath() to create classpath for proxy implementation but return it only if ProxyClassPathImplementation.impls is non empty? Could that work or am I missing something?
Integrated into 'main-golden', available in NB_Trunk_Production #234 build Changeset: http://hg.netbeans.org/main/rev/078eed1a8422 User: Milos Kleint <mkleint@netbeans.org> Log: #136016 temporarily create a copy of ClassPathProviderMerger, that will not merge "classpath/packaged"
tomasi, can you comment on wheather having empty classpath creates a problem? afaik the java infrastructure will always just check source roots for sake of performance. davide, it could work the way you suggest. maybe we should check if one of the delegates returns non-null and return non-null in such a case. I have to return to the merger implementation anyway, it will currently cache the proxyimpls in a non-efficient manner.
The empty classpath may cause problems to clients which are using ClassPath.getClassPath() != null to check that the folder is a valid java source root, as far as I remember web services are doing something like this. There is probably more such a clients. Java infrastructure uses only classpaths registered in the GPR and does a check of CP validity ClassPath.getClassPath(root).getRoots().contains(root), so the Milos change doesn't affect java infrastructure.
http://hg.netbeans.org/main/rev/847ae7e9b0e8 is probably a more generic fix. if none of the delegating providers returns a value fo rthe given file, the merger returns null, but doesn't cache the null value, to allow installed modules to kick in later.. davide, you might be able to remove the hotfix workaround in web/project, however I didn't want to do myself as I'm leaving on vacation soon.
Cool. I will fix the web, no worries. Enjoy your break.
Hotfix removed: 712a9fe445df Please retest.
Integrated into 'main-golden', available in NB_Trunk_Production #237 build Changeset: http://hg.netbeans.org/main/rev/712a9fe445df User: David Konecny <dkonecny@netbeans.org> Log: #136016 - removing temporary hotfix