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.
Created attachment 163896 [details] The patch NetBeans should have support for creating projects with the NetBeans HTML/Java API (http://bits.netbeans.org/html+java/1.3/index.html). There already is some support for creating Wizards, and TopComponents in Plugin projects, but this is limited to plugin development. The NetBeans/HTML (aka DukeScript) is also a great general purpose Java client technology and a great alternative to Swing and JavaFX. So far users need to install an external plugin to create applications with it, or to use maven on the command line. I think it's a shame that this great part of our beloved IDE is not given a little more attention. That's why I propose to add a project type for Java/HTML-based client project. I've created a patch and added a new TemplateRegistration to the „maven“ module. I chose this module, because it already has other project templates based on maven archetypes (e.g. JavaFX). So I followed this example. The patch doesn’t make any changes in existing Java code, except that it fixes a bug in templatesui AbstractWizard which I found during testing (threading issue). I’m a long time member of the NetBeans community (maxnitribitt==Toni Epple), and I’m willing to maintain this integration as an external contributor also for future releases. The Maven archetypes (https://github.com/dukescript/maven-archetypes/releases) are also maintained by my company (Dukehoff GmbH) and have been in active use and development for more than 2 years. My company and I are committed to this project and will dedicate as much time as needed for maintaining this project. The patch ads a new Project type to the JavaFX category (see screenshot1). From there the wizard collects user input to parametrize the archetype (see screenshots2-5). I’m not sure if that category is a good match, and would ask for advice where to best put it. Ideally there would be a separate category, or maybe it should go to the main Java category like Swing Projects (?). Also „JavaFX WebView Application“ is probably not a good description. Some feedback here would also be appreciated. It would be great to finally have adequate support for this great part of NetBeans, so I ask for your support and feedback for this small, but important, enhancement.
Created attachment 163897 [details] screenshots mentioned in text
Toni, I don't think the patch is correct. It seems to contain some API changes done by Tomáš Zezula.
Created attachment 163923 [details] the real patch
Thanks for the fix in templatesui/src/org/netbeans/modules/templatesui/AbstractWizard.java, but: Y01 Why is the diff changing so many lines? Did you reformat the source? Can you patch the file gently and just use the EventQueue.invokeLater and leave the other parts of the source unchanged? Y02 The wizard hard-codes references to 0.13 version of the archetypes. Unless I am mistaken, there are newer versions: http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.dukescript.archetype%22 - don't you want to reference the most recent ones?
Created attachment 163924 [details] updated patch
TS01 the new wizard page has a different look than the typical NetBeansUI (fonts etc.). Any chance to do something about it? TS02 a lot of new dependencies. Are all them really necessary? TS03 MavenUtilities.getDefault() etc. - there should be a better way how to access the settings file. See MavenEmbedder.getSettings() and how o.a.maven.Settings is used, maybe it can be of some help. thanks
(In reply to Tomas Stupka from comment #6) > TS01 the new wizard page has a different look than the typical NetBeansUI > (fonts etc.). Any chance to do something about it? Yes, I can style it differently. Is there a list of fonts, sizes and colours for the different platforms that I can use?
(In reply to Tomas Stupka from comment #6) > TS02 a lot of new dependencies. Are all them really necessary? > new patch has less dependencies.
Created attachment 163933 [details] less dependencies
(In reply to Tomas Stupka from comment #6) > TS03 MavenUtilities.getDefault() etc. - there should be a better way how to > access the settings file. See MavenEmbedder.getSettings() and how > o.a.maven.Settings is used, maybe it can be of some help. I tried using Maven DefaultSettingsWriter, but this way all comments and formatting are lost.
> (In reply to Tomas Stupka from comment #6) > > TS01 the new wizard page has a different look than the typical NetBeansUI > (In reply to Tomas Stupka from comment #6) thinking it over one more time - currently all the wizards in maven project are swing/nb based and i see no good reason why the DukeScriptWizard should be now implemented by a different technology and by introducing new dependencies on top of it. Being consistent with how other wizards are made in maven, this problem would be off the table and we would save 4 new dependencies. > > TS03 MavenUtilities.getDefault() etc. - there should be a better way how to > I tried using Maven DefaultSettingsWriter, but this way all comments and formatting are lost. hm, would guess that the settings api is able to deal with it ... the problem with MavenUtils is that is be quite easy to break.
Re. TS02 - thanks for pointing this out. Yes, the new dependencies are an issue. The problem isn't that there is many of them (all of the modules are already in the NetBeans Platform), but that some of them need JavaFX. There are some JDKs that don't provide JavaFX by default (IcedTea or OpenJDK come to my mind) and with the new dependency on HTML UI API the whole Maven module would get disabled on such platforms. That's certainly an undesirable behaviour. I see two solutions: 1) rewrite the UI to Swing 2) move the wizard definition to separate module Tomáš already explained why #1 would be good and keep things simple. As somebody who believes Swing days are over and that HTML is a way to go I want to advocate #2: it wouldn't affect existing behaviour and it would be a great chance to explore the HTML approach and pave path to future followers. Btw. Toni is a great UI expert and I am sure he can polish the UI to look great. The overall situation reminds me of the Equinox case[1] (1st in the Platform unused, then used by the IDE to run Mylyn, then powering JDeveloper as the fastest OSGi container on the Planet). I'd like the follow the same pattern in this case - as such I prefer #2. [1] http://wiki.apidesign.org/wiki/Netbinox
(In reply to Jaroslav Tulach from comment #12) Re. TS02 - I would also be in favour of #2, since the idea of the wizard is to offer an alternative to Swing, it would be strange to write it in Swing. I'm at a conference now, but should be able to prepare a patch tomorrow after the talks. Re. TS01 It's no problem styling it to make it look less alien, as soon as we've fixed the other problems. If there's a design document for fonts and colours, that would simplify things.
Btw. I have just integrated the deadlock fix: http://hg.netbeans.org/core-main/rev/1886b9d908cb
The dependency issue pointed out by jarda makes #2 the right way to go. As a side remark - a showcase should not be realised on the cost of mixing up different approaches at literally the same place, for the same kind of thing. re design document for fonts and colours - i'm not aware about any. Most of it is given somewhere behind the curtains of NetBeans UI/L&F. Just note that every time some default for a font, color etc changes, you probably will have to straigthen it up in your implementation as well. re o.a.mave.Settings - maybe the problem isn't in DefaultSettingsWritter, but how the settings file is read in the first place - skipping comments etc. and therefore they are later not written. Found a isStrict flag in DefaultSettingsReader, perhaps worth to have a look on it.
lets create a new module and call it something like - maven.javafx, or maven.htmljava, or maven.htmlui. Once the name is set, we can add the module as a friend to maven.embedder so that the settigns api can be accessed.
(In reply to Tomas Stupka from comment #15) > re o.a.mave.Settings - maybe the problem isn't in DefaultSettingsWritter, > but how the settings file is read in the first place - skipping comments > etc. and therefore they are later not written. Found a isStrict flag in > DefaultSettingsReader, perhaps worth to have a look on it. I've seen the flag, you can set it using the options Map. I tried with true/false. It makes no difference, comments are skipped.
(In reply to maxnitribitt from comment #17) > (In reply to Tomas Stupka from comment #15) > > > re o.a.mave.Settings - maybe the problem isn't in DefaultSettingsWritter, > > but how the settings file is read in the first place - skipping comments > > etc. and therefore they are later not written. Found a isStrict flag in > > DefaultSettingsReader, perhaps worth to have a look on it. > > I've seen the flag, you can set it using the options Map. I tried with > true/false. It makes no difference, comments are skipped. Settings cannot keep comments (http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.maven/maven-settings/2.0.8/org/apache/maven/settings/Settings.java/?v=source). Should I use XML Parser instead to make sure that valid XML is produced?
How about sthg. like this. Makes sure it's valid xml and keeps comments: try { String path = "thePath"; File settingsFile = settingsFile = new File(new File(new File(System.getProperty("user.home")), ".m2"), "settings.xml"); DocumentBuilderFactory dbFactory = DocumentBuilderFactory.newInstance(); DocumentBuilder dBuilder; dBuilder = dbFactory.newDocumentBuilder(); Document settings = dBuilder.parse(settingsFile); settings.getDocumentElement().normalize(); NodeList profiles = settings.getElementsByTagName("profiles"); Node parent = profiles.item(0); Document doc = parent.getOwnerDocument(); String fragment = "<profile>\n" + " <id>android.sdk.path</id>\n" + " <activation>\n" + " <property>\n" + " <name>!android.sdk.path</name>\n" + " </property>\n" + " </activation>\n" + " <properties>\n" + " <android.sdk.path>" + path + "</android.sdk.path>\n" + " </properties>\n" + " </profile>\n"; Node fragmentNode = DocumentBuilderFactory .newInstance() .newDocumentBuilder().parse( new InputSource(new StringReader(fragment))) .getDocumentElement(); fragmentNode = doc.importNode(fragmentNode, true); parent.appendChild(fragmentNode); doc.getDocumentElement().normalize(); TransformerFactory transformerFactory = TransformerFactory.newInstance(); Transformer transformer = transformerFactory.newTransformer(); DOMSource source = new DOMSource(settings); StreamResult result = new StreamResult(settingsFile); transformer.setOutputProperty(OutputKeys.INDENT, "yes"); transformer.transform(source, result); } catch (ParserConfigurationException ex) { Logger.getLogger(MAin.class.getName()).log(Level.SEVERE, null, ex); }
Created attachment 163984 [details] proposed patch for TS02 and TS03
hm, bad luck with o.a.m.Settings see attached patch - added maven/FileUtilities.getSettings() which gets (and eventually creates settings.xml) so that you are consistent with how it is done on other places in nb/maven otherwise ok for me
Created attachment 163992 [details] <no description>
Created attachment 164052 [details] Styling and getSettings
I updated the patch to use getSettings and platform specific styling to look similar to the rest of the wizards.
Created attachment 164058 [details] updated diff It seems the patch is corrupted. Strange, I created a fresh clone of main-silver, then applied Thomas patch and after that added my module. Then I used NetBeans "Export uncommitted Changes" to create and directly upload to the issue. This is the diff created with hg diff
Created attachment 164059 [details] missing files
https://hg.netbeans.org/ergonomics/rev/06d94994f818
Created attachment 164060 [details] Slightly too dark background on Linux+Metal Looks fine, integrated. Few improvements may be done later.
(In reply to Jaroslav Tulach from comment #28) > Created attachment 164060 [details] > Slightly too dark background on Linux+Metal > > Looks fine, integrated. Few improvements may be done later. Thanks for the help. Yes, it seems I accidentally used the Nimbus background, metal should be rgb(238,238,238);.
Integrated into 'main-silver', will be available in build *201704110002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/06d94994f818 User: Toni Epple <maxnitribitt@netbeans.org> Log: #270140: Add Java/HTML Maven Archetypes