Creating new application (Java With Maven, Java Application) has main class built ignoring templates

[dgreen]

Apache NetBeans version

Apache NetBeans 13 release candidate

What happened

Creating a new Java with Maven, Java Application generates a Java file with a main. The file is generated ignoring the available template for Java Main Class.

Somewhat unrelated to this issue, clicking on the nbfs: links did not cause any noticeable activity.

How to reproduce

1. File | New Project
2. In popup, choose Java with Maven then Java Application
3. Hit finish on next pop up
4. Generated project has a MavenProject1.java file with a main

It has

/*
 * Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license
 * Click nbfs://nbhost/SystemFileSystem/Templates/Project/Maven2/JavaApp/src/main/java/${packagePath}/${mainClassName}.java to edit this template
 */

package edu.uab.mavenproject1;

/**
 *
 * @author name <email>
 */
public class Mavenproject1 {

    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
}

There is an existing template viewable using Tools | Templates , select Java, then Java Main Class, open in editor

/*
 * Author: ${user}
 * Assignment:  ${project.displayName} - ${course}
 *
 * Credits:  (if any for sections of code)
 */

<#if package?? && package != "">
package ${package};

</#if>
<#if superclass?? && superclass != "" && !superclass?starts_with("java.lang") && !superclass?matches(package + "\\.\\w+")>
import ${superclass};

</#if>
<#if interfaces?? && interfaces != "">
    <#list "${interfaces}"?split("\n") as interface>
        <#if interface?? && interface != "" && !interface?starts_with("java.lang") && !interface?matches(package + "\\.\\w+")>
import ${interface};
        </#if>
    </#list>

</#if>
/**
 *
 */
<#if superclass?? && superclass != "">
    <#assign extension = "${superclass}"[("${superclass}"?last_index_of(".") + 1)..]>
</#if>
<#if interfaces?? && interfaces != "">
    <#assign implementation = "">
    <#list "${interfaces}"?split("\n") as interface>
        <#assign implementation += "${interface}"[("${interface}"?last_index_of(".") + 1)..] + ", ">
    </#list>
    <#assign implementation = "${implementation}"?remove_ending(", ")>
</#if>
public class ${name}<#if extension?? && extension != ""> extends ${extension}</#if><#if implementation?? && implementation != ""> implements ${implementation}</#if> {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        // TODO code application logic here
    }

}

Did this work correctly in an earlier version?

Apache NetBeans 12.6

Operating System

MacOS 12.2.1 (Monterey) M1 Pro

JDK

JDK 17

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

Note: the previous 12.6 did not add a starting file as part of project completion.

Are you willing to submit a pull request?

No response

Code of Conduct

Yes

[mbien]

the second link seems to be broken, but ctrl+click on the first (license template) does work for me.

I could change the template and the next new project did use it, so the mechanism appears to be working.

• second link needs to be repaired
• it should also say "ctrl+click" instead of just "Click" to avoid any confusion
• the template for a new main class does work too, its just that new maven projects have now their own template for some reason instead of using the existing new main class template (edit: changed in #3262)

Thanks for the report.

[mbien]

@sdedic where is the second link actually supposed to point at?

[neilcsmith-net]

This was obviously also brought up recently in https://lists.apache.org/thread/dhlwp3wkglfk9265g362olj2b0dphqoq

I'm curious too why the second link has tokens in it? Is this a mistake in the template in use, or a sign that templating isn't correctly set up at the point it's triggering?

[dgreen]

Confirming that CMD-click (Mac) does work on the first link.

[mbien]

I made some minor improvements to templates with PR #3876.

I did also take a look at this issue here, but tbh I am not even sure how it is supposed to work. For example a new maven specific template was added with App.java.template in this PR but I can't find it under Tools -> Templates. Should it appear there? Or why does each project type ship with its own template instead of using the common "Java Main Class" template (which the user above IMO correctly assumed would influence new project creation).

Gradle project has its own template too, only ANT uses "Java Main Class" template.

@sdedic @JaroslavTulach @lkishalmi @matthiasblaesing Sorry for pinging everyone but this is a cross project type issue :)

[neilcsmith-net]

This issue seems to be automatically bumping through milestones without resolution. @sdedic @mbien thoughts on this?

[mbien]

well i would like to have all new-project wizards use the same new-java-mainclass template. Just like the old ant project did/does. It makes sense for the user too. One file to edit. This would fix the broken link on the new-java-maven-project too which is there since several releases already.

But i don't have the full picture why all the additional templates were introduced in the first place. I suppose part of it is because VSCode. I also learned that the VSCode nb plugin does not have a template manager window, so it heavily relies on those links.

I tried to get rid of some of the links but that was not popular (#3876) - this was supposed to be the easy part. At some point i stopped working on this since I don't know what the requirements are and getting answers is difficult.

[neilcsmith-net]

well i would like to have all new-project wizards use the same new-java-mainclass template. Just like the old ant project did/does.

+1 to that. Is that reasonable to target during NB15 do you think?

I also learned that the VSCode nb plugin does not have a template manager window, so it heavily relies on those links.

I'm curious how you edit those the second time! :wink:

[mbien]

well i would like to have all new-project wizards use the same new-java-mainclass template. Just like the old ant project did/does.

+1 to that. Is that reasonable to target during NB15 do you think?

probably not. I am not going to do that anyway since I don't know the requirements. I pinged everyone in march https://github.com/apache/netbeans/issues/3678#issuecomment-1080221805 and got no reply.

I also learned that the VSCode nb plugin does not have a template manager window, so it heavily relies on those links.

I'm curious how you edit those the second time! wink

customer support probably ;)

[sdedic]

Sorry - missed the ping; will look at this (1-2 days).

[sdedic]

OK; the second link is supposed to lead to the template the file was created from. An the file exists (on the nbfs) in fact:

                <folder name="JavaApp">
                    <folder name="src">
                        <folder name="main">
                            <folder name="java">
                                <folder name="${packagePath}">
                                    <file name="${mainClassName}.java" url="nbresloc:/org/netbeans/modules/maven/resources/App.java.template">
                                        <attr name="javax.script.ScriptEngine" stringvalue="freemarker"/>
                                        <attr name="template.openFile" boolvalue="true"/>
                                    </file>
                                </folder>
                            </folder>
                        </folder>
                    </folder>
                </folder>

So the templating engine (or the template) should be enhanced to properly URLencode special chars (which it does not do at the moment). The replaceable tokens are intentionally in the path to allow substitution from API call parameters.

The other issue is that the entire Java Project structure is not shown in Templates - this should be (somehow) fixed. "Somehow" means that the template UI (Tools | Templates dialog) isn't actually prepared for structured templates, where the user could eventually add conent etc - so some tweak will be needed to present the Maven-main-class template.

The reason why the Wizard does not use the "main" template is because the template instantiation call would invoke another New From Template wizard -- this is how those templates are registered at the moment, and that Wizard does not support being parametrized from outside and run headless. That might be fixed as well - but will be probably more tough.

I can take as a Friday project the first two items (URL encoding / link fix + Templates UI appearance). I cannot promise the last at the moment - although it would be cool to be able to reuse other templates in project structure template.

---

The reason behind this all was to allow to create Maven projects in a non-interactive manner, througj an API (File Templates API) and from a LSP client (that uses the programmatic access).

[neilcsmith-net]

@sdedic I assume a fix for this won't make NB15? If so, could you bump the milestone to NB16?

[dgreen]

On 20 Jul 2022, at 10:26, Michael Bien wrote:

well i would like to have all new-project wizards use the same new-java-mainclass template. Just like the old ant project did/does.

+1 to that. Is that reasonable to target during NB15 do you think?

probably not. I am not going to do that anyway since I don't know the requirements. I pinged everyone in march https://github.com/apache/netbeans/issues/3678#issuecomment-1080221805 and got no reply.

Sorry. Did not realize I was being included specifically as opposed to just a mailing list message.

File URLs:

• Click nbfs://nbhost/SystemFileSystem/Templates/Licenses/license-default.txt to change this license
• Click nbfs://nbhost/SystemFileSystem/Templates/Project/Maven2JavaApp/src/main/java/uab.edu.ee333.mavenproject1/Mavenproject1.java ${packagePath}/${mainClassName}.java to edit this template

What I desire is, in steady state, to have customizable templates with my information being used instead of one or more URLs. I understand new templates may be needed for new situations. In the cited case, there is not a deducible template to create as the second line appears broken — not completely interpolated and clicking (or CMD+clicking on Mac) doesn’t cause any visible action. Tools > Templates does not seem to include any options that suggest the template to create/modify.

I generally write small programs so I use the templates across all projects not new templates for each project. My understanding is that the existing templates are across all projects.

If a template can be established for this generated main from clicking the second line of the inserted URLs, pre-populated with the default content including the URL, and after editing the edited template is used for future use both inside the current and future projects, I think this would be a win.

Certainly one new-java-mainclass seems like a good way to go for command line programs and I was thinking that way went I made the initial post but Javafx (and others) has their own structure (imports, a shell main calling start and a shell launch) and that is helpful. So reuse when appropriate would be great but it most important to have a path to having a template.

I also learned that the VSCode nb plugin does not have a template manager window, so it heavily relies on those links.

I'm curious how you edit those the second time! wink

customer support probably ;)

I have not used this before. Firing it up with the extension “Language Server for Java by Apache NetBeans v14.0.301” on my Mac, and then running the only wizard there for a maven Java project with the same template and two URLs that can be run within VSCode. The same URLs are present, and the first one works option-clicking on it while the second one is unresponsive.

Dave

[neilcsmith-net]

@sdedic would be really good to get some fix for this in NB16!

[neilcsmith-net]

@mbien given nothing from @sdedic and other conversations around default Maven template, should we consider pushing this again towards NB17 and having a more wholesale rethink of this template? Possibly worth considering how Gradle support uses gradle init too, and what the best parallel is?

[mbien]

yes lets push this to NB 17 again. Wondering if we should at least add a patch which removes the broken links on top of the file?

I think the most user friendly approach would be if all java project types could use the same hello world template - unless they want something special (a JavaFX project might want a hello world window).

[neilcsmith-net]

Patch sounds good for now.

I'm more inclined that the default project defers to the build system, eg. like the change made to gradle support. I'm not sure Maven publish an up to date template artefact though?

[mbien]

I don't mind either way. But I think i lean a bit towards staying with NB templates since all the functionality is there and the user can also customize them easily.

There is also the VSCode plugin which may or may not rely on them. I don't know any details which is the main reason why I actually don't want to touch anything. Last time I tried it got -1ed since I didn't consider that VSCode had no template manager window.

[neilcsmith-net]

Just considering whether there should be more consistency with #3084

[mbien]

Just considering whether there should be more consistency with #3084

ultimately I really don't care as long the links are fixed since they are already broken for a while. Its just a hello world with some text substitution - lets not make this too complicated ;)

[neilcsmith-net]

I think we're talking at cross purposes. I don't care about the hello world template aspect of this, I care about having a better default Maven template as a whole (eg. pom changes discussed in relation to --release hint). Bringing things in line with the Gradle project behaviour would remove the problematic template completely.

That's for NB17 discussion. If we can clean the links up for NB16, great!

[mbien]

found a way how to hide it if broken #4891

[neilcsmith-net]

Thanks @mbien - immediate issue with links fixed. Bumping this to NB17 for discussion on whether project templates should ignore file templates or not.

[neilcsmith-net]

Well, that discussion seemed not to have happened. Removing the milestone as it's just bumping from one to the next.