What's New in Intershop Studio 4.3.4


1 Introduction

The new Intershop Studio comes with meaningful tooling for tasks that occur in the context of the new continuous integration processes.

2 Eclipse Update

2.1 Intershop Studio is based on Eclipse 4.3.2 (Kepler SR2)

Intershop Studio is now based on Eclipse 4.3.2 (Kepler SR2).

This is a maintenance release that mainly focuses on bugfixes. For a list of fixed bugs see: Eclipse Project's Bug List

3 Continuous Integration Support

3.1 Groovy Tooling for Intershop Studio

3.1.1 Groovy Support

Intershop Suite implicitly uses Groovy since it supports gradle builds. In order to support editing build files Groovy tooling has been added.

3.2 Intershop Studio Main Configuration Uses gradle.properties File

3.2.1 Main Intershop Preferences

Intershop Studio now uses the data of the gradle.properties file as configuration for a server ≥ 7.5.

3.3 Import Component Set (Gradle) Wizard

3.3.1 Import Component Set

Intershop Studio now provides an import wizard to import an entire component set or valid sub sets of it.

This wizard configures the project (e.g., its class path, project natures etc) if necessary.

This wizard has to be used in favor to the import wizard Gradle|Gradle Projects.

You might like the option Add to workingset ....

Especially, when working with multiple component sets.

3.4 Content Assist for build.gradle Available

3.4.1 Intershop Specific Content Assist in Groovy Editor

The Groovy Editor used when editing a build.gradle file now provide particular content assist related to Intershop Suite or cartridge related concepts.

3.4.1.1 Apply Cartridge Plugins

Most cartridge builds need to apply particular plugins. Content assist offers proposals for this:

3.4.1.2 Edit intershop Extension Block

Cartridge build files allow to declare special properties in a intershop closure:

3.4.2 Edit dependencies Block

Inside the dependencies block cartridges, components or other required artifacts need to be declared.
Proposals are available that support this task:

4 Clarity When Working with Pipelines

4.1 Pipeline Editor Palette Enhancements

4.1.1 Customize the Pipeline Editor Palette

You  can now customize the items shown in the palette of the Visual Pipeline Editor. Use the Customize... action from the context menu of the editors palette.

4.1.2 Generic Pipeline Nodes Are Displayed in Pipeline Editor Palette

Generic pipeline nodes that express, e.g., a Start node or Interaction node are now shown in the palette of the editor.

4.1.3 Pipelet Palette Item Contains Pipelets and Generic Pipeline Nodes

The palette now contains an entry Pipelet... which provides a dialog to select a pipelet or a generic pipeline node.

The children of the Pipelet... entry can be expanded (and pinned if necessary).
Dependent on the configuration of the palette the children are either:

  1. All pipelets and generic pipeline nodes that are not marked as other node type
  2. The Top 50 pipelets/pipeline nodes.
    This Top 50 statistics is based on number of usages in pipelines with the same type as the edited one.
  3. None.

The children mode can be configured using the palette customization dialog.

The following image shows the children in Top 50 mode.

Note

The top 10 pipelets are listed according to the usage count, the other are sorted by name.

 

4.1.4 Refresh Palette

The palette can be refreshed using the refresh button located in its tool bar.

All required files for the example below are available in the example.zip.

4.2 Customizable Pipelet and Pipeline Node Appearance

4.2.1 Pipelet and Pipeline Node Appearance

Most aspects of appearance of pipelets and generic pipeline nodes can now be fully customized using particular annotations. This includes labels, but also the graphical image of a node.

For more detailed information on how to use generic pipeline nodes, see the Concept - Pipeline Nodes.

Note

Images are supported only with theme Node Icons.

Let us start with an example that features a nonsense but kind pipeline node called EmotionalNode!

This is the generic pipeline node's source code.

package com.intershop.test.pipelinenode;

import com.intershop.beehive.pipeline.capi.annotation.Attribute;
import com.intershop.beehive.pipeline.capi.annotation.PipelineNode;
import com.intershop.beehive.pipeline.capi.annotation.PipelineNodeInput;
import com.intershop.beehive.pipeline.capi.annotation.PipelineNodeOutput;
import com.intershop.beehive.pipeline.capi.annotation.PipelineNodeParameter;
/**
 * A pipelet that shows emotion dependent on its configuration.
 */
@PipelineNode
public class EmotionalNode {
    private enum Mood {
        happy, angry
    }
    /**
     * Enter the mood!
     */
    @PipelineNodeParameter
    private Mood mood;
    @PipelineNodeOutput
    private Out happyOut;
    @PipelineNodeOutput
    private Out angryOut;
    @PipelineNodeInput()
    public Object start(In in) {
        
        if (mood == Mood.angry)
            return angryOut;
        
        return happyOut;
    }
    interface In {
    }
    interface Out {
    }
}

As you might guess, this node features one input connector and two output connectors. Depending on the value of the configuration mood it will choose either the output connector happy or angry.

And this is how it looks:

Using the Node Icons theme (and we switch to it now, because it supports more customization options), this is how it looks:

Not really impressive. Now we decide our node is actually semantically a decision node and should be presented as such. We do that by adding an @Attribute annotation:

/**
 * A pipelet that shows emotion dependent on its configuration.
 */
@PipelineNode(attributes = {
         @Attribute(name = "NodeType", value = "Decision")
})

Now the node looks as follows:

Well, now it looks like a decision node. It also appears in the palette (click refresh in its toolbar, if it is not there), but there it looks rather ugly. Therefore we give it a display name:

/**
 * A pipelet that shows emotion dependent on its configuration.
 */
@PipelineNode(attributes = {
         @Attribute(name = "NodeType", value = "Decision"),
         @Attribute(name = "DisplayName", value = "Emotional Decision Node")
})

Better. But the node label is still rather boring. We fix that using some label annotions:

/**
 * A pipelet that shows emotion dependent on its configuration.
 */
@PipelineNode(attributes = {
         @Attribute(name = "NodeType", value = "Decision"),
         @Attribute(name = "DisplayName", value = "Emotional Decision Node"),
         @Attribute(name = "Label", value = "${Configuration[\"mood\"].value:Pipelet.Configuration[\"mood\"].description}"),
         @Attribute(name = "MinorLabel", value = "*++++*"),
         @Attribute(name = "CartridgeLabel", value = "[Cartridge: <b>${Pipelet.Cartridge.label}</b>]"),
})

As you see, a simple Expression Language might be used to compute the labels (there exist three labels: The main label, a minor label, and the cartridge label). In this example the value of the configuration (of the node) mood is used as main label. If this would evaluate to null, the description of its defining property (of the node) will be used. Now the pipeline looks as follows:

We are just satisfied here, but the Pipelet node still does not show emotion. In order to do that, we draw some images and store them in the cartridges content folder:

The images have size 50*50:

Now we need to specify to use them as image and decoration:

/**
 * A pipelet that shows emotion dependent on its configuration.
 */
@PipelineNode(attributes = {
         @Attribute(name = "NodeType", value = "Decision"),
         @Attribute(name = "DisplayName", value = "Emotional Decision Node"),
         @Attribute(name = "Image", value = "pipelet_icons/pipelet_yellow.svg"),
         @Attribute(name = "DecorationImages", value = "${equals(Configuration[\"mood\"].value,\"angry\")?\"pipelet_icons/angry.svg\":equals(Configuration[\"mood\"].value,\"happy\")?\"pipelet_icons/happy.svg\":\"pipelet_icons/indifferent.svg\"}")
})

As you see, you can use a main image as well as decoration images. A yellow node with an indifferen mood is shown:

In order to make it happy, you need to set the configuration. But because this is the one and only and actually most important property here, we declare it as such:

/**
 * A pipelet that shows emotion dependent on its configuration.
 */
@PipelineNode(attributes = {
         @Attribute(name = "NodeType", value = "Decision"),
         @Attribute(name = "DisplayName", value = "Emotional Decision Node"),
         @Attribute(name = "Image", value = "pipelet_icons/pipelet_yellow.svg"),
         @Attribute(name = "DecorationImages", value = "${equals(Configuration[\"mood\"].value,\"angry\")?\"pipelet_icons/angry.svg\":equals(Configuration[\"mood\"].value,\"happy\")?\"pipelet_icons/happy.svg\":\"pipelet_icons/indifferent.svg\"}"),
		 @Attribute(name = "DirectEditProperty", value = "mood"),

})

No you can directly edit this configuration in the editor (Select and press F2):

And eventually it is happy!

And finally a pipeline with several usages of this node:

4.2.2 Pipelet EL

As outlined above, values to be used for labels or images can be expressed using expressions. This is most useful in situations where the most important information is expressed in configuration values or parameter bindings. A label of an interaction node should include the template being rendered, a decision node should have a label that includes the expression.

These expressions are similar to Java EL () but do not fully support all EL features. Following rules apply:

  • Expressions are enclosed in ${EXPRESSION}
  • Each expression gets the actual Pipelet Node as root object
  • Bean properties are accessed using the name.
  • Array or collection entries can be expressed using [INDEX|"LABEL"]. Example ${Configuration["mode"].value.label or ${Configuration[0].value.label. The label of the value of the configuration with name "mode". Or the label of the value of the first configuration value.
  • Functions are called using parentheses
  • Conditions are expressed using: ${BooleanExpression?TRUE_CASE:FALSE_CASE}
  • EL Extension: Conditions to test for empty or null properties might be ommitted. Example:  ${Configuration["mode"]:"Please enter the mode!"}: If configuration "mode" is not set, the constant "Please enter the mode!" is used.

4.2.3 Supported Attributes

NameDescriptionValue
DisplayNameThis is used whenever a node is displayed in views or in the palette. If omitted the name of the node is used.
This attribute does not support expressions.
String only
LabelThe main label of the node in the editor.Strings or expressions
NodeTypeThe display type of a node. This property will be considered to calculate the icon of a node in views and editors.
If, e.g., your node is called IsProductAvailable it would be wise to use the node type Decision.
  • Loop[Node]
  • Join[Node]
  • Decision[Node]
  • Pipelet[Node]
  • Start[Node]
  • Call[Node]
  • Jump[Node]
  • Interaction[Node]
  • End[Node]
  • Stop[Node]
PipelineTypeUse this attribute if a node should only be used in pipelines that have a particular type.String only. E.g., process, view.
MinorLabelA minor label used within the Visual Pipeline Editor.Strings or expressions
CartridgeLabelThe label of the cartridge that hosts the node.Strings or expressions

DirectEditProperty

The name of a configuration that should be used as direct edit property. If omitted the Pipelet selector will be used.

Strings or expressions

ImageThe value of a graphic relative to the cartridge content folder. Using SVG with size x = 50, y = 50 is recommended.
This property is supported only with the Node Icon theme.
 An image reference. Expressions are supported.
DecorationImagesThe value of a images relative to the cartridge content folder. These images will be rendered centered over the main image.
This property is supported in Node Icon theme only.
Comma separated list of image references. Expressions are supported.

4.2.4 Usage of Attributes

Attribute annotations can be used in descriptions of normal pipelets and generic pipeline nodes. You just used the attribute name as annotation. E.g.:

@NodeType Decision

@DisplayName A Fancy Pipelet

Additionally, the annotations of generic pipeline nodes support the @Attribute(name="",value="") annotation. The usage of the @Attribute annotation is the preferred solution, see the example above.

4.3 Pipeline Debugger - Current Node Highlighted

4.3.1 Node Highlighting

The current node as well as all call nodes that are part of the current pipeline debug stack frame are now highlighted by an arrow icon.

4.3.2 Parameters and Values Tool Tip

The parameters of a node (e.g., of a start node, or the input parameters of a pipelet) as well as their values can be shown in the tool tip. All other variables are shown too.

5 SonarQube IDE Removed

5.1 SonarQube IDE Removed from Intershop Studio Distribution

Due to an annoying bug that constrained the developers (and the fact, that only a few people are actually using this tooling) the SonarQube IDE has been removed completely from the Intershop Studio distribution.

However, developers who need this tooling may still obtain it from the Intershop Studio update site or http://dist.sonar-ide.codehaus.org/eclipse/.

Note

If you do so, please keep in mind that the mentioned bug will not be fixed before release 3.4 of the SonarQube IDE.

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets