When an .adoc file includes source content delimited by tags and there is no content a freemarker exception is thrown.

An example of an adoc file reproducing this would be like this:

// tag::importsHealth3[]
// end::importsHealth3[]

The exception is as follow:

[ERROR] ----
[ERROR] FTL stack trace ("~" means nesting-related):
[ERROR] 	- Failed at: ${content}  [in template "vuetify/document" at line 21, column 1]
[ERROR] ----: InvocationTargetException: An error occurred during rendering of vuetify/block_section: Error during getter invocation: node=org.asciidoctor.ast.impl.SectionImpl@4a30c120, methodname=getContent
[ERROR] 
[ERROR] ----
[ERROR] FTL stack trace ("~" means nesting-related):
[ERROR] 	- Failed at: #assign _content = content  [in template "vuetify/block_section" at line 16, column 1]
[ERROR] ----: Error during getter invocation: node=org.asciidoctor.ast.impl.SectionImpl@66ce9b99, methodname=getContent
[ERROR] 
[ERROR] ----
[ERROR] FTL stack trace ("~" means nesting-related):
[ERROR] 	- Failed at: #assign _content = content  [in template "vuetify/block_section" at line 16, column 1]
[ERROR] ----: Error during getter invocation: node=org.asciidoctor.ast.impl.SectionImpl@4e2c82a6, methodname=getContent
[ERROR] 
[ERROR] ----
[ERROR] FTL stack trace ("~" means nesting-related):
[ERROR] 	- Failed at: #assign _content = content  [in template "vuetify/block_section" at line 16, column 1]
[ERROR] ----: An error occurred during rendering of vuetify/block_listing: The following has evaluated to null or missing:
[ERROR] ==> content  [in template "vuetify/block_listing" at line 20, column 4]
[ERROR] 
[ERROR] ----
[ERROR] Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing</#if>. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)??
[ERROR] ----
[ERROR] 
[ERROR] ----
[ERROR] FTL stack trace ("~" means nesting-related):
[ERROR] 	- Failed at: ${content}  [in template "vuetify/block_listing" at line 20, column 2]
[ERROR] ----
[ERROR] -> [Help 1]

The template does expect a non empty value, it should be improved to handle this better: either fail nicely or allow an empty value.

Maintain a user preferences config file at ~/.helidon/config.

All the options should map CLI options.
Some options might be fully hidden, others might need to be exposed with a special flag (e.g. --help-extra)

Or we introduce a new category of options (global options, config options, command options)

Once we have the new archetype mechanism is in place, and we configure the helidon-maven-plugin as required in #135, and there has been a helidon release containing it, do the following:

• set CommandAssertions.MINIMUM_HELIDON_VERSION to the release version
• remove precondition in CommandTest
• remove try/catch in AppTypeBrowserTest

We should have logic in the cli to resolve the latest Helidon version from Maven Central.
This will allow for making the CLI loosely couple with the Helidon versions and have the CLI binaries work with many Helidon versions.

The latest version can be resolved by downloading the maven-metadata.xml file, e.g. maven-metadata.xml:

<metadata>
  <groupId>io.helidon</groupId>
  <artifactId>helidon-bom</artifactId>
  <versioning>
    <latest>2.0.0-M1</latest>
    <release>2.0.0-M1</release>
    <versions>
      <version>1.4.1</version>
      <version>1.4.2</version>
      <version>1.4.3</version>
      <version>2.0.0-M1</version>
    </versions>
    <lastUpdated>20200309220605</lastUpdated>
  </versioning>
</metadata>

Code snippet may not be suitable for being copied, add an attribute to disable the copy to clipboard button on source blocks.

AsciiDoctor allows this:

Refer to <<otherPlace>>.

where the otherPlace ID is defined like this on a heading:

[[otherPlace,Here is the other place]]
## Other place

The rendered text at the link should be Refer to Here is the other place but in our rendered vuetify output there is no text; the output is Refer to. AsciiDocFX (for example) renders as expected.

Workaround: just specify the reference text on the referring link.

I need to do the following to get AsciiDoctor to substitute an attribute that contains backticks for monospacing:

:mapped-config-id-callout: The identifier must be `cors`.
<1> {blank}
+
[subs=attributes+]
{mapped-config-id-callout}

This displays as expected with IntelliJ's AsciiDoctor plug-in and also using the asciidoctor command to generate HTML. But on our site the callout number is there but the text is blank.

1. Add keystore file and use maven-jarsigner-plugin to create jar.
2. Re-enable JarTest.

Ordering is currently done by natural sorting of document names. Using a prefix with double digit numbers is an easy way to do that, e.g.:

• 01_bar.adoc
• 02_alice.adoc

However this produces URLs like /#01_bar and /#02_alice.
It would be better if it were just /#bar and /alice.

This can be done with a regular expression to generate the vuejs path. ^[1-9][1-9]_.*, the matched group would be the actual path for the document.

The site search returns empty results when the query includes '-'.
See https://github.com/oracle/helidon/issues/452

Related to #67.

The constants should be updated so that all of the tests that rely on them will run against the new versions.

The search on the Doc pages doesn't handle '-'. As a consequence, a query on 'jax-rs', 'json-p', 'json-b' leads to zero result.

A card like below does not specify an icon, and this results with an horizontal separator at the top of the card.

[CARD]
.Create a RESTful Web Service Using Helidon SE
--
Use Helidon SE to create a RESTful web service that accepts HTTP requests.
--

Add support for http_proxy HTTP_PROXY https_proxy HTTPS_PROXY noproxy NOPROXY no_proxy and NO_PROXY in the CLI.

Add sort-of hidden options for these (something that can also be set in the user preferences file if we have one).

Decide how to handle noproxy NOPROXY no_proxy and NO_PROXY when converting these to -Dhttp.nonProxyHost.

When I run tests, the ClassDataSharingTest gets stuck on:

Creating base image: target/helidon-quickstart-mp/target/mp-jri
Installing 156 application jars in target/helidon-quickstart-mp/target/mp-jri/app
  checking index in CDI beans archive helidon-quickstart-mp.jar
  creating missing index for CDI beans archive helidon-microprofile-server-2.0.0-M1.jar
  creating missing index for CDI beans archive jersey-weld2-se-2.29.1.jar
  creating missing index for CDI beans archive helidon-health-checks-2.0.0-M1.jar
  creating missing index for CDI beans archive helidon-microprofile-fault-tolerance-2.0.0-M1.jar
Creating startup class list for helidon-quickstart-mp.jar

I have added a workaround to TestFiles that limits the versions to 1.x (see line 184). If you revert this workaround to just look for latest version, it will fail (even local builds).

Currently the Vuetify output does not support the AsciiDoctor-standard TOC processing.

It would be nice to add this feature.

It looks like a table width setting using

[width=75%]
|===
...

is ignored in the vuetify output.

Including Maven output

• Test windows with all kinds of shells:
  • cygwin
  • bash
  • mingw bash
  • mks bash
  • bat
  • bash on windows 10
  • powershell
• Test on macos (latest two versions)
• Test on linux (any distro)

Add support for vanity URLs, e.g. https://helidon.io/docs/latest/guides/

This can be done with HTML redirects and having index.html files nested under existing directories ; this should also work with GitHub pages.

This is a must have for 2.0.

When a pom change results in a build failure, currently we just wait and retry. When we can, we should wait for another change before retrying. We can't do this on the initial build because we don't have a Project instance yet, but we can on subsequent iterations.

If mvn is a symlink, the following error is reported:

error: maven-core-* not found in /usr/local/lib

E.g. /usr/local/bin/mvn -> /opt/apache-maven-3.6.3/bin/mvn

The code in MavenCommand.mavenHome() resolves the home at /usr/local instead of
/opt/apache-maven-3.6.3 and then it tries to find the maven-core jar, under /usr/local/lib instead of /opt/apache-maven-3.6.3/lib/

This is a nice to have feature on top of #122

When a CLI update is detected, prompt the user for download and print install instructions upon download.

While testing the 1.4.2 release candidate the helidon-quickstart-se example failed when building with Dockerfile.native:

Caused by: java.lang.UnsupportedClassVersionError: 
io/helidon/build/maven/graal/GraalNativeMojo has been compiled by a more recent 
version of the Java Runtime (class file version 53.0), this version of the Java Runtime 
only recognizes class file versions up to 52.0

This appears to be because the build-tools plugin is now built targeting Java 9 (https://github.com/oracle/helidon-build-tools/blob/c982510aa6361a7be50cf0225328f9adaa954f17/pom.xml#L176) but the 1.4.X Dockerfile.native uses the Java 8 version of GraalVM 19.3 (https://github.com/oracle/helidon/blob/3d76fd91215cab3ec7c9aae06bb5aee64a3a1872/examples/quickstarts/helidon-quickstart-se/Dockerfile.native#L18).

Options:

1. Change the build-tools plugin to target Java 8, but maybe that breaks the jlink image support.
2. Revert 1.4.x to use the previous version of build-tools, and abandon jlink image support in 1.4
3. Require Java 11+ when building native images (and jlink images) on 1.4. But this would break backwards compatibility with folks using a Java 8 version of graalvm.

Any of these options will require code changes and a rebuild.

Filter the maven output for the prime build and various other maven output.

We are currently using GraalVM to compile the CLI, but the resulting binary is not standalone. Doing so creates all sorts of problems that need further analysis --for example the property "java.home" is not available. We should investigate this for the next milestone.

Projects can be generated using various mechanisms:

• cli
• maven-archetype-plugin
• helidon-archetype-maven-plugin (not implemented yet)

The cli has option mappings for the common archetype properties (groupId, artifactId, version, name, package), with hard-coded default values.

We should derive these from the archetype instead, so that we avoid the duplication and let these values be customized per archetype.

If we end-up with duplication in the archetype descriptors, we can think of an include mechanism for the archetype descriptor itself.

In particular feasibility of using it with Graal native. Seems that it has very little dependencies but we need to make sure it compiles.

Implement a catalog descriptor and required tooling:

• POJO
• SAX reader
• Maven tooling (packaging type + plugin to check and attach the artifact).
• Replace the current "catalog" implementation

The descriptor should provide some information for each archetype:

• id (short, no white spaces, lowercase only)
• name (short, human readable, capitalized, with spaces etc.)
• description
• flavor SE|MP

Add a way to display the list of archetypes non interactively.

Maybe something like helidon init --list

Figure out the final layout for the CLI downloads on helidon.io, and implement the changes on helidon-site.

E.g.

https://helidon.io/cli/latest -> 2.0.0
https://helidon.io/cli/2.0.0/linux/helidon
https://helidon.io/cli/2.0.0/darwin/helidon
https://helidon.io/cli/2.0.0/windows/helidon

The above produces a download step like this:

curl -O https://helidon.io/cli/latest/linux/helidon

Or:

https://helidon.io/cli/latest -> 2.0.0
https://helidon.io/cli/2.0.0/helidon-cli-linux
https://helidon.io/cli/2.0.0/helidon-cli-darwin
https://helidon.io/cli/2.0.0/helidon-cli-windows

The above produces a download step like this:

curl -o helidon https://helidon.io/cli/latest/helidon-cli-linux

There is currently no way to make a card clickable.

[CARD]
.Config
[icon=settings]
--
A flexible configuration framework with support for multiple sources and formats.
--

I'm thinking of adding an attribute link like below:

[CARD]
.Config
[icon=settings, link=config/08_supported-formats.adoc#Config-ModuleHocon]
--
A flexible configuration framework with support for multiple sources and formats.
--

For the dev command to function, we need to ensure the following property is present:

<version.helidon.plugin>XX</version.helidon.plugin>

as well as this plugin declaration:

<plugin>
    <groupId>io.helidon.build-tools</groupId>
    <artifactId>helidon-maven-plugin</artifactId>
    <version>${version.helidon.plugin}</version>
    <extensions>true</extensions>
</plugin>

We had discussed putting this in the application parent pom rather than embedding it in the new archetype templates. However, this makes it more difficult for the CLI to configure the plugin version, since it is not part of the templates.

Add a mechanism to lookup new versions of the CLI and notify users.
This will enable quick iterations on the CLI releases to fix bugs.

This is not an auto-update or auto-download feature, only a lookup + log message.

If we maintain a user preference file, then we can have an option to disable the check.
We should also maintain a file for the last check timestamp in order to avoid checking the updates for every command invocation ; (the interval can perhaps be configureable as well).

We would implement this with a file that we publish at helidon.io, e.g.:

• helidon.io/latest-cli-info.txt

This file would at least contain an entry for the latest version.
It can also contain an entry for the latest Helidon version, which would remove the need to handle the maven-metadata.xml file.

We should provide a sort-of hidden option to control the URL of the info file.

That file can also contain some kind of changelog to inject a special message in the notification that justifies why one should update. (E.g. CVE-XXX)

Demonstrate ability to do syntax coloring when GraalVM and multi-processes are in the picture.

Like Quarkus and Spring Initializr, provide a RESTful APIs and UI for developers to generate Helidon projects quickly.

• Quarkus Code
• Spring Initializr

Current support is based on a properties file. There should be a way for the CLI to detect features dynamically.

There are many configuration options for the maven-compler-plugin that, if specified, will cause the current javac based build step to fail (e.g. includes / excludes, compiler args, etc.).

We cannot / should not attempt to replicate every feature in the plugin, so we must be able to use the plugin itself, at least in those cases where we detect that the javac step is insufficient. However, even detecting that case is challenging and will lead to a maintenance headache.

Given that executing the compiler plugins directly is both straightforward and fast enough, we should make this the default (and maybe only) implementation.

The same approach should be used for resources.

The init command currently hard codes the java package of the generated project. Need to be able to override that.

Version: 2.0.0-M3
Steps to reproduce

>> helidon init --version 2.0.0-M2 --flavor mp
Creating helidon-quickstart-mp using version 2.0.0-M2
Switch directory to ./helidon-quickstart-mp to use CLI

>> cd ...; helidon dev

| building (full)
| build completed (1.8 seconds)
| helidon-quickstart-mp starting

Exception in thread "main" java.lang.NoClassDefFoundError: io/helidon/microprofile/server/Server
        at io.helidon.examples.quickstart.mp.Main.startServer(Main.java:59)
        at io.helidon.examples.quickstart.mp.Main.main(Main.java:46)
Caused by: java.lang.ClassNotFoundException: io.helidon.microprofile.server.Server
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:602)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
        ... 2 more

Replacement for Maven archetype toolchain suitable for implementing helidon init properly.

Requirements

• Nice interactive user experience (terminal prompts)
• Structured properties to support conditions (e.g. if ${jpa} then ask ${data-source})
• Map files and templates to archetype properties
• Standalone (can be invoked without mvnw, without pom.xml, just java)
• Support Maven Archetype (can be wrapped by a maven archetype to support creating project with IDE tooling based on maven archetype)

Maven Archetype issues

• Flat properties structure (How to support conditions?)
• No property description (How to describe the properties on the interactive command prompt?)
• No optional files (How to include certain files only when certain properties are set?)
• Requires Maven (How to bootstrap from the cli ? How about Gradle?)

Building on Windows. There are some failing tests (see attached build log for details). Project builds fine with -DskipTests.
build.log

Implement a bridge between the maven-archetype-plugin and our archetype mechanism.

• Generate a archetype.xml that is compatible with the maven archetype plugin
• Use a post-archetype groovy script to trigger generation of the archetypes

Add connect and read timeout to the HTTP calls within AppTypeBrowser.

• Investigate if we need to sign the binary. (moved to #120)

This is nice to have for post 2.0

Support for multi module will enable the use of the CLI for applications with multiple modules, especially microservice examples composed of more than one application.