Adding an artifact

From Skyway Wiki

Jump to: navigation, search
  1. In the plug-in manifest editor, add an extension for the org.skyway.core.coreArtifactSet extension point.
  2. Select the (set) child node (this was automatically added for you) and enter the id of the artifact set you want to contribute to. The artifact set for the Skyway web deployment facet is org.skyway.integration.java.spring.artifactset.
  3. Right click this (set) node and choose New/modelType.
  4. Enter the model class that should trigger creation of your new artifact. The most common core Skyway model classes are:
    1. org.skyway.core.model.data.DataType
    2. org.skyway.core.model.data.DataStore
    3. org.skyway.core.model.data.NamedQuery
    4. org.skyway.core.model.action.Action
    5. org.skyway.core.model.service.Operation
    6. org.skyway.core.model.service.Service
    7. org.skyway.core.model.service.Exception
    8. org.skyway.core.model.Project
    9. org.skyway.core.model.web.WebController
    10. org.skyway.core.model.web.Conversation
    11. org.skyway.core.model.Folder
  5. Right click the the (modelType) node and choose New/coreArtifactDefinition.
  6. Configure your artifact definition:
    1. template: Select your JET template. The JET templates are typically located in the /templates folder and have a .jet file extension.
    2. definition: Specify the artifact definition class.
      • For java classes, use org.skyway.integration.java.generation.JavaArtifactDefinition
      • For XML configuration files, use org.skyway.integration.java.generation.configuration.XMLArtifactDefinition
      • For plain text files, use org.skyway.core.generation.jet.CoreArtifactDefinition
      • If you need specialized functionality, you can write your own artifact definition. This would give you very low level control over the generation process for your artifact; for example, you could specify a custom beautifier to run. Normally, it's sufficient to sub-class org.skyway.integration.java.generation.JavaArtifactDefinition (for Java source files) or org.skyway.core.generation.jet.CoreArtifactDefinition (for configuration files). If you search for sub-classes of these two types, there are plenty of examples.
        • org.skyway.integration.java.generation.configuration.WebFolderArtifactDefinition is a good example of an artifact that's only generated for very specific instances of its associated core model object. This is done using org.skyway.core.generation.IArtifactDefinition#isInterestedIn.
    3. alias: Give your artifact a unique name. Some Skyway JET tags have an alias attribute, which lets them lookup information in the artifact definition. For example, the sw:javaType tag does this to lookup name that you want to give your generated class.
    4. invalidator: Generally, you can leave this blank. If you need to regenerate other artifacts whenever your file is generated, you could do this by writing your own sub-class of org.skyway.core.generation.ArtifactInvalidator.
    5. invalidator:
    6. keepExistingFile: If true, your artifact will never be overwritten (updated) if it exists. This is seldom used, but is helpful if you anticipate making changes to your generated file and you know that it will never need updating if your models change.
    7. artifactCategoryId: Specify one of: domain, service, dao or web.
    8. artifactTypeId: Specify one of: java, resource, java.test, resource.test, web.application, config or assembly.
    9. path: Specify where you would like your artifact generated. Generally you can use ${category}/${type}/${namespace} for java files or ${category}/${type} for config files. But you can customize this; for example, ${category}/${type}/WEB-INF puts the artifact in the WEB-INF folder.
    10. filename: Specify the filename. If this is a java class, the filename is always based on the class name (what we call the derivedName), so you should use ${derivedName}.java.
    11. namespace: This should be the java package. Leave this blank for non-java files. And generally, you can use ${user} for java classes, which will use whatever the user enters into the project code generation tab.
    12. derivedName: Leave this blank for non-java files. And for java files, this should be the class name, which is usually derived from the name of your model. ${coreName} is the default value.
Personal tools