Bug 31637

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