New compilation unit should be created probably from template.

Hanzi, ask Honza for Help. Thanks.

reproducible with 6.7m3

Integrated into 'main-golden', will be available in build *201012180001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7ceac2093024
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #119887: newly created compilation units should be based on corresponding templates

Verified with Options Panel wizard (Primary Panel, Allow Secondary Panels) on both a new standalone module (default header text) and a nb.org module (Oracle CDDL/etc. license).

Never mind, apisupport.project was in fact using DataObject.createFromTemplate to avoid this bug.

I am unclear on how to take advantage of this fix; make.CompilationUnit ought to work from what I understand, but how do I get the JavaSource without a source file to call JavaSource.forFileObject on? Do I need to construct it manually with the right source/classpath?

Originally, runModificationTask required a FileObject to run on (i.e. it was only able to run on JavaSources created for one or more files), but that limitation has been relieved by:
http://hg.netbeans.org/main-silver?cmd=changeset;node=f0c413954535
Spec. version updated by:
http://hg.netbeans.org/jet-main/rev/55665b266264

JavaSource.create(ClasspathInfo).runModificationTask can be used now.

(In reply to comment #7)
> http://hg.netbeans.org/main-silver?cmd=changeset;node=f0c413954535
> Spec. version updated by:
> http://hg.netbeans.org/jet-main/rev/55665b266264
> 
> JavaSource.create(ClasspathInfo).runModificationTask can be used now.

Shouldn't java.source/apichanges.xml mention this?

(In reply to comment #7)
> JavaSource.create(ClasspathInfo).runModificationTask can be used now.

I can't seem to get it to work.

1. When I try to create the package-info.java on a module in which I have just before added the API deps, I get

java.io.IOException: No annotation org.netbeans.spi.options.OptionsPanelController.ContainerRegistration in ClasspathInfo .... compile: .../nbbuild/netbeans/platform/modules/org-netbeans-modules-options-api.jar:...
	at org.netbeans.modules.apisupport.project.CreatedModifiedFiles$PackageInfo$1$1.run(CreatedModifiedFiles.java:1179)

which is of course incorrect.

2. If I call wc.toPhase(JavaSource.Phase.RESOLVED) as the first thing the Task does, I get

java.lang.IllegalStateException
	at org.netbeans.modules.java.source.parsing.CompilationInfoImpl.getCompilationUnit(CompilationInfoImpl.java:192)
	at org.netbeans.api.java.source.CompilationInfo.getCompilationUnit(CompilationInfo.java:182)
	at org.netbeans.api.java.source.TranslateIdentifier.<init>(TranslateIdentifier.java:86)
	at org.netbeans.api.java.source.GeneratorUtilities.importFQNs(GeneratorUtilities.java:527)
	at org.netbeans.modules.apisupport.project.CreatedModifiedFiles$PackageInfo$1$1.run(CreatedModifiedFiles.java:1197)

3. If I don't call toPhase, I get

java.lang.IllegalStateException: Cannot call getTreeMaker before toPhase.
	at org.netbeans.api.java.source.WorkingCopy.getTreeMaker(WorkingCopy.java:188)
	at org.netbeans.modules.apisupport.project.CreatedModifiedFiles$PackageInfo$1$1.run(CreatedModifiedFiles.java:1173)

Note that problems #2 and #3 assume the wizard is being rerun on the project so the API dependencies are already there when it starts. #1 might not be a regression due to this patch; I seem to recall something similar happening rarely and randomly before.

Created attachment 105209 [details]
Current attempted patch

(By the way, reading java.source sources, EMPTY_PATH seems to duplicate ClassPath.EMPTY.)

Thanks for testing - I did not realize that importFQNs would ask for CompilationUnitTree (it is not needed to resolve the FQNs, AFAIK), I will fix that.

(In reply to comment #10)
> #1 might not be a
> regression due to this patch; I seem to recall something similar happening
> rarely and randomly before.

See bug #194569.

(In reply to comment #13)
> Thanks for testing

Sure. You may want to try to get the patch to work yourself, since it is a good end-to-end test. Straightforward to trigger it: create a new (standalone) module project; run Options Panel wizard; check Create Primary Panel and Allow Secondary Panels; fill in some arbitrary labels and pick some arbitrary icon. Expected behavior is a new package-info.java with appropriate header comment ("Tools > Template..." for a fresh module, or Oracle CDDL/GPL in case of nb.org module), and an annotation with no error badges.

Yes, I tested that. Did several changes, the last one is:
http://hg.netbeans.org/jet-main/rev/676d12689fdb

Two changes are needed in the apisupport patch: to create a new file, the WorkingCopy.rewrite's first param needs to be null. Also, srcFile is null in this case, and so the DataObject lookup below commit fails.

(In reply to comment #16)
> to create a new file, the WorkingCopy.rewrite's first param needs to be null.

This doesn't seem to be documented. http://bits.netbeans.org/dev/javadoc/org-netbeans-modules-java-source/org/netbeans/api/java/source/WorkingCopy.html#rewrite%28com.sun.source.tree.Tree,%20com.sun.source.tree.Tree%29 claims @NullAllowed for oldTree but description says "null values are not allowed" and "throws IllegalArgumentException when null was passed to the method". The oldTree param description does not mention when a null param should be used.

(In reply to comment #16)
> Two changes are needed in the apisupport patch

Thanks, those seem to work: core-main #edef89c78745


BTW once when I tried it the result looked as expected:


/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
@ContainerRegistration(...)
package ...;

import org.netbeans.spi.options.OptionsPanelController.ContainerRegistration;


When I tried it again, the comment was in the wrong place:


@ContainerRegistration(...)
package ...;

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
import org.netbeans.spi.options.OptionsPanelController.ContainerRegistration;


It seems that if the selected package already exists, the comment is in the right place at the top of the file; but if a new package is created, the comment is inserted between the package statement and the imports. Maybe a bug to be fixed in java.source?

Integrated into 'main-golden', will be available in build *201101220001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/f0c413954535
User: Jan Lahoda <jlahoda@netbeans.org>
Log: Allow to run runModificationTask on JavaSource with zero files - useful when creating new source files (e.g. create from template). See #119887.

Integrated into 'main-golden', will be available in build *201101230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/edef89c78745
User: Jesse Glick <jglick@netbeans.org>
Log: Take advantage of TreeMaker.CompilationUnit to generate package-info.java with license header. Cf. #119887.