Import Your Project to Codenvy
Configuring your project just right in Codenvy is 90% of success, in terms of having a positive user experience from take one. Having imported a project from version control or as a zip, a project configuration wizard will show up. Stop for a while and make well thought choices there. You will need to make two choices: project type and runtime environment. Let’s move on to these steps.
Step 1: Dealing With Project Type
Having imported source code to your Codenvy workspace, you need to tell the system how it should be treated, i.e. choose a project type. There are many implications and consequences of this choice (don’t worry, you can re-configure the project later). Project types are provided by plugins, like PHP or Python plugin. Project type may or may not associate project with a particular build system, if applicable, change the UI (introduce additional panels), add project-specific functionality (like Angular generators), disable existing menus or toolbar buttons.
If you have a Java project, you should pick the right build system. Currently, Maven and Ant are available. When choosing any of these project types, you set up the following project build and run cycle:
>> Project is built and packaged on a separate builder node >> artifacts are injected into a Docker image on a runner node >> output is piped into builder/runner console in a workspace
Blank Project Type
It is possible that none of the available project type suits your project. If this is the case, choose Blank project type which has no associated builders and special IDE featured that are provided by other project types. You will be able to set the right runtime and launch your project in Docker.
However, if this is a Maven or Ant project, choosing Blank project type will prevent you from using builders, since Builder related commands will be disabled. Otherwise, you can freely use Blank project type for your projects.
Step 2: Choosing Runtime That Suits Your Project
Having configured project type (you may go through additional project configuration, for example, changing GroupID or packaging in Maven’s pom.xml), it’s time to choose runtime environment for your project. You will see categories with environments and their descriptions:
You may want to check runtime recipe for the environment you are about to choose. Visit our Dockerfiles project on GitHub. How to navigate this project?
You will find folders with names identical to environment categories on a wizard configuration page. So, if you want to choose java > web > tomcat7 environment, its recipe is available at https://github.com/codenvy/dockerfiles/blob/master/java/web/tomcat7/Dockerfile
It’s a Dockerfile that’s used to cook this particular environment. If you are interested in underlying base images, you may want to browse /base directory – https://github.com/codenvy/dockerfiles/tree/master/base
Tips and shortcuts:
- if you have a Java web project, head to java > web category and pick an application server
- if your project is packaged as JAR, choose java > standalone > simple – cli. This environment injects a jar into a Docker image and executes it (java – jar application.jar)
- if you have a desktop Java project, java > standalone > simple – gui. This environment injects a jar into a Docker image and executes it, while a client connects to a VNC server, which makes it possible for a user to connect to this environment.
- if your Java project creates a db in the runtime, java > standalone > db should be your destination
- if you have a Python GAE project, your environment should be python > web > python27_gae199
This way, you can analyze the particular environment to make sure it fits your project. Odds are that the environment itself is OK (it has all the tools/software installed), but some Docker instructions are missing, or vice versa, there are unnecessary instructions that cause image build failure. If you have run into such a situation you will need to provide your own Docker recipe. See: Custom Dockerfile.
If resources permit, you can set recommended RAM for a project. This property will be tied up to Run button, i.e. each time you hit Run, the app will be allocated the exact amount of RAM specified in configuration wizard.
To sum it up, let’s go through all the steps once again:
Reconfigure the Project
Made a wrong choice? Or failed to make any choice at all? You can re-configure your project anytime at File > Project Configuration.
You will see the same project configuration wizard that you have seen the first time you imported your project. Steps are identical to steps you have previously taken.
If you have created your own custom environment, you will find it in the list of available environments under project category. Project means that the environment is provided by the project, not system like all the rest.
Basics: Correcting Config Mistakes
Builder Not Set
Runner Not Set
Name of runner environment is not specified, be sure corresponded property of project is set
JSON Configuration File
Each time you re-configure the project, all the configuration settings are stored in a special configuration JSON file. You can download this file at File > Export Config. Let’s take a look at a typical JSON configuration file:
In the source, you can see location of the project, type of version control system and commit ID. Then comes the project section with essential info on project name, privacy, default runner and builder. system:/java/web/tomcat7 means that system provided environment is used (pre-built env). If you create a new environment in your project, call it custom, add it as a default runtime environment and set recommended RAM – 2048, this is how the runners section will look like:
As you can see, system scope has been replaced with project, and there’s 2GB RAM allocation.
Any reconfiguration changes are saved into this file, which you can share with other people who will be able to recreate the same project in their workspaces.