Iterating on component development with Talend Studio

Integrate components you developed using Talend Component Kit to Talend Studio in a few steps. Also learn how to enable the developer and debugging modes to iterate on your component development.

Job run

Version compatibility

The version of Talend Component Kit you need to use to develop new components depends on the version of Talend Studio in which components will be integrated.

Refer to this document to learn about compatibility between Talend Component Kit and the different versions of Talend applications.

Installing the components

Learn how to build and deploy components to Talend Studio using Maven or Gradle Talend Component Kit plugins.

This can be done using the deploy-in-studio goal from your development environment.

If you are unfamiliar with component development, you can also follow this example to go through the entire process, from creating a project to using your new component in Talend Studio.

Configuring the component server

The Studio integration relies on the Component Server, that the Studio uses to gather data about components created using Talend Component Kit.

You can change the default configuration of component server by modifying the $STUDIO_HOME/configuration/config.ini file.

The following parameters are available:

Name Description Default


Enables the developer mode when set to dev



Specifies the timeout (in milliseconds) before calling listeners in components Text fields



If set to true, the plugin is not enabled. It is useful if you don’t have any component developed with the framework.


Component server additional options


Maven repository that the server uses to resolve components

Defaults to the global Studio configuration

A list of comma-separated GAV (groupId:artifactId:version) of components to register


A properties file with values matching component GAV (groupId:artifactId:version) registered at startup. Only use slashes (even on windows) in the path.


Sets the port to use for the server


Active, if set to true, Beam support (Experimental). It requires Beam SDK Java core dependencies to be available.



Adds a console handler to JUL to see logs in the console. This can be helpful in development because the formatting is clearer than the OSGi one in workspace/.metadata/.log.

It uses the java.util.logging.SimpleFormatter.format property to define its format. By default, it is %1$tb %1$td, %1$tY %1$tl:%1$tM:%1$tS %1$Tp %2$s%n%4$s: %5$s%6$s%n, but for development purposes [%4$s] %5$s%6$s%n is simpler and more readable.


Here is an example of a common developer configuration/config.ini file:

# use local .m2 instead of embedded studio one
maven.repository = global

# during development, see developer model part
component.environment = dev

# log into the console the component interactions - optional
component.server.jul.forceConsole = true
java.util.logging.SimpleFormatter.format = [%4$s] %5$s%6$s%n

Enabling the developer mode

The developer mode is especially useful to iterate on your component development and to avoid closing and restarting Talend Studio every time you make a change to a component. It adds a Talend Component Kit button in the main toolbar:

Studio Reload Button

When clicking this button, all components developed with the Talend Component Kit framework are reloaded. The cache is invalidated and the components refreshed.

You still need to add and remove the components to see the changes.

To enable it, simply set the component.environment parameter to dev in the config.ini configuration file of the component server.

Debugging your custom component in Talend Studio

Several methods allow you to debug custom components created with Talend Component Kit in Talend Studio.

Debugging the runtime or the Guess schema option of a component

  1. From your development tool, create a new Remote configuration, and copy the Command line arguments for running remote JVM field. For example, -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005, where:

    • the suspend parameter of the -agentlib argument specifies whether you want to suspend the debugged JVM until the debugger attaches to it. Possible values are n (no, default value) or y (yes).

    • the address parameter of the -agentlib argument is the port used for the remote configuration. Make sure this port is available.

      IntelliJ remote configuration
  2. Open Talend Studio.

  3. Create a new Job that uses the component you want to debug or open an existing one that already uses it.

  4. Go to the Run tab of the Job and select Use specific JVM arguments.

  5. Click New to add an argument.

  6. In the popup window, paste the arguments copied from the IDE.

    IntelliJ remote configuration
  7. Enter the corresponding debug mode:

    • To debug the runtime, run the Job and access the remote host configured in the IDE.

    • To debug the Guess schema option, click the Guess schema action button of the component and access the remote host configured in the IDE.

Debugging UI actions and validations

  1. From your development tool, create a new Remote configuration, and copy the Command line arguments for running remote JVM field. For example, -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005, where:

    • suspend defines whether you need to access the defined configuration to run the remote JVM. Possible values are n (no, default value) or y (yes).

    • address is the port used for the remote configuration. Make sure this port is available.

      IntelliJ remote configuration
  2. Access the installation directory of your Talend Sutdio.

  3. Open the .ini file corresponding to your Operating System. For example, TOS_DI-win-x86_64.ini.

  4. Paste the arguments copied from the IDE in a new line of the file.

    IntelliJ remote configuration
  5. Go to Talend Studio to use the component, and access the host host configured in the IDE.

Random port when running concurrent studio instances

If you run multiple Studio instances automatically in parallel, you can run into some issues with the random port computation. For example on a CI platform. For that purpose, you can create the $HOME/.talend/locks/ file.

Then, when a server starts, it acquires a lock on that file and prevents another server to get a port until it is started. It ensures that you can’t have two concurrent processes getting the same port allocated.

However, it is highly unlikely to happen on a desktop. In that case, forcing a different value through in your config.ini file is a better solution for local installations.

Scroll to top