Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 31637 - Broken Visual XML editor dependencies, CNFE
Broken Visual XML editor dependencies, CNFE
Status: VERIFIED FIXED
Product: xml
Classification: Unclassified
Component: Code
3.x
PC Linux
: P2 (vote)
: 3.x
Assigned To: issues@xml
issues@xml
PROJECTS_CANDIDATE
:
Depends on: 31818
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-04 08:21 UTC by _ pkuzel
Modified: 2003-10-10 06:28 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
The CNFE (4.04 KB, text/plain)
2003-03-04 17:56 UTC, _ pkuzel
Details
Cummulated patch for release35 branch (20.16 KB, patch)
2003-03-11 09:58 UTC, _ pkuzel
Details | Diff
XML subset in trunk (16.84 KB, patch)
2003-03-11 16:48 UTC, _ pkuzel
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2003-03-04 08:21:15 UTC
Rich Unger wrote:

> I just compiled the trunk, and then compiled the
xml subtree in order
> to get xml.tree in there.
> 
> At first, it used an implementation version of
"dev", both for itself
> and to check against the dependencies on core
and tax.
> 
> I manually hacked manifest-subst to use the
version string 0.8.
> 
> Now, I can install the module, but attempting to
bring up
> Tools..Options results in:
> 
> Annotation: Encountered while introspecting
>
org.netbeans.modules.xml.tree.settings.TreeEditSettings
> java.lang.NoClassDefFoundError:
> org/netbeans/modules/xml/core/lib/AbstractUtil
> 
> which is, of course, in xml.core.  What's going
on with these
> dependencies?


Thomas Kellerer wrote:

OK there is only one version on AU, that is 0.2.7
(200202081003).
I tried it with today's dev build as well and it
still doesn't work.

Here are the library versions:

TAX Library version (Specification) 0.8,
TAX Library Version (implementation) 200303030100

XML Core is 0.8
XML Tools API 1.1

Btw: the exception at the beginning prevents the
module from installing 
itself, because when I right click on an xml file,
the "Open" still is 
greyed out...


My theory:

"To check whether your module is correctly
declaring every dependency,
make sure your bin/ide.cfg does not contain
-J-Xverify:none (dev builds
are OK, but change this in release builds), then
start NetBeans with
the flag -J-Dnetbeans.preresolve.classes=true and
check the log
file for any problems."

http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/doc-files/upgrade.html#3.5i-indirect-dep-cp
Comment 1 _ pkuzel 2003-03-04 08:49:01 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.
Comment 2 Jesse Glick 2003-03-04 17:45:15 UTC
"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.
Comment 3 _ pkuzel 2003-03-04 17:56:05 UTC
I see there a reflection on stack trace. Does the effective class path
survive Instrospector?

Sorry for missing info, attaching...
Comment 4 _ pkuzel 2003-03-04 17:56:42 UTC
Created attachment 9262 [details]
The CNFE
Comment 5 Rich Unger 2003-03-04 18:57:39 UTC
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)
Comment 6 _ pkuzel 2003-03-05 07:48:23 UTC
Rich, the clean have cleaned everything.
Comment 7 _ pkuzel 2003-03-07 20:48:44 UTC
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.
Comment 8 _ pkuzel 2003-03-07 21:13:02 UTC
I cannot find it in apichanges. But with some fuzziness I think that
Jesse used something like it for the debugger API.
Comment 9 _ pkuzel 2003-03-07 22:20:24 UTC
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.
Comment 10 _ pkuzel 2003-03-07 23:21:52 UTC
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.
Comment 11 _ pkuzel 2003-03-10 11:12:44 UTC
Issue #31818 should be solved in batch. It simplifies manifests of
dependent modules.
Comment 12 Jesse Glick 2003-03-10 14:56:02 UTC
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...
Comment 13 _ pkuzel 2003-03-10 16:01:07 UTC
Never mind, it's "Public-Packages: -" related. Clean incompatible change.
Comment 14 _ pkuzel 2003-03-11 09:58:51 UTC
Created attachment 9341 [details]
Cummulated patch for release35 branch
Comment 15 _ pkuzel 2003-03-11 10:13:29 UTC
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.
Comment 16 _ pkuzel 2003-03-11 16:48:00 UTC
Created attachment 9358 [details]
XML subset in trunk
Comment 17 _ pkuzel 2003-03-11 17:00:25 UTC
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.
Comment 18 Jesse Glick 2003-03-11 18:46:49 UTC
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)?
Comment 19 _ pkuzel 2003-03-12 08:28:28 UTC
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.
Comment 20 Martin Schovanek 2003-03-14 13:31:04 UTC
VERIFIED
Comment 21 Martin Schovanek 2003-10-10 06:28:44 UTC
VERIFIED 


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo