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.

Bug 144257

Summary:	Library wrapper module and Refactoring
Product:	apisupport	Reporter:	_ moser <moser>
Component:	Project	Assignee:	issues@java <issues>
Status:	RESOLVED DUPLICATE
Severity:	blocker	CC:	puce
Priority:	P3
Version:	6.x
Hardware:	All
OS:	All
Issue Type:	DEFECT	Exception Reporter:

Description _ moser 2008-08-18 13:15:34 UTC

In a module suite I have a library wrapper module for an existing plain Java project. I hooked them
up as described in method 1 at http://wiki.netbeans.org/DevFaqWrapperModules

So far all works fine: I have code-completion with javadoc and go-to-source when referencing my-project.

Now I want to rename a method in the plain Java project. Or I want to find its usages. Unfortunately
this does not work for references of the library in the module suite but only in dependent plain
Java projects. On the mailing list I was told that there's no way: the Library Wrapper "breaks" the chain of references.

Even the other way round would make sense. I have plain Java projects which depend on a couple of jars defined and built
by modules from a NetBeans module suite. I want refactoring to respect usages of the modules's classes in the plain Java
project.

Frank-Michael

Comment 1 Jesse Glick 2008-08-23 16:34:02 UTC

Method #2 is likely better; netbeans.org projects routinely use it. Method #1 is untested AFAIK.

*** This issue has been marked as a duplicate of 70894 ***

Comment 2 _ moser 2008-08-23 22:56:42 UTC

Do you mean that using method 2 I will get support for refactoring?

Comment 3 Jesse Glick 2008-08-25 16:41:18 UTC

You should. I haven't tried recently.

Comment 4 _ moser 2008-08-26 00:02:28 UTC

In NetBeans IDE Dev (Build 200808241401) refactoring works (see issue 70894). Even the other way round plain Java
projects which depend on a couple of jars defined and built by modules from a NetBeans module suite are taken into
account when refactoring classes in the modules if the plain java projects directly depend on jars in build/cluster/modules.