Rational Developer for Power Systems Software
V7.6

com.ibm.etools.iseries.remotebuild
Interface IBuildStyle

All Known Implementing Classes:
BuildStyle, CommandBuildStyle, ProgramBuildStyle

public interface IBuildStyle

A build style provides access to the configurations necessary to implement a build system on a remote iSeries system.

Build styles and build style configurations go hand in hand. There is one instance of a particular build style per workspace. These act as factories for build style configurations which exist as a workspace default or as a configuration for a particular project.

If a build style has configurations that may be modified by a user it answers true to isConfigurable().

The build style, its configurations, and the actions defined in its plugin have access to the utility classes defined in this package.

The lifecycle of a build style is:

  1. construction -- the default constructor is called when the build style is needed.
  2. setId -- called just after construction.
  3. setDeclaringPluginBundle -- called just after construction.

This interface must not be directly implemented by clients. Clients must sublcass the implementation found in com.ibm.etools.iseries.remotebuild.BuildStyle.


Field Summary
static String Copyright
           
 
Method Summary
 IBuildStyleConfiguration getDefaultConfiguration()
          Returns a new default configuration for this style.
 String getDescription()
          Returns a short description of this build style.
 String getId()
          Returns a unique identifier within the workbench for this build style.
 String getVendorString()
          Returns a description of the vendor that supplied this build style.
 boolean isConfigurable()
          Returns true if the build style is configurable by the user.
 void setDeclaringPluginBundle(Bundle bundle)
          Remembers the plugin bundle that defined this build style.
 void setId(String id)
          Remembers the unique identifier of this build style.
 

Field Detail

Copyright

static final String Copyright
See Also:
Constant Field Values
Method Detail

getDescription

String getDescription()
Returns a short description of this build style. This is presented to the user during the selection of a build style.


setDeclaringPluginBundle

void setDeclaringPluginBundle(Bundle bundle)
Remembers the plugin bundle that defined this build style.

Called as part of the initialization of this build style.


getVendorString

String getVendorString()
Returns a description of the vendor that supplied this build style.


setId

void setId(String id)
Remembers the unique identifier of this build style.

Called after construction to provide this instance with the id of its class. The id is supplied from the plugin.xml file.


getId

String getId()
Returns a unique identifier within the workbench for this build style. Must return the value provided by setId().


isConfigurable

boolean isConfigurable()
Returns true if the build style is configurable by the user. All build styles have configurations but not all may be configurable. A configurable style will probably present a dialog to the user that asks for parameters on a per project basis. These parameters will be stored in a configuration for that project.

Styles that are configurable may be presented in the user interface differently that styles that are not configurable.

Styles that are configurable are expected to have configurations that respond in a non-trivial way to the IBuildStyleConfiguration.configure().

See Also:
IBuildStyleConfiguration

getDefaultConfiguration

IBuildStyleConfiguration getDefaultConfiguration()
Returns a new default configuration for this style.


Rational Developer for Power Systems Software
V7.6

Copyright © 2011 IBM Corp. All Rights Reserved.

Note: This documentation is for part of an interim API that is still under development and expected to change significantly before reaching stability. It is being made available at this early stage to solicit feedback from pioneering adopters on the understanding that any code that uses this API will almost certainly be broken (repeatedly) as the API evolves.