Containerless Kantra Distribution for Java Analysis #196

eemcmullan · 2024-08-12T18:38:51Z

Closes #188

Signed-off-by: Emily McMullan <[email protected]>

pranavgaikwad

I like the idea overall. I am requesting that we include all pre-requisites for the user to be able to run this on their machines. Also, can we talk about Builtin provider too?

enhancements/containerless-kantra/README.md

pranavgaikwad · 2024-08-13T19:48:07Z

enhancements/containerless-kantra/README.md

+
+Users will be expected to have or install several tools onto their machines, such as OpenJDK and Maven. We will produce and ship our [rulesets](https://github.com/konveyor/rulesets/), JDTLS, and the [Java Bundle](https://github.com/konveyor/java-analyzer-bundle).
+
+The user will be instructed to set these packaged binaries and rules in a known location, such as `$HOME/.kantra/`. Alternatively, an install script can set these.


By setting, do you mean keeping those binaries there? Can we use standard system paths as well as environment variables for this?

For JDT.LS and java analyzer bundle, for unistall purposes it would be nice I think if this was all in .kantra/<folders> for ease of use, Maven, OpenJDK should be system paths and we use the correct env vars ($M2_ and $JAVA_) IMO

Are we going to allow these to be in the system path?

Install script to add .kantra/<folders>/... to path? Or users add it manually? And set those as env vars in kantra? And +1 for using expected env vars for Maven and OpenJDK. @djzager Are you instead thinking of using the binaries from the abs path?

What I meant was that, if a user installs the binary at /usr/local/bin then it should be accessible via Kantra right?

I suppose that what I am suggesting is that we may install stuff at ${XDG_CONFIG_HOME}/.kantra/... but we should encourage the users to set their PATH to include that directory so kantra the CLI is free to just execute them (and not go looking for them or expecting environment variables).

pranavgaikwad · 2024-08-13T19:58:04Z

enhancements/containerless-kantra/README.md

+
+### Technical Implmentation
+
+A new analyze subcommand can be introduced for kantra to recognize when to start the containerized version of analysis versus the non-containerized option. This could look like `kantra analyze-java-only <options>`. Another option for starting the analyze subcommand without running containers would be to detect existing packaged requirements at the expected location discussed in the [requirements](#requirements). However, in this case, we would want to provide an option to disable this behavior.


I like the idea of having an explicit / separate subcommand for this. Keeps things clean for us and users. Think we should discuss more about semantics, analyze-java-only sounds restrictive. Maybe fine right now, but unsure if similar requirement will arise for other providers.

It is "restricte" in that you can't use any other providers (besides builtin which you called out we need to add :) good catch!)

I wish I could come up with a decent analyze-no-container name that could be more generic.

Yea, I am still not sure of this subcommand name, so I'm open to any other suggestions.

The best I could come up with kantra analyze-bin --provider=java, gives us ability to expand to other providers.

I am a +1 on @djzager's flag to add more, or the one in the enhancement

enhancements/containerless-kantra/README.md

djzager

I think this genuinely improves on what I've heard previously discussed. I do somewhat wonder what prevents us from creating a new command altogether (separate go module) and whether that may give us some more flexibility even if in the same repository.

enhancements/containerless-kantra/README.md

djzager · 2024-08-14T18:50:16Z

enhancements/containerless-kantra/README.md

+
+Users will be expected to have or install several tools onto their machines, such as OpenJDK and Maven. We will produce and ship our [rulesets](https://github.com/konveyor/rulesets/), JDTLS, and the [Java Bundle](https://github.com/konveyor/java-analyzer-bundle).
+
+The user will be instructed to set these packaged binaries and rules in a known location, such as `$HOME/.kantra/`. Alternatively, an install script can set these.


Are we going to allow these to be in the system path?

djzager · 2024-08-14T18:51:22Z

enhancements/containerless-kantra/README.md

+
+### Technical Implmentation
+
+A new analyze subcommand can be introduced for kantra to recognize when to start the containerized version of analysis versus the non-containerized option. This could look like `kantra analyze-java-only <options>`. Another option for starting the analyze subcommand without running containers would be to detect existing packaged requirements at the expected location discussed in the [requirements](#requirements). However, in this case, we would want to provide an option to disable this behavior.


I wish I could come up with a decent analyze-no-container name that could be more generic.

eemcmullan · 2024-08-15T20:24:25Z

"I think this genuinely improves on what I've heard previously discussed. I do somewhat wonder what prevents us from creating a new command altogether (separate go module) and whether that may give us some more flexibility even if in the same repository."
@djzager This is an interesting idea. It would make it more light-weight as well if we do not have to build the entirety of kantra for this distribution. I'd be curious to know what others think @pranavgaikwad @shawn-hurley

Signed-off-by: Emily McMullan <[email protected]>

enhancements/containerless-kantra/README.md

shawn-hurley

Understanding why a new InternalProviderClient and not just importaing from external is the only open question in my book

Otherwise this LGTM

enhancements/containerless-kantra/README.md

shawn-hurley · 2024-08-21T22:07:32Z

enhancements/containerless-kantra/README.md

+
+### Technical Implmentation
+
+A new analyze subcommand can be introduced for kantra to recognize when to start the containerized version of analysis versus the non-containerized option. This could look like `kantra analyze-java-only <options>`. Another option for starting the analyze subcommand without running containers would be to detect existing packaged requirements at the expected location discussed in the [requirements](#requirements). However, in this case, we would want to provide an option to disable this behavior.


I am a +1 on @djzager's flag to add more, or the one in the enhancement

enhancements/containerless-kantra/README.md

djzager

This looks good to me. The only two (non-blocking) comments I have are:

To consider documenting that we will start shipping binaries as the release artifacts for kantra (and any other necessary component) as part of this work.
Consider kantra analyze-bin --provider=java as a way to satisfy the requirements with room to grow in the future.

Signed-off-by: Emily McMullan <[email protected]>

djzager

ACK

Signed-off-by: Emily McMullan <[email protected]>

eemcmullan requested review from shawn-hurley and pranavgaikwad August 12, 2024 18:38

eemcmullan changed the title ~~Containerless Kantra for Java Analysis~~ Containerless Kantra Distribution for Java Analysis Aug 12, 2024

containerless kantra for java analysis

309a023

Signed-off-by: Emily McMullan <[email protected]>

eemcmullan force-pushed the containerless-kantra branch from 67dd018 to 309a023 Compare August 13, 2024 15:34

pranavgaikwad reviewed Aug 13, 2024

View reviewed changes

djzager reviewed Aug 14, 2024

View reviewed changes

eemcmullan requested review from djzager and pranavgaikwad August 15, 2024 20:21

update title and requirements

92a549a

Signed-off-by: Emily McMullan <[email protected]>

eemcmullan force-pushed the containerless-kantra branch from 05f06bd to 92a549a Compare August 15, 2024 20:33

dymurray added this to the v0.6.0 milestone Aug 20, 2024

shawn-hurley reviewed Aug 21, 2024

View reviewed changes

enhancements/containerless-kantra/README.md Outdated Show resolved Hide resolved

shawn-hurley approved these changes Aug 21, 2024

View reviewed changes

djzager approved these changes Aug 22, 2024

View reviewed changes

update requirements and cmd name

c96d949

Signed-off-by: Emily McMullan <[email protected]>

djzager approved these changes Aug 22, 2024

View reviewed changes

remove CI/CD refs

cc53e9e

Signed-off-by: Emily McMullan <[email protected]>

eemcmullan merged commit 2380ae9 into konveyor:master Aug 26, 2024
3 checks passed

aufi mentioned this pull request Sep 27, 2024

Containerless support for Java apps konveyor/kantra#338

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Containerless Kantra Distribution for Java Analysis #196

Containerless Kantra Distribution for Java Analysis #196

eemcmullan commented Aug 12, 2024

pranavgaikwad left a comment

pranavgaikwad Aug 13, 2024

shawn-hurley Aug 13, 2024

djzager Aug 14, 2024

eemcmullan Aug 15, 2024

djzager Aug 21, 2024

pranavgaikwad Aug 13, 2024

shawn-hurley Aug 13, 2024

djzager Aug 14, 2024

eemcmullan Aug 15, 2024

djzager Aug 21, 2024

shawn-hurley Aug 21, 2024

djzager left a comment

djzager Aug 14, 2024

djzager Aug 14, 2024

eemcmullan commented Aug 15, 2024

shawn-hurley left a comment

shawn-hurley Aug 21, 2024

djzager left a comment

djzager left a comment


		Users will be expected to have or install several tools onto their machines, such as OpenJDK and Maven. We will produce and ship our [rulesets](https://github.com/konveyor/rulesets/), JDTLS, and the [Java Bundle](https://github.com/konveyor/java-analyzer-bundle).

		The user will be instructed to set these packaged binaries and rules in a known location, such as `$HOME/.kantra/`. Alternatively, an install script can set these.


		### Technical Implmentation

		A new analyze subcommand can be introduced for kantra to recognize when to start the containerized version of analysis versus the non-containerized option. This could look like `kantra analyze-java-only <options>`. Another option for starting the analyze subcommand without running containers would be to detect existing packaged requirements at the expected location discussed in the [requirements](#requirements). However, in this case, we would want to provide an option to disable this behavior.

Containerless Kantra Distribution for Java Analysis #196

Containerless Kantra Distribution for Java Analysis #196

Conversation

eemcmullan commented Aug 12, 2024

pranavgaikwad left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

djzager left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eemcmullan commented Aug 15, 2024

shawn-hurley left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

djzager left a comment

Choose a reason for hiding this comment

djzager left a comment

Choose a reason for hiding this comment