Implementation of "160. Feature Launcher Service Specification" ( issue 21 )

[ideas-into-software]

• The Feature Launcher Command Line ( 160.4.2.4 )

• Refactoring / fixes / improvements

[ideas-into-software]

#21

[ideas-into-software]

Running $ mvn clean package will result in executable uber-JAR which can then be run via

java -jar ./featurelauncher-1.0.0-SNAPSHOT.jar

However, running this way will display missing required argument error, so valid feature file JSON must be supplied, e.g.:

java -jar ./featurelauncher-1.0.0-SNAPSHOT.jar ./gogo-console-feature.json

Implementation: com.kentyou.featurelauncher.cli.FeatureLauncherCli

Relevant integration test: com.kentyou.featurelauncher.cli.FeatureLauncherCliTest

Screencast.from.2024-10-12.02-53-36.webm

[ideas-into-software]

Questions

1. should picocli dependency be included as is, i.e. com.kentyou.featurelauncher.cli.CommandLine ( one of the ways it can be included, as it's self-contained, as per https://github.com/remkop/picocli?tab=readme-ov-file#download ) or as Maven dependency ( also possible, as per https://github.com/remkop/picocli?tab=readme-ov-file#download ) ?

2. except for feature file, should any other options / parameters be required ? currently, only feature file is required, everything else is optional;

3. regarding --artifact-repository option:

   a) section 160.4.2.4 of OSGi compendium specification ( "The Feature Launcher Command Line" ) is silent on the topic of local repositories and its wording for --artifact-repository option implies that only remote artifact repositories are "defined" this way; therefore, since local artifact repository is required as well, it is created "behind the scenes" for the user; please confirm / clarify;

   b) similarly, since --artifact-repository option is not marked as required in the specification ( only for feature file that is implied ), and at least one remote repository is required as well, it is created "behind the scenes" for the user as well IF user does not specify that option; please confirm / clarify;

   c) lastly, please clarify regarding notation defined in specification for --artifact-repository ( uri[,key=value] ), because as it is, if more than one repository is passed with configuration properties having same key, only last value will be used ( key value is replaced ), e.g.:

--artifact-repository="https://repo1.maven.org/maven2/" --artifact-repository=name=central --artifact-repository="https://oss.sonatype.org/content/repositories/snapshots/" --artifact-repository=name=OSSRH ./gogo-console-feature.json

.. will only keep name=OSSRH ( same key, different value ); those are parsed as map, see com.kentyou.featurelauncher.cli.FeatureLauncherCli.remoteArtifactRepositories

4. among other very cool features, "picocli" supports packaging as "GraalVM Native Image" ( https://picocli.info/#_graalvm_native_image ) - is there any use for this, or it's enough as is ?

[timothyjward]

Some minor comments that we can discuss in our call. A couple of them are probably specification tweaks, but the artifact repository issue definitely needs to be worked out so that it's implementable.

[timothyjward]

Questions

1. should picocli dependency be included as is, i.e. com.kentyou.featurelauncher.cli.CommandLine ( one of the ways it can be included, as it's self-contained, as per https://github.com/remkop/picocli?tab=readme-ov-file#download ) or as Maven dependency ( also possible, as per https://github.com/remkop/picocli?tab=readme-ov-file#download ) ?

I would probably prefer the maven dependency route and using the shade plugin, but it doesn't need to be changed now.

2. except for feature file, should any other options / parameters be required ? currently, only feature file is required, everything else is optional;

One of:

• providing a Feature file using -f
  or
• providing JSON directly as the final argument
  is required. Everything else is optional, although failing to provide any artifact repositories will almost certainly result in a launch failure as there will be nowhere to find bundles.

3. regarding --artifact-repository option:
   a) section 160.4.2.4 of OSGi compendium specification ( "The Feature Launcher Command Line" ) is silent on the topic of local repositories and its wording for --artifact-repository option implies that only remote artifact repositories are "defined" this way; therefore, since local artifact repository is required as well, it is created "behind the scenes" for the user; please confirm / clarify;

The user can pass a file: uri which would be local.

b) similarly, since --artifact-repository option is not marked as required in the specification ( only for feature file that is implied ), and at least one remote repository is required as well, it is created "behind the scenes" for the user as well IF user does not specify that option; please confirm / clarify;

This should not happen by default, but a --impl-default-repos flag could be used to add in maven central by default.

c) lastly, please clarify regarding notation defined in specification for --artifact-repository ( uri[,key=value] ), because as it is, if more than one repository is passed with configuration properties having same key, only last value will be used ( key value is replaced ), e.g.:

--artifact-repository="https://repo1.maven.org/maven2/" --artifact-repository=name=central --artifact-repository="https://oss.sonatype.org/content/repositories/snapshots/" --artifact-repository=name=OSSRH ./gogo-console-feature.json

.. will only keep name=OSSRH ( same key, different value ); those are parsed as map, see com.kentyou.featurelauncher.cli.FeatureLauncherCli.remoteArtifactRepositories

The syntax from the specification would be:
--artifact-repository="https://repo1.maven.org/maven2/",name=central --artifact-repository="https://oss.sonatype.org/content/repositories/snapshots/",name=OSSRH -f ./gogo-console-feature.json

We should discuss other syntax if this is problematic.

4. among other very cool features, "picocli" supports packaging as "GraalVM Native Image" ( https://picocli.info/#_graalvm_native_image ) - is there any use for this, or it's enough as is ?

This could be nice in future, but it may be challenging as GraalVM compilation usually needs to know the full application up front and we don't know the content of the feature, or which framework we might be launching. Let's come back to it another time.

[ideas-into-software]

Some minor comments that we can discuss in our call. A couple of them are probably specification tweaks, but the artifact repository issue definitely needs to be worked out so that it's implementable.

All that you requested Tim was resolved via 789aece, minus the key=value syntax for extension handlers ( #26 (comment) ) - in this particular case I think specification would need to be updated.