 Good evening everyone. I am Mohit. I'm based out of India. I work at Red Hat as a senior software engineer. And today we are going to see that how easy it can be to deploy your Java applications on OpenSAFE instance and performing an end-to-end environment using a VS Code editor. So as a normal developer, the idea we have is, so we have a Java application. So we have a backend server. We have a front-end interface. We need to integrate them. And then we deploy those on a Cuban instance or say an OpenSAFE instance. So we have a CLI tool for that. We have editor where we code our Java application. And then we have a different console for OpenSAFE to deploy others. So basically a three-step scenario, more than three-step scenario. So in this talk, what we are going to say is that we are going to create an extension pack where basically you will have all those extensions needed to create your Java applications and deploy that code directly into OpenSAFE using your VS Code editor. So you did not switch different terminals, different consoles to perform that operation. Everything can be done directly on the VS Code instance. So let's move forward and see how things are. So the first question we have is why do we need an extension pack or say what is an extension pack? So in VS Code editor we have a concept known as extensions. Basically those are the plugins which are integrated into your editor where you can perform different operations. For this, say, I need to create a game based out of where the scenario is more or less related to Java. And it can be different. So it can be a Node.js also. It can be a Go application. It can be Python or anything. Right now, if I am a developer, I need to know how Java language works, what are the syntax, how I need to debug it, how Maven works. All those nuances are needed to be known. And for every scenario there are different plugins. So in this extension pack what we have done at Red Hat is we have created one extension pack which will have an extension which does connection to OpenShift, an extension which does your Maven plugin, an extension which creates a Docker hub. So all those small extensions are packed into one and can directly be installed into VS Code. So as a developer, say, you have a specific use case where you need just those set of extensions. So you did not install them manually every time. You just install that extension pack and that extension pack will perform all those operations for you. So as I mentioned, what is the use case to have an extension pack? So if you have, say, you have an extension pack where all these steps are done. So you can pass that same extension pack to your different team. That can be a dev team. That can be a QA team or that can be an SRE team, whatever. And they can use that same extension pack to perform all those operations. Starting from writing a Java code, debugging a Java code, deploying the Java code, pushing that code to OpenShift and even maintaining the logs. So, say, if you have a Jenkins build running and you need to see the logs, you need to, again, go to Jenkins, see which logs are there, what is failing, does your build pass or your file is broken or not. So everything can be directly seen into that editor. You need not switch between different terminals. And that basically enhances the performance of a developer walking on a given scenario. The second part is, if you have an extension pack just related to, say, Java, you walk on that extension pack, you perform all those operations, and you have a separate extension pack which does the same things, but not for Java. That does for Python or, say, does for Node. So for specific use cases, you have specific extension packs. And that can be directly installed to your editor VS code from the marketplace. So for this talk, I will be mostly focusing on that how you can perform an end-to-end experience for a Java app which can be deployed to an OpenShift cluster directly using this extension pack. So, say, you are a new developer or say you are an experienced developer, whatever the case may be, you have a VS code editor into it, you install it. It does not have any extension right now. You go to the marketplace, you search for OpenShift Java extension pack, and that will prompt you an extension. You just install it and reload it. So right now that is not yet published on the marketplace, but I think maybe next week we are going to publish it on the marketplace. But if you go into the Visual Studio marketplace and search for Red Hat, you will have extensions known as OpenShift Connector, which basically does all this deployment for your Java code directly to the OpenShift cluster, whichever OpenShift cluster is running. That OpenShift cluster can be your local instance, which can be run from, say, MiniShift, that's an open source, or it can be an on-premise OpenShift instance. You just write your code in VS code, you create a tar file, you create a component on that cluster which is running, and just do a push, everything from editor, and that will be deployed to your instance. Now, say, once you have written this Java code, now you need to debug the Java code. So now if you have to debug it, you need some other plugin for that. But for this extension pack, you need not worry about that debugging. As soon as you have this installed, that whatever code is there that will automatically prompt you for the debugger. So you can even debug your Java code step-by-step and see what is breaking and what things are, why it is not deployed on that instance correctly. So the first thing which we have with that extension pack is known as server connector. This server connector basically gives you advantages to, say, install and run different dependencies. Like you want to run a wildfire server or you need to run an EAP server. So you need to download it first, then you need to install it, and then you need to use it. With this server connector extension installed in your VS code, you can directly use any wildfire server, say wildfire 14 or 15. Just start it and the server will automatically be started. Now your Java code is already there. Once your Java code is already there, click on that server connector and say deploy. So whatever Java code is there, that will be deployed onto that server. Now once that code is deployed onto that server, you need to run it, say, on a cluster, right? And that cluster can be anything. Whatever configuration is present in your kube config, say you have a kube config file which basically has different clusters which are running, you can select whatever cluster you want to deploy that file and that whatever build which was there on that server will be directly deployed to your OpenShift instance. So that is the advantage of having a server connector. So this extension is already there in the marketplace. If you go and search by redhat, server connector, you will find it. The second one in the extension pack is the Docker Explorer. So basically we have this extension to manage your Docker containers, your images, whatever Docker files which are there from your Docker hub will always be listed down in this Explorer and you can figure it out. Okay, this is the Docker container which I need to use or this is the image which I need to use to create that component. And the third one is project initializer. So this is basically, if you are using, say, a new Java project, right? You need not know, okay, which source image I need to use or which image is right for that application. So project initializer basically gives you a set of quick start projects which you can directly select, start it, initialize it and all those configurations with all those files, with the POM XML files, whatever Maven configurations are there will be loaded in your local workspace. And you can use that local workspace to deploy onto that server which was started using the server connector. And once that is deployed into that server connector, just deploy that code into the, say, OpenShift instance. So everything is connected more or less whatever you need to do an end-to-end lifecycle of that Java application which you want to create. So now these are, these were some of the extensions which are needed to start your deployment. These are some of the extensions which are needed to configure your Java application. The first one is language support for Java. Basically this gives you auto-completion, whatever language support we need for Java, whatever the files, whatever the functions which are needed for your Java classes. Those things are given by language support. And I think this extension currently has approximately 1.2 million downloads currently in Visual Studio Marketplace. So this is one of the most usable extensions in VS Code. And this is supported by Red Hat. The second one is debugger for Java. So whatever code you have in your Java application, definitely you need to debug it and you need to see what are the step-by-step executions which are done. So this extension will help you to debug your code. And the third one is Maven Project Explorer. Basically whatever types you have in your Java project, whatever PowerMaximal file or whatever Maven file you have, you need to check that, okay, is this PowerMaximal file correct? Can this be built to create a new tar file? Can this be deployed onto that Wildfly server I'm running or EAP server I'm running? So this Maven Explorer will give you all those scenarios and hints and auto-completions to configure your application and make it correct. So if you see the overall flow from start to end for that Java application can be done with all these extensions which are there for you. So as a new developer or even as a senior developer, this saves you time to not worry about what are the smaller nuances needed for that. You have everything set up in that VS Code. It will prompt you for all those changes. It will prompt you for all those builds. It will even start your servers which are running. You need not go to any command line to start your Wildfly server or download that Wildfly and then start it. So everything is there for you. You just need to work on your code, create that, build it, deploy it and that's how the end-to-end lifecycle will work. So the basic idea of having this collection of extension pack is as a developer we want to write more code so that it is not giving us nuances that do I need to learn OpenShift? Do I need to know how KubeConfig works? Or do I need to find out where is my Wildfly server running? So everything which is running on your VS Code editor directly you know that, okay, these are my logs, these are my server which are running, these are my different configurations which are there and these are how things can be integrated. So this gives you one end goal that, okay, as a developer I know what my situations are for a given extension pack. Now in this OpenShift extension pack, right now I'm covering for Java but in the future we are also going to support whatever languages you know. As a developer, if you are comfortable with Node, this works with OpenShift extension pack. If you're comfortable with Go, this works the same way. The example with Java was that the adaptation of Java is more with developers so we started with OpenShift extension pack for Java but going ahead every language will be supported and on-premises and even on the local shift OpenShift is supported. So for example if you need to just test and deploy for just one Jenkins build, you can just run your local instance, you can just start your Minishift instance directly from the server connector that gives you the options to download Minishift, start the Minishift version and just start your OpenShift cluster. Now as your OpenShift cluster is running, you create a Java component. Your Java code is there in the local workspace. Just create a component from a local workspace. A new component will be created and once that new component is created, you just do a push. So that push will directly go to the cluster which is running and that will be deployed. Now you need to make some changes to the code. As soon as you make some changes to the code, as we have the Maven Explorer there, a new build is generated and the new build generates, creates a new tar file and that new tar file will again be deployed to that OpenShift cluster which is there. So you have that end-to-end experience of working for a Java application throughout seamlessly. Now if you need to see what are the logs which are running, I need to check are the logs correct, are the deployment correct. So everything can be seen directly on the terminal and in the VS code editor terminal, you need not go to a different console or different terminal and you can see what logs are there, what Maven configuration is there, what build is running from Maven. Is there any incorrect data in my .pom.xml file? How the scenario is? So everything in that interface is using this OpenShift extension pack. Now I have been asked this question many a times is that if I have this OpenShift, can I just work with one extension and not use this extension pack? You can definitely work ahead with one extension, just have an OpenShift extension to connect and just deploy into that OpenShift instance. But the use of this extension pack is it provides you many other advantages like a debugger is there, explorer is there, even running different servers like running wildfire servers, EAP servers, running those servers directly on the VS code editor, this extension pack will help you in doing all those scenarios at one point and just enabling you that end-to-end lifecycle of a developer very easier. So I think this is what I had for this talk. So you have any questions at how this works or how the scenarios are, please feel free to ask. I think I have some time. So if you need to see that how the project is going, we have a GitHub slash redhat-developer. If you go into that, you can find all those projects which are listed, how things are working, how things are. And that's it. And we have the server connector, the project analyzer and the OpenShift connector already there in the VS code marketplace and the language support for Java. As I mentioned, we have approximately 1.2 million downloads for language support for Java. The OpenShift connector currently has been launched two months back and it has approximately 2,000 downloads. And the project analyzer was launched last week. So we are continuously working on this to upgrade the developer experience and more and more extension packs will be coming in the future for the developers to work on different languages. Right now we have for Java, but in the future we'll be supporting all the other, say, primary languages with developer work on. So no questions? Okay, thank you.