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.
Summary: | Broken Visual XML editor dependencies, CNFE | ||
---|---|---|---|
Product: | xml | Reporter: | _ pkuzel <pkuzel> |
Component: | Code | Assignee: | issues@xml <issues> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | jglick, lkishalmi, richunger, tkellerer |
Priority: | P2 | ||
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Linux | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | 31818 | ||
Bug Blocks: | |||
Attachments: |
The CNFE
Cummulated patch for release35 branch XML subset in trunk |
Description
_ pkuzel
2003-03-04 08:21:15 UTC
I cannot reproduce. The debugging flag does not report anything. Rich you have to hack both implementaion numbers and specification numbers. Jesse do you have a clue why the CNFE occure? Is it possible that the module system enables module with inproper implementation dependency then failing on lack of classloader resources? I cannot reproduce on my environment. "Is it possible that the module system enables module with inproper implementation dependency then failing on lack of classloader resources?" - should not be possible. Read http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/doc-files/classpath.html if you have not already, and specifically look at Tools -> Options -> Modules -> <<your module>> -> Expert -> Effective Classpath. I see there a reflection on stack trace. Does the effective class path survive Instrospector? Sorry for missing info, attaching... Created attachment 9262 [details]
The CNFE
I tried: nbbuild$ ant real-clean nbbuild$ ant -Dbuild.compiler.debug=true -Dmoduleconfig=xml -Dbuildnumber=030304 merge and I end up with: Warning - could not install some modules: XML Core - The module XML Tools API would also need to be installed. XML Core - No module providing the capability org.openide.windows.IOProvider could be found. XML Text Editor - The module XML Tools API would also need to be installed. XML Text Editor - The module XML Core would also need to be installed. XML Text Editor - The module Editor would also need to be installed. Debugger API - No module providing the capability org.openide.compiler.CompilationEngine could be found. XML Tools API - The module Full JAXP API would also need to be installed. Full JAXP API - No module providing the capability javax.xml.transform.TransformerFactory could be found. TAX Library - The module XML Tools API would also need to be installed. TAX Library - The module XML Core would also need to be installed. Editor - The module Debugger API would also need to be installed. CSS Support - The module XML Tools API would also need to be installed. CSS Support - No module providing the capability org.openide.windows.IOProvider could be found. CSS Support - The module Editor would also need to be installed. XML Schema Support - The module XML Tools API would also need to be installed. XML Schema Support - The module XML Core would also need to be installed. XML Productivity Tools - The module Full JAXP API would also need to be installed. XML Productivity Tools - The module XML Tools API would also need to be installed. XML Productivity Tools - The module TAX Library would also need to be installed. XML Productivity Tools - The module XML Core would also need to be installed. XSL Support - The module Full JAXP API would also need to be installed. XSL Support - The module XML Tools API would also need to be installed. XSL Support - No module providing the capability org.openide.util.HttpServer$Impl could be found. XSL Support - The module XML Core would also need to be installed. XSL Support - The module named org.netbeans.libs.xalan/1 was needed and not found. XML Entity Catalog - The module XML Tools API would also need to be installed. XML Entity Catalog - The module XML Core would also need to be installed. XML Tree Editor - The module XML Tools API would also need to be installed. XML Tree Editor - The module TAX Library would also need to be installed. XML Tree Editor - The module XML Core would also need to be installed. *********** Exception occurred ************ at Tue Mar 04 10:52:07 PST 2003 java.lang.IllegalStateException: No Menu/ at org.openide.awt.MenuBar.<init>(MenuBar.java:79) at org.netbeans.core.windows.MainWindow.initialize(MainWindow.java:94) at org.netbeans.core.Main.initializeMainWindow(Main.java:249) at org.netbeans.core.NonGui.run(NonGui.java:533) at org.netbeans.core.Main.run(Main.java:233) at org.netbeans.core.NbTopManager.getNbTopManager(NbTopManager.java:236) at org.netbeans.core.NbTopManager.get(NbTopManager.java:195) at org.netbeans.core.Main.start(Main.java:407) [catch] at org.netbeans.core.TopThreadGroup.run(TopThreadGroup.java:79) at java.lang.Thread.run(Thread.java:536) Rich, the clean have cleaned everything. I think I got it. All older XML modules (these at stable AU) use specification dependencies. These still match but since new 3.5 modules utilize new Public-Packages feature to hide non-API classes it effectively breaks old specification version based dependants. I need to turn on an auto-dependecy upgrade feature for all XML modules that started to use the Public-Package feature. Jesse where could I find the feature doc please? My dependency upgrade means to virtually erase the Public-Package contraint if seen by the dependent module declaring specification dependency less than something. I think it must be resolved for 3.5. I cannot find it in apichanges. But with some fuzziness I think that Jesse used something like it for the debugger API. Oops, the auto dependency update would cause further problems because several public classes have moved around modules. Now I am considering to increase major specification number and change module names to org.netbeans.modules.xml.XXX/2. If accepted it requires dependent module owners to update their
manifest dependencies by adding "/2" suffix after any xml module
dependency. It's all once they have code compileable against release35
branch.
E.g. diff:
OpenIDE-Module-Module-Dependencies:
< org.netbeans.modules.xml.core/1 = YYMMDD
> org.netbeans.modules.xml.core/2 = YYMMDD
where YYMMDD is actual xml/core build number.
Issue #31818 should be solved in batch. It simplifies manifests of dependent modules. I'm not really following this in detail, so if you have some specific question for me, pls. first read http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/modules/doc-files/api.html#refactoring and if that does not help then let me know exactly what you need... Never mind, it's "Public-Packages: -" related. Clean incompatible change. Created attachment 9341 [details]
Cummulated patch for release35 branch
Integrated in release35 branch. I'll need to do the same for trunk and prj40_prototype branches. Postponing until there will be clean decision what is new main development branch. Created attachment 9358 [details]
XML subset in trunk
Generic version propagated into trunk. I updated all dependent modules in NetBeans CVS too. Staring from now release34, release35 and trunk build should coexist at AU properly. Looks fine in release35 but I am still not happy with the "solution" in the trunk. Consider e.g. the ant/grammar module. It is now useless for dev builds. I cannot use it in test mode. I cannot publish an NBM which will work with more than one dev build, so the daily alpha NBM server is going to be close to useless, even though it is unlikely that the API in xml/core is changing *that* quickly. Can't you use the same XMLr35 impl version in the trunk until something is actually changed (and then switch it to e.g. XML-dev-2003-03-25, according to the date of the change)? It's changing quickly - there are another public classes in xml/core. This solution guarantees that all modules from particular build will cooperate without any periodic maintenance at client modules side. I doubt that all client module developers are so enthuiastic as you are. XML module build infractructure is prepared to serve enthuiastic developers. It's just now turned off to avoid complains from others. All these sort of problems become void once API (at least next part) will be promoted. VERIFIED VERIFIED |