Add developer joy !

[ggrebert]

• DevService
• Auto configure jsch logs
• @JSchSession annotation:
  • configurable by properties
  • named sessions
  • auto connect/disconnect

---

Next step:

• Add @JSchChannel annotation
• auto mount a directory in the devService

[gastaldi]

Perhaps it should be defaulted to false to avoid spinning up a service when it's not needed?

[ggrebert]

Most of extensions in quarkus (datasources, message queues, ...) and quakiverse (mailpit, ...) active the devservices by default,
But I can change this behavior if you want.

[gastaldi]

That's fine I think. My only concern is about spinning up images when they are not needed, but that's okay I guess

[ggrebert]

there is a reuse property which is set to false by default, I can set it to true.
the reason why i have choosed to set the reuse to false by default is:

• when reuse is false, the ryuk auto remove the container
• when reuse is true, TestContainer does not run ryuk so, the container is never stop and removed.
  To me, this use case is usefull for containers which need lots of resources and when we work with multiple services

[gastaldi]

It would be nice to have that explanation added to the docs so we don't lose it

[gastaldi]

About the reuse flag, I think it should be set to false by default. Spinning up a new SSH server is fast and the devservice should IMHO live as long as the app is running

[gsmet]

TBH... I think I would tend to set it to false by default. The reason is that this extension is extremely low level and could be used by a lot of other extensions to connect to SSH.

And in that case, you won't define a client via config and you won't need a dev service.

I'm also a bit torn on the config thing. I would have expected people to use it to connect to all sorts of stuff. Not sure being able to connect to only one server is useful.

Now, maybe I'm missing something as to how/when this library is used. I just want to make sure we don't make the extension impractical for using it as a low level component.

[gastaldi]

Even better: it could be true but the devservice is only started if an injection point is found AND no host is configured for the session

[ggrebert]

Context examples:

• Historical use of Axway to transfer files from server to many servers
  The named session annotation for simple use cases
  And JSchSessions.fromName(String sessionName) method for dynamic use cases

  Due to the interop interface contracts between french telecom operators, the usage of Axway is mandatory for lots of applications

• S3 to SFTP, SFTP to SFTP: create simple and dynamic config at runtime with environment variables

[ggrebert]

we can also create a new extension that depends on this one. (ex: quarkus-jsch-simple)
then we can keep the low level

[gastaldi]

That is really cool! Great job! I'll try it locally before merging and report my findings. Perhaps @ppalaga would be interested too?

[ggrebert]

Thank you <3

[gastaldi]

I find this confusing. It's not really mocking the session, but returning the default session instead.

But I am probably missing the whole picture here. Can you elaborate on the use case this is needed?

[ggrebert]

new doc:

/**
 * Mock the JSch session in dev and test mode:
 * This is useful for testing purposes with devservices where
 * we re-use the default session configuration generated by the devservice.
 */

Is it OK for you ?

[gastaldi]

I understand the reason, but I guess it may be frustrating if you have set up 2 sessions and when you quarkus dev your app, you see that the second session is always connecting to the default session. Perhaps start a different SSH Server for each configured session?

[gastaldi]

Also, start an SSH server only if the host is not defined (this is the same behavior as when defining the URL for Datasources)

[ggrebert]

I think it is fixed

[gastaldi]

I think using io.smallrye.common.annotation.Identifier would be better. Plus, you shouldn't need to use @JSchSession given that the injection type expected is already a Session

[ggrebert]

Yes I can do it with @Identifier.

But I want to be consistent with the future works: create a session by a simple annotation is cool, but it will be even better to create a channel.

I have already thought about it:

package io.quarkus.jsch;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Retention(RetentionPolicy.RUNTIME)
@Target({ ElementType.FIELD })
public @interface JschChannel {

    /**
     * The channel type.
     */
    String value();

    /**
     * The session name.
     */
    String session() default JSchSession.DEFAULT_SESSION_NAME;

}

And i havent find a way to do it with just a simple naming annotation.
I wanted to be consistent with all this extension's annotations. But yes, we can use @Identifier for sessions and for the channels we can see it later and use a custom one.

I'll let you choose the solution that seems the cleanest to you.

[ggrebert]

The injections types for this future annotation are:

• com.jcraft.jsch.Channel
• com.jcraft.jsch.ChannelSftp
• com.jcraft.jsch.ChannelShell
• com.jcraft.jsch.ChannelExec