Type Members

1.  case class ApexSummary(typeSummary: TypeSummary, diagnostics: Array[Diagnostic]) extends Product with Serializable

   Summary of an Apex class with diagnostic information

2.  case class BlockSummary(isStatic: Boolean, dependents: Array[DependentSummary]) extends Product with Serializable

   Summary of a initialiser block

3.  case class ConstructorSummary(idRange: Option[RangeLocation], modifiers: Array[String], parameters: Array[ParameterSummary], dependents: Array[DependentSummary]) extends Product with Serializable

   Summary of a type constructor

4.  sealed trait DependentSummary extends AnyRef

   Dependency information interface for detailing types of dependency

5.  case class FieldDependentSummary(typeId: TypeIdentifier, name: String) extends DependentSummary with Product with Serializable

   Dependency information for a field

   Dependency information for a field

   Annotations

   @key( "Field" )

6.  case class FieldSummary(idRange: Option[RangeLocation], name: String, modifiers: Array[String], typeName: TypeName, readAccess: String, writeAccess: String, dependents: Array[DependentSummary]) extends Product with Serializable

   Summary of a type field (or property)

7.  class IssueOptions extends AnyRef

   Options available when retrieving Org issues.

8.  case class MethodDependentSummary(typeId: TypeIdentifier, name: String, parameterTypes: Array[TypeName]) extends DependentSummary with Product with Serializable

   Dependency information for a method

   Dependency information for a method

   Annotations

   @key( "Method" )

9.  case class MethodSummary(idRange: Option[RangeLocation], name: String, modifiers: Array[String], typeName: TypeName, parameters: Array[ParameterSummary], dependents: Array[DependentSummary]) extends Product with Serializable

   Summary of a type method

10.  trait Org extends AnyRef

    A virtual Org used to present the analysis functionality in a familiar way.

    A virtual Org used to present the analysis functionality in a familiar way.

    All analysis works within the context of a virtual Org. You can manage multiple of these at the same time but most use cases just need one creating, see Org.newOrg(). The Org functions as a container of multiple Package objects and maintains a set of discovered issues from the analysis of the package metadata. All orgs have at least one 'unmanaged' package identifiable by having no namespace.

    In the simple case after creating an Org, you should add one or more packages detailing where package metadata is stored. Adding large packages can take considerable CPU and memory resources. Once the packages are loaded the metadata within them can be mutated using the Package methods. At any point you can list of current issues with the packages from getIssues.

    When metadata changes are requested (see Package.refresh they are queued for later processing either via calling Org.flush or via automatic flushing (the default). Flushing also updates a disk cache that helps significantly reduce initial loading times. The flushing model used by an Org is set on construction, see ServerOps.setAutoFlush to change to manual flushing.

    Orgs and Packages are not thread safe, serialise all calls to them.

11.  trait Package extends AnyRef

    A virtual Package constructed from metadata.

    A virtual Package constructed from metadata.

    Packages must be created in the context of a specific Org. Each Package manages a set of Types which are created from the metadata of the package. Once constructed you can use the package APIs to introspect dependency relationships between Types, obtain summary and view information about Types and replace or delete Types.

    A key concept to understand in this API is that a Type may be created from multiple metadata files, e.g. the System.Labels Type is always present but can be constructed from several labels files. The API methods expose Types via the TypeIdentifiers which you don't need to understand to use the API as long as you keep in mind the 1:M mapping between Types and Paths.

    The term dependency can be rather ambiguous, we use it here to mean a 'using' relationship. So if class A calls a method on class B, we say A has a dependency that is B. The reverse relationship is a 'dependency holder', so B has a dependency holder that is A. Transitives of dependencies or dependency holder relationships are not exposed by these APIs but can be easily obtained by recursive iteration.

    Summary and View information provide two different levels of looking at the structure of Types. In summary form only the most important details are provided but it is essentially free to access since it is the same format used in the disk cache. View information requires both more CPU and memory to use but can provide fuller details on the implementations of Apex classes.

    Packages only handle metadata that is important to Apex class analysis, other forms of metadata that might appear in the package directory are ignored.

12.  case class ParameterSummary(name: String, typeName: TypeName) extends Product with Serializable

    Summary of a constructor or method parameters

13.  case class TypeDependentSummary(typeId: TypeIdentifier, sourceHash: Int) extends DependentSummary with Product with Serializable

    Dependency information for a type

    Dependency information for a type

    Annotations

    @key( "Type" )

14.  case class TypeSummary(sourceHash: Int, idRange: Option[RangeLocation], name: String, typeName: TypeName, nature: String, modifiers: Array[String], superClass: Option[TypeName], interfaces: Array[TypeName], blocks: Array[BlockSummary], fields: Array[FieldSummary], constructors: Array[ConstructorSummary], methods: Array[MethodSummary], nestedTypes: Array[TypeSummary], dependents: Array[DependentSummary]) extends Product with Serializable

    Summary of a type

15.  trait ViewInfo extends AnyRef

    Detailed view of an ApexClass.

    Detailed view of an ApexClass.

    This is currently WIP and will be expanded later.