diff --git a/.github/workflows/preview.yml b/.github/workflows/preview.yml index 164782b..a7e5d44 100644 --- a/.github/workflows/preview.yml +++ b/.github/workflows/preview.yml @@ -14,10 +14,12 @@ defaults: env: doc_name: Transforms -on: +on: # trigger on commit of files in the doc subdirectory push: branches: - - master + - master + paths: + - 'doc/**' jobs: build: diff --git a/.gitignore b/.gitignore index 83ca368..9c3c490 100644 --- a/.gitignore +++ b/.gitignore @@ -2,7 +2,18 @@ # Project specific excludes # # -# Binaries +# ivoatex intermediate files +*.aux +*.bbl +*.blg +*.fdb_latexmk +*.fls +*.lof +*.log +*.out +*.pdf +*.toc +ivoatexmeta.tex # vo-dml products *.cmap @@ -10,6 +21,9 @@ *.gvd *.validation-report.txt +# vo-dml toolkit files +.gradle + # OS .DS_Store diff --git a/model/trans_1.0_uml2p4p1.xmi b/model/trans_1.0_uml2p4p1.xmi index 57072e8..28c6814 100644 --- a/model/trans_1.0_uml2p4p1.xmi +++ b/model/trans_1.0_uml2p4p1.xmi @@ -1,11 +1,11 @@ - - - - - + + + + + - + The transform model defines objects which can be used to construct expressions representing the relation between two coordinate systems. These may be used to transform coordinates and other objects defined in one coordinate system into corresponding objects in another coordinate system. There are two primary components to the model, the "Mapping", and the "TransformSet". The "Mapping" object defines how to transform a set of "input" scalar values into a corresponding set of "output" scalar values. The Mapping supports transforms in either direction via "operations" which we refer to as the forward and inverse operations. The forward operation transforms the mapping inputs into mapping outputs. The inverse operation transforms the mapping outputs into mapping inputs. @@ -15,12 +15,12 @@ The "TransformSet" object gives physical context to the "Mapping" by relating a Since a mapping expression can involve multiple steps between end points, we separate these features, such that the Mapping provides the path, and the TransformSet associates a Mapping with its source and target coordinate systems. - - + + - - - + + + The "Mapping" object defines how to transform a set of "input" scalar values into a corresponding set of "output" scalar values. The Mapping supports transforms in either direction via "operations" which we refer to here as the forward and inverse operations. The forward operation transforms the mapping inputs into mapping outputs. The inverse operation transforms the mapping outputs into mapping inputs. There is possibility here for confusion regarding the meaning of the words "input" and "output". A clear distinction should be drawn between the inputs and outputs of a mapping and those of an operation. The inputs and outputs of a mapping are the same as the inputs and outputs of the mapping's forward operation, but are the reverse of the inputs and outputs of the mapping's inverse operation. Thus, the inputs of the inverse operation are the outputs of the mapping, etc. @@ -39,8 +39,8 @@ In this model, we describe three flavors of mappings which allow specifications - - + + Boolean flag indicates that the Mapping content defines its inverse operation rather than its forward operation and so the Mapping should be inverted before being used. In other words, the forward operation of the Mapping should be implemented using the inverse operation implied by the Mapping's contents, and vice versa. For many operations, the inverse transformation can be directly derived from the forward transform. For instance, the inverse of a transform that simply adds a constant to each input is a transform of the same type, with a negated constant. However, there are potentially operations for which this cannot be done. For instance, the inverse of a transform that maps 3D Cartesian coordinates to spherical coordinates cannot be expressed by the same algorithm. This flag indicates that it should be used in its inverse sense. @@ -48,202 +48,202 @@ For many operations, the inverse transformation can be directly derived from the In addition, the invert flag allows a complex compound transformation to be be inverted simply by toggling its invert flag. Without such a flag each component would need to be re-written to represent its inverse (if possible), and the order of serial transformations would need to be reversed - a much more complex and error prone process. - + - - + + Abstract class to facilitate the combination of Mappings in various ways. Since they are themselves mappings, they can be used as a components in other compound mappings to create arbitrarily complex transform expressions. - - - + + + List of component mappings. Joins multiple mappings together to form a single unit. The interpretation of the list set depends on the particular sub-class of CompoundMap. - + - - + + - - + + Combines the component mappings in series. This allows the building of multi-stage transforms such as a Matrix operation followed by a WCS Projection. When the invert flag is 'True', the forward operation of the ComposeMap is defined by the inverse of the content, iterating the component list in reverse order, executing the inverse operation of each component. - + - - + + Combines the component mappings in parallel. This enables the building of a mapping which covers the full dimension space of the input. Axes are distributed to the component mappings in order. For example, to perform a shift on a 2-dimensional coordinate (x,y), one would join two Shift maps giving the offset in x and y respectively. When the 'invert' flag is True, the forward operation of the ConcatenateMap is defined by applying the inverse operations of the component mappings. - + - - + + Enumeration of interpolation methods to control the interpretation of data between known points in operations such as Lookup. - - + + No interpolation method specified, interpretation between points is undefined. - - + + Nearest neighbor is selected - - + + Assume a linear progression between points. - - + + Perform a spline interpolation through the points. 2-dimensional only. - - + + Enumeration of non-linear celestial projection algorithm codes as listed in Table 13 of the FITS WCS paper II. - - + + Zenithal perspective - - + + Slant zenithal perspective - - + + Gnomonic (Tangent plane projection) - - + + Stereographic - - + + Slant orthographic (Sine projection) - - + + Zenithal equidistant - - + + Zenithal polynomial - - + + Zenithal equal-area - - + + Airy - - + + Cylindrical perspective - - + + Cylindrical equal-area - - + + Plate carree - - + + Mercator - - + + Sanson-Flamsteed - - + + Parabolic - - + + Mollweide - - + + Hammer-Aitoff - - + + Conic perspective - - + + Conic equal-area - - + + Conic equidistant - - + + Conic orthomorphic - - + + Bonne equal-area - - + + Polyconic - - + + Tangential spherical cube - - + + COBE Quadrilateralized spherical cube - - + + Quadrilateralized spherical cube - - + + Permute the order and possibly number of dimensions between operations. This operation facilitates the workflow through the operation sequence. It is comprised of an ordered axismap list defining the output axis sequence in terms of the source (input) axes. It supports the reorder, duplication, and dropping of dimensions. Reorder Example: We have a 3-dimensional coordinate (x,y,z) and wish to perform a 2-dimensional transform on the (x,z) plane. Define a Permute operation to reorder the axes from (x,y,z) to (y,x,z) using an axismap list specifying the new axis order, [2,1,3]. The results feed into the next step ( 1D + 2D operations ). Duplicate Example: We have 2-dimensional coordinate (x,y) feeding two Polynomial2D operations to form (x',y'). Define a Permute operation with axismap list specifying sourceAxis set [1,2,1,2]. The result feeds into the next step ( Polynomial2D + Polynomial2D operations). @@ -251,628 +251,628 @@ When the 'invert' flag is True, the forward operation of the ConcatenateMap is d Add Example: We have a 2-dimensional operation feeding into axes [1,3] of a 3-dimensional operation. Define a Permute operation with numSourceAxes=2; and sourceAxis set [1,0,2] where output axis 2 also specifies the fixed seed value. - - - + + + Ordered list defining the number and order of the resulting axis set. Each entry provides the source (input) dimension for that output dimension. - - + + - - + + The number of input axes. Used to verify dimensional coverage in forward and inverse directions. For example, numSourceAxes=4 with axismap=[1,3] indicates that axes [2,4] have been dropped. - - + + - - + + Entry for the Permute operation, this object defines the mapping of input dimension to output dimension. The output dimension is determined from its order in the axismap list. - - + + Source (input) dimension number, 1 based. - - + + Value to assign for the new dimensional axis. - + - - + + A 1-Dimensional operation which makes no change to the inputs. ( X' = X ) - + - - + + A 1-Dimensional operation defining a simple offset. ( X' = X + offset ) - - - + + + The amount of offset to apply. - - + + A 1-Dimensional operator for simple scaling. ( X' = factor*X ) - - - + + + The scale factor. - - + + A 2-Dimensional rotation operation. - - - + + + Rotation angle, in degrees, from the positive direction of axis 1 toward the positive direction of axis 2. - - + + Defines a rotation operation in a 3-dimensional cartesian coordinate space, defined as a series of rotations about the native axes (x,y,z). - - - + + + Rotation angle about a specified axis. - + - - + + - - + + Angular rotation about a particular axis of a 3-dimensional cartesian coordinate space. - - + + Identifies the axis of rotation. MUST be 'x', 'y', or 'z' - - + + Angle of rotation, in degrees. Angle sign follows the right-hand rule, where positive values indicate clockwise rotation (looking in +axis direction), negative values for counter-clockwise. - - + + An M x N matrix operation. Each cell of the matrix is provided by a MatrixElement object. Missing elements should be considered to equal 0. - - - + + + Collection of MatrixElements which define each cell of the matrix. The total number of elements MUST NOT exceed M*N, any missing elements result in a cell with value=0.0. - - + + - - + + Number of rows in the matrix. - - + + Number of columns in the matrix. - - + + - - + + The value of cell m,n in an M x N matrix. - - + + Matrix cell row number. - - + + Matrix cell column number. - - + + Matrix cell value. - - + + Abstract head of World Coordinate System (WCS) projection operations. We do not attempt to define the operations here, but instead, provide extensions which support the transforms described in the FITS WCS papers II and III. - - - + + + Set of 0 or more parameters providing supplemental metadata required to execute a particular projection algorithm. The number and meaning of the parameters depends on the algorithm. They are typically in the from of keyword/value pairs, so we provide a simple ProjectionParam element to accommodate these. The detailed content description is left to the WCS paper. - - + + - - + + - - + + Simple parameter specification for WCS Projections. The parameter is modeled as a simple name/value pair. The details of expectations for the various projection algorithms is left to the WCS paper describing the algorithm. - - + + The parameter name as described in the WCS papers for each operation type. - - + + The value for the parameter. - - + + This class corresponds to the Spherical Projection component of the FITS WCS paper II. As in the paper, this operation describes the mapping from the intermediate &quot;Projection Plane&quot; to the &quot;Native Spherical&quot; coordinate system. This model supports all defined projection types, where the appropriate code is specified in the algorithm attribute. All projection parameters are to be provided through the ProjectionParam list according to the descriptions given in the FITS WCS paper. - - - + + + The projection algorithm to apply. The value MUST be taken from the enumeration of standard sky projection algorithms. Extracted from &#39;ctype&#39; in the FITS WCS representations. - - + + This class extends SkyProjection to include the Spherical Rotation component of the FITS WCS paper II. This operation describes the mapping from the "Native Spherical" coordinate system to the "Celestial" coordinate system. The reference values are provided at the appropriate attribute, while all other parameters (e.g. LONPOLE, LATPOLE) are to be provided through the ProjectionParam list according to the descriptions given in the FITS WCS paper. - - - + + + The target reference values in each dimension. Equivalent to 'crval' in FITS WCS representations. - - + + - - + + This class represents a nonlinear one-dimensional spectral transform as detailed in the FITS WCS paper III. - - - + + + The target reference value for the axis. Equivalent to 'crval' in FITS WCS representations. - - + + The projection algorithm to apply. The value MUST be taken from the enumeration of non-linear spectral projection algorithms. Extracted from 'ctype' in FITS WCS representations. - - + + The resulting spectral coordinate type code. Values MUST be taken from the enumerated list of spectral coordinate types. Extracted from 'ctype' in FITS WCS representations. - - + + Abstract head of a family of Polynomial distortion operations. - - - + + + The order, or degree, of the polynomial expression. - - + + A 1-Dimensional Polynomial transform represented by the expression: X' = SUM( Ci*X**i), i=0..order. Each term is provided by a PolyCoeff1D object. Missing terms are considered to have a coefficient of 0.0. - - - + + + A term in the polynomial expression. - + - - + + - - + + A term of the polynomial expression. This object provides the coefficient (c) and power (p) of the term, forming the expression c*X**p. - - + + Multiplicitive coefficient of the term. - - + + The power to raise the value for this term. - - + + A 2-Dimensional Polynomial transform represented by the expression: X' = SUMi,j( Cij*X**i*Y**j), i+j<=order. Each term is provided by a PolyCoeff2D object. Missing terms are considered to have a coefficient of 0.0. - - - + + + A term in the polynomial expression. - + - - + + - - + + A term of the polynomial expression. This object provides the coefficient (c) and power (p) of the term, forming the expression c*X**p[0]*Y**p[1]. - - + + Multiplicitive coefficient of the term. - - + + The power to raise the values for this term in each dimension. - - + + - - + + Defines a lookup table operation. The Lookup is comprised of a series of value pairs (LookupEntry) which link specific points in the native system to corresponding points in the target system. The 'interpolation' flag tells the user how to interpret data which falls between entries in the lookup table. All members of the series MUST be of the same type. Lookup tables with StringEntry type content MUST have interpolation="None". Handling Enumerated data: A common usage of a Lookup operation is to map image pixel index to an enumeration, such as a Polarization state. This can be handled by two means: 1) Define a numeric equivalent for each enumeration literal, and use NumericEntry types. Casting to the corresponding literal occurs outside of the operation. 2) Your local model can define a LookupEntry extension which maps the native value directly the target EnumerationLiteral. The details of either approach for particular enumerations is considered outside the scope of this document. - - - + + + Set of lookup table entries forming a discrete mapping from the native space to the target space. - + - - + + Specifies the form of interpolation, if any, prescribed to be performed. - + - - + + Flag to specify behaviour outside the lookup table data bounds. True indicates an error condition, False indicates that the associated "fill" entry should be returned. If no "fill" entry is provided, the value should be extrapolated. - + - - + + - - + + This is an abstract head of lookup table entry objects. Each entry provides a discrete translation of a 'native' value to the corresponding 'target' value. - - + + When TRUE, the entry provides values to be used outside the Lookup table data domain. MUST only appear first or last in the sequence. If missing, it is considered to be FALSE. - + - - + + A 1-Dimensional discrete mapping of numeric values. - - - + + + The native, or reference, value of the lookup entry. - - + + The target, or resulting, value of the lookup entry. - - + + A 2-Dimensional discrete mapping of numeric values. - - - + + + The native, or reference, value of the lookup entry. - - + + - - + + The target, or resulting, value of the lookup entry. - - + + - - + + A 1-Dimensional discrete mapping of an integer counter to a corresponding string form. Since the result is non-numeric, a Lookup operation with StringEntry-s can only be used at the end of a Transform sequence. - - - + + + The native, or reference, value of the lookup entry. - - + + The target, or resulting, value of the lookup entry. - - - - - + + + + + - - - - - - - - - + + + + + + + + + - - - + + + - - - + + + - - - + + + - - + + Enumeration of non-linear spectral projection algorithm codes as listed in Table 2 of the FITS WCS paper III. NOTE: We exclude the TAB code from this list, that type is handled by the Lookup operation in this model. - - + + Frequency - Wavelength - - + + Frequency - Apparent radial velocity - - + + Frequency - Air wavelength - - + + Wavelength - Frequency - - + + Wavelength - Apparent radial velocity - - + + Wavelength - Air wavelength - - + + Apparent radial velocity - Frequency - - + + Apparent radial velocity - Wavelength - - + + Apparent radial velocity - Air wavelength - - + + Air wavelength - Frequency - - + + Air wavelength - Wavelength - - + + Air wavelength - Apparent radial velocity - - + + Logarithm - - + + Grism - - + + Grism in air - - + + Enumeration of spectral coordinate types as listed in Table 1 of the FITS WCS paper III. - - + + Frequency - - + + Energy - - + + Wavenumber - - + + Radio velocity - - + + Vacuum wavelength - - + + Optical velocity - - + + Redshift - - + + Air wavelength - - + + Apparent radial velocity - - + + Beta factor (v/c) - - - + + + <Enter note text here> - - - - + + + + - - + + TransformSet supports the relation of coordinate systems via Mappings. The design is such that it supports the relation of collections of related coordinates systems by the various mappings between them. A single TransformSet can relate a tree of spatial coordinate systems, individual TransNodes can be used as the parent for multiple branches. For example: @@ -885,128 +885,128 @@ Each transition is encapsulated by a TransNode instance linking the parent coord A simple transform from system A to system B requires two TransNodes, one describing system A (with no Mapping), and another describing system B with the Mapping from A to B. - - + + A node in the transform set, relating a parent and target coordinate system with the corresponding mapping specification. - + - - + + - - + + TransNode is a container object relating a parent coordinate system and a target coordinate system (that of the node) with the mapping relation between them. The associated Mapping MUST be constructed such that the mapping inputs correspond to the parent coordinate system and the mapping outputs to the target coordinate system. If either the parent node or mapping is NULL, the other MUST also be NULL. This forms a 'root' node, containing only the target coordinate system, and serves as an origination node in the TransformSet. If the target is NULL, the parent and mapping MUST NOT be NULL, additionally such a node MUST NOT be the end point of a node sequence (ie: must be the 'parent' of another node). This type of node can be useful for cases where the mapping defines the transform to an unspecified intermediate coordinate system, and enables a more efficient and compact structure for the TransformSet by forming a node at this intermediate coordinate system which can serve as the parent for multiple subsequent nodes. - - + + This identifies the source coordinate system node. The associated mapping describes the transformation from this parent system to the target system of this node. Will be NULL for 'root' nodes. - + - - + + This identifies the target coordinate system node. It is the represenitive coordinate system for this node. The associated mapping describes the transformation from the parent system of this node to this target system. The coordinate systems themselves are described in the IVOA "Astronomical Coordinates and Coordinate Systems" model. - + - - + + This is a reference to the mapping relating the parent coordinate system to the target system. Will be NULL for 'root' nodes. - + - - - + + + - - - + + + - - + + An entry in the CompountMap component mapping list. Holds a reference to the component mapping. - - + + Reference to the component Mapping. - - - + + + - - + + The BiDirectionalMap supports cases where one wants to explicitely define independent transforms for the forward and inverse operations. This may be because a mapping does not have a analytical inverse, or dictated by the requirements of the application. The associated mappings do not have to be of the same type. The forward operation of the BiDirectionalMap is supported by the forward operation of the forwardMap, and the inverse operation of the BiDirectionalMap by the inverse operation of the inverseMap. If the 'invert' flag is True, this is reversed so that the forward operation of the BiDirectionalMap is supported by the inverse operation of the inverseMap, and the inverse operation of the BiDirectionalMap by the forward operation of the forwardMap. - - - + + + The Mapping that defines the inverse operation of the BiDirectionalMap. The inverse operation of the target Mapping is used as the inverse operation of the BiDirectionalMap. If the inverse operation of the target Mapping is undefined, then the inverse operation of the BiDirectionalMap is also undefined. The forward operation of the target Mapping is never used and may be undefined. - - + + The Mapping that defines the foward operation of the BiDirectionalMap. The forward operation of the target Mapping is used as the foward operation of the BiDirectionalMap. If the forward operation of the target Mapping is undefined, then the forward operation of the BiDirectionalMap is also undefined. The inverse operation of the target Mapping is never used and need not be defined. - - - + + + - - - + + + - - - + + + - + - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/work/README.md b/work/README.md new file mode 100644 index 0000000..a29fc76 --- /dev/null +++ b/work/README.md @@ -0,0 +1,89 @@ + +# Overview + +This is a workspace area for the development of the data model and subsequent generation +of the various products derived from the vo-dml/XML representation of the model. + +Since there are many paths for generating the data model documents, the products themselves +are stored in the other directories of this repository, and no software is installed in this +workspace. Instead, we provide the instructions for duplicating the workflow used to create +the current products. + +# Data Modeling Tool + +The modeling itself is currently done using Modelio. This includes the UML diagrams, and documentation +of the model elements. This is exported as an XMI (UML-2.4.1 format) document which can be found in the 'model' +sibling directory. The XMI file is processed using the VO-DML Toolkit to generate the VO-DML/XML file and +other products. + +# VO-DML Toolkit plugin + +This toolkit provides a set of tasks for generating and translating vo-dml/XML files. +For details on the toolkit, please see the "[Using the VO-DML Gradle Plugin](https://github.com/ivoa/vo-dml/tree/master/tools)" +page of the [VO-DML repository](https://github.com/ivoa/vo-dml). + +The files included here are those necessary to execute the tasks outlined below. + +## Setup + +* Clone this repository + The toolkit is a command-line system + +* "[VO-DML Tools Guide](https://ivoa.github.io/vo-dml/)" + Guide on the VO-DML Toolkit and how to use it. + +* Install gradle + Instructions can be found on the "[Using the VO-DML Gradle Plugin](https://github.com/ivoa/vo-dml/tree/master/tools)" page. + There is no need to run the `gradle init` command, this space includes the files generated by that process tailored to + this particular model and directory structure. + + Note: While gradle requires Java 8 or higher, the toolkit itself requires Java 11 in your environment. + + * build.gradle.kts + * gradle connection to vo-dml toolkit plugin + * dependencies and required information (directory specs) + * register additional tasks + * settings.gradle.kts + * gradle support + * bindings__model.xml + * mapping between model and generated files. + + +## Running Tasks + +The toolkit contains several tasks which can be used to generate and validate VO-DML/XML files, or translate them into +various other formats or to code. These instructions are focused on the tasks used to create and validate the +VO-DML/XML files and generation of the standard HTML documentation. + +* ```%> gradle UMLToVODML``` + This model is currently developed using the Modelio UML tool and exported to UML-2.4.1 format. + This command translates the XMI file into the VO-DML/XML representation. + + * input, output, and translation script are specified with the task registration in build.gradle.kts + * the task locates the xmi file, and executes the specified translation script + * output is written to ./src/main/vo-dml/ + +* ```%> gradle vodmlValidate``` + Runs the VO-DML validation utility on the vo-dml/xml file. + + * locates the vo-dml/XML file using the information contained in build.gradle.kts + * executes the validation utility + * output is echoed to the screen + +* ```%> gradle vodslToVodml --dml= --dsl=``` + Runs a utility to VO-DML/XML files from models described in vodsl format. + + * locates the vodsl file using the information contained in build.gradle.kts + * executes the translation task + * output is written to ./src/main/vodsl/ + +* ```%> gradle vodmlDoc``` + Runs a utility to generate HTML (and Tex) representation of the model. + Note: This model does not use the Tex format output from this utility for the actual PDF document. + + * locates the vo-dml/XML file using the information contained in build.gradle.kts + * executes the translation task + * output is written to ./build/generated/docs/vodml + + +* Schema Generation diff --git a/work/binding_transform_model.xml b/work/binding_transform_model.xml new file mode 100644 index 0000000..8e49927 --- /dev/null +++ b/work/binding_transform_model.xml @@ -0,0 +1,11 @@ + + + + +trans +Trans-v1.0.vo-dml.xml + org.ivoa.trans.transform +http://ivoa.net/dm/models/vo-dml/xsd/trans/ + + diff --git a/work/build.gradle.kts b/work/build.gradle.kts new file mode 100644 index 0000000..815db99 --- /dev/null +++ b/work/build.gradle.kts @@ -0,0 +1,60 @@ + +plugins { + // id("net.ivoa.vo-dml.vodmltools") version "0.4.5" << requires gradle version 8.0+ + id("net.ivoa.vo-dml.vodmltools") version "0.3.14" +} + +group = "org.javastro.ivoa.dm" // "net.ivoa.vo-dml" +version = "0.4.1-SNAPSHOT" // "0.2-SNAPSHOT" + +// Settings for all vodml tools +vodml { + // where to find the vodml XML files (using 'project' structure) + // - defaults to src/main/vo-dml + //vodmlDir.set( file("") ) + + // identify the vodml XML files + // - defaults to all "*.vo-dml.xml" files in vodmlDir + //vodmlFiles.setFrom( project.files( vodmlDir.file("Trans-v1.0.vo-dml.xml") )) + + // where to find the VODSL files + // - defaults to src/main/vodsl + //vodslDir.set( file("./src/main/vodsl") ) + + // identify the VODSL files (using 'project' structure) + // - defaults to all "*.vodsl" files in vodslDir + //vodslFiles.setFrom( project.files( vodslDir.file("Trans-v1.0.vodsl") )) + + // where to find the binding file(s) + // - finds them by pattern in the project file tree. (eg: binding_proposal_model.xml ) + bindingFiles.setFrom( project.files( + layout.projectDirectory.asFileTree.matching( PatternSet().include("binding*model.xml") ) + )) + + // where to put output from vodmlDoc task + outputDocDir.set(layout.projectDirectory.dir("std/generated")) + + // where to put output from vodmlSite task ( toolkit 0.4.5 ) + // outputSiteDir.set(layout.projectDirectory.dir("docs/generated")) + + // which models to process ( for repos containing multiple models? ) + modelsToDocument.set("transform") +} + +// Register task to execute UML converter which is very custom +tasks.register( "UmlToVodml", net.ivoa.vodml.gradle.plugin.XmiTask::class.java){ + // ---------------------------------------------------------- + // creates build/tmp/UmlToVodml tree to write temporary files + // ---------------------------------------------------------- + description = "convert UML to VO-DML" + + // the conversion script to use + xmiScript.set("xmi2vo-dml_Modelio3.7_UML2.4.1.xsl") + + // where to find the UML XMI file + xmiFile.set(file("../model/trans_1.0_uml2p4p1.xmi")) + + // output VO-DML/XML file to 'project' tree structure + // - this lets us use a lot of default settings in the vodml block + vodmlFile.set(file("./src/main/vo-dml/Trans-v1.0.vo-dml.xml")) +} diff --git a/work/settings.gradle.kts b/work/settings.gradle.kts new file mode 100644 index 0000000..2e24d27 --- /dev/null +++ b/work/settings.gradle.kts @@ -0,0 +1,27 @@ +rootProject.name = "TransformDM" + +// space for gradle toolkit to work within +// - this doesn't appear to be necessary +include("work") + + +pluginManagement { + repositories { + mavenLocal() // IMPL allow picking up from local - should be removed when publishing + gradlePluginPortal() + } +} + +dependencyResolutionManagement { + repositories { + mavenLocal() + mavenCentral() + /* + add this repository to pick up the SNAPSHOT version of the IVOA base library - in the future when this + will not be necessary when this library is released as a non-SNAPSHOT version. + */ + maven { + url= uri("https://oss.sonatype.org/content/repositories/snapshots/") + } + } +}