kordamp / gm Goto Github PK

https://github.com/jbangdev/jbang lets you launch Java/Jshell sources. It also sports a local wrapper.

Suggested by @shelajev.
Keeping @maxandersen happy 😄

Apparently PowerShell prefers $Env:Path.

What do you think if gm verifies the checksum of gradle/wrapper/gradle-wrapper.jar file?

Of course, it won't make the build completely secure (e.g. a malicious repository could augment gradlew to use a different jar for classpath), however it might improve things since text files (e.g. build scripts, batch scripts are easier to review than binary jars).

An alternative (or additional) option is to verify the integrity of gradlew and gradlew.bat (e.g. hard-code well-known good checksums)

An alternative option is to use gw-controlled set of gradlew executables (and gradle-wrapper.jar) so gw uses a trusted wrapper.

URL pattern is https://github.com/sormuras/bach/releases/download/${BACH_VERSION}/build.jsh

Ensure a default ${BACH_VERSION} is configured in .gm.toml.

Why would I suggest that? Reason is quite simple. On Windows with Powershell, ie. all current versions of Windows gm is something else. It's Get-Members command.

Technically user can use gm.exe explicitly which resolves the problem, but it's a quite weird. As far as I know gum or gum.exe does not conflict with anything common.

Note: I'm working on scoop package manifest and I use scoop shim which is a workaroudn for this. Unpleasant fact of this solution is, that on Windows shim is not your program directly but intermediary binary.

Support the following goals/tasks

Both ways

| Maven           | Gradle
| exec:java       | run
| dependency:tree | dependencies

Gradle -> Maven

| check           | verify
| jar             | package

Gum 0.4.0 autodetects Gradle first.

trying to use gm with jbang build which has a install task so gm build install fails as it tries publish to maven local which is not right.

reading docs I thought -gr should force it to skip but gm -gr spotlessApply build install still tries doing publish to maven.

What am I missing ?

(using latest brew install)

Workaround for gradle/gradle#14756

Allow Maven goals to be replaced by Gradle tasks and viceversa, for example invoking gm build on a Maven project should result in gm verify. The following goals/tasks should be taken into consideration

| Maven   | Gradle
| compile | classes
| package | assemble
| verify  | build
| install | publishToMavenLocal

https://github.com/sormuras/bach/

I dislike the fact that commands panic when run without the arguments. It's unacceptable.

> gum.exe
panic: value method github.com/kordamp/gm/gum.MavenCommand.Execute called using nil *MavenCommand pointer

goroutine 1 [running]:
github.com/kordamp/gm/gum.(*MavenCommand).Execute(0x0)
        <autogenerated>:1 +0xb0
main.main()
        /home/runner/work/gm/gm/src/github.com/kordamp/gm/gm.go:56 +0x27f

Something like, use -gh for help or print help directly with different than 0 exit code is still better.

Recently I was updating my brew formulas (not gm, but others), and brew outputted the following warning:

Warning: Calling bottle :unneeded is deprecated! There is no replacement.
Please report this issue to the kordamp/tap tap (not Homebrew/brew or Homebrew/core):
  /usr/local/Homebrew/Library/Taps/kordamp/homebrew-tap/Formula/gum.rb:10

Allow certain settings to be defined externally. Use TOML as format.
Should support merging project & user ($HOME) settings.

Invoking gm -X build is not the same as gm build -X. The former does not perform goal substitution while the latter will, as expected.

Discovered during the #hackergarten at Javaland 2021

Sometimes the wrapper script is not executable. Gum currently invokes the wrapper script anyway and nothing will happen as a result.

Gum should check if the file is executable or not. Output an error and fail immediately when that't the case as the presence of a wrapper indicates the project should use it.

For a project layout as

.
├── build.gradle
├── gradle
│   └── wrapper
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradle.properties
├── gradlew
├── gradlew.bat
├── settings.gradle
└── subprojects
    └── project1
        └── project1.gradle

The root project is resolved as project1.gradle instead of build.gradle.

It's called .bach/bin now and contains platform-specific launch scripts, a JShell overlay API, and the Bach module.

Checking for .bach/bin (Bach 17) prior to .bach/cache (Bach 16) should do the trick.

Running gm with Gradle 7.1.1 produces the following message

Specifying custom build file location has been deprecated. This is scheduled to be removed in Gradle 8.0. Consult the upgrading guide for further information: https://docs.gradle.org/7.1.1/userguide/upgrading_version_7.html#configuring_custom_build_layout

These flags instruct gradle where the start directory should be instead of the default (current directory).

The following command line

-am -pl :project compile

is parsed in such way that -pl is set as argument of the -am flag.

Invoking gm -b location/to/build.gradle does not execute the explicitly defined build file as it should.

If Bach 17 is to be executed in the current directory and there's no .bach subdirectory, the canonical way to initialize and run Bach 17 is a two-step story:

• jshell https://bit.ly/bach-init
• .bach/bin/bach <ARGS>

The latter is a short-cut for java --module-path .bach/bin --module com.github.sormuras.bach <ARGS>

Add a -gc flag that prints out the current configuration.

gm only checks to see if the file "mvn.bat" is on the path. In Maven 3.6.3, only mvn.cmd is provided as a windows executable.
Workaround was to create a mvn.bat file as follows.
call mvn.cmd %*

It would be nice if it detected it correctly.

As gradle does not include the distributionSha256Sum by default in the gradle-wrapper.properties (gradle/gradle#12412) it would be great if gm could offer support for validating/injecting this as well. Especially if users are using a mirror url.

The version and type could be inferred from the url if it is just a transparent mirror.

The checksums can be retrieved here https://gradle.org/release-checksums/ or from https://services.gradle.org/versions/all

This is related to #39 which validates the committed gradle-wrapper.jar and shell scripts.

In a Gradle build, when a command is given such as

gm :subproject:install

The expectation is to invoke the publishToMavenLocal task on the :subproject project.

https://forum.snapcraft.io/t/request-for-classic-confinement-gum/21219

Invoking gm -f location/to/pom.xml does not execute the explicitly defined build file as it should.

Add timestamp and git commit

Add a flag to the config format that can be used to specify the order in which source files should be discovered.
Default order remains java, jsh, jar.

For a project layout as

.
├── pom.xml
└── subprojects
    └── project1
        └── pom.xml

The root project is resolved as subprojects/project1/pom.xml instead of ./pom.xml.