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.
I've observed occational references to org.openide.loaders. Looking closer to this I have found out that those are usually reference to TemplateWizard and its Iterator. I am convinced that there is no real reason for this other than convinience and anyway TW.Iterator does not seem to be suitable well for creation of new project, for example, and that is why I think the buildsys apis should be data systems independent. (I know that physical view is based on them, but that is not my concern, that can stay or be replaced). If I should suggest some replacement, for example for iterator to create new Project, I would create interface ProjectIterator { // with needed methods like init,deinit,install // and some communication to obtain logical // project name, physical location, etc. In the // best situation supporting extensibility. } I would suggest to continue to use TempalateWizard, just modify the way how templates are registered in the /Templates/Project directory. There are two choices: <attr name="templateWizardIterator" methodvalue="org.nb.api.project.ui.Wizard.default" /> <attr name="projectIterator" newvalue="..." /> which is simple, works immeditatelly and has just two problems: it still shows the templateWizardIterator and it uses methodvalue, which is to be deprecated in future. Thus the nicer alternative would be to define your own XML type and register projects by a descriptive file: <file name="jnlp.xml" url="jnlp.xml" > <attr name="template" boolvalue="true" /> </file> and in the jnlp.xml have: <!DOCTYPE project-template PUBLIC "..." > <project-template> <iterator classname="..." /> <!-- other stuff if needed --> </project-template> This file would be automatically processed (XMLProcessor or Environment.Provider are currnen possiblities) and convert ProjectIterator into TemplateWizard.Iterator, so the API would remain completelly clean from the loaders stuff. I like the second suggestion a bit better, but I am not going to request particular impl, this is just suggestion. The request is to get rid of loaders package in API (javadoc for sure, layers and other apis if possible).
The main reason to use TemplateWizard.Iterator was simply that so many existing wizards already implement it, and in order to get rid of use of loaders throughout the APIs we would have to replace these anyway. I.e. I was expecting a different effort to work on creating a loader-less template API, and not for promo-D. To remove the org.openide.loaders.* dep in the API for creating templates means that every module with a custom wizard will need to be rewritten. Perhaps not such a big deal, but I wanted to avoid such a big change just in order to support project-sensitive templates.
What are the cases when TemplateWizard.Iterator is used in API? I am aware of one: when creating new project. That usage does not need any existing modules rewrite, the TemplateWizard usage there is artificial. What are the other cases when it is used?
Will need to look at this. There are really two issues: 1. Currently new project creation requires that the wizard be in Templates/ and use a TW.I, just like any other template. This is completely consistent with creation of many other kinds of objects in the IDE and I am not sure I want to do something wildly different for project creation just because you want to remove deps on loaders. We may need to have a general (buildsys-independent) addition to the wizard API and set of conventions as to where to register wizards. We need to do this anyway for many other kinds of wizards. 2. Creation of new files. Here the API currently uses TW.I for two reasons: a. Compatibility with existing templates in the Templates/ dir with custom wizards. It is possible there is some way to retain compatibility with these without exposing o.o.loaders.* in the public API. Or, more likely, we can just forget about trying to retain wizard compatibility for such templates; very likely they would need to be rewritten anyway to match the revised user model. b. TW.I already exists and describes what is needed to create new objects from template. Without it, will just need to create a new interface which looks more or less identical but is in a different package. Not a big issue. I will concentrate on #2. I am not convinced #1 should be solved here; rather, when we make a real effort to remove Datasystems, we should be providing a reasonable alternative for special (non-file) "template" wizard registration.
I think Petr is already working on this and it should be possible to remove all refs to Datasystems. Re. project creation (also Java platform creation), there will be a new interface such as WizardDescriptor.InstantiatingIterator which will look similar to TW.I but not refer to Datasystems, e.g. public interface II extends Iterator { // throws IOException? probably unnecessary, TBD Set/*<Object>*/ instantiate(); void initialize(WizardDescriptor d); void uninitialize(WizardDescriptor d); } We can use the same for file templates, so that the templateWizardIterator attr (e.g.) would be expected to be of this type. It may be possible to provide a bridge for TW.I instances as well, though this is probably not very high priority since I would expect most existing custom wizards would need to be rewritten anyway.
WizardDescriptor.InstantiatingIterator has been created and implemented by java/project/NewJavaFileWizardIterator, modules can declare this iterator in its layer.
Jirka, next time please paste or attach the commit log into the issue report for future reference.
I'm not sure the original request is actually fixed here. :-) NJFWI.instantiate returns Set<DataObject>, which was exactly what we did not want - we want to return Set<FileObject>. Also IMHO the new file wizard infrastructure should be responsible for running default actions (i.e. open in editor) of newly created files, not the particular wizard. Co Hrebejk?
I am reopening pending an answer to the last comment. I see that NewFile just calls wd.instantiate and discards the result. It should IMHO expect a Set<FileObject> and open them all.
Log: #40894: NJFWI returns set of FileObject instead of DataObject Checking in src/org/netbeans/modules/java/project/NewJavaFileWizardIterator.java; /cvs/java/project/src/org/netbeans/modules/java/project/NewJavaFileWizardIterator.java,v <-- NewJavaFileWizardIterator.java new revision: 1.6; previous revision: 1.5 done
no additional informations for long time - closing