This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
gramar_defined [2016/06/28 11:11] chrisgerken |
gramar_defined [2016/10/14 02:37] (current) chrisgerken |
||
|---|---|---|---|
| Line 3: | Line 3: | ||
| noun **|** **gram** - ar **|** \ˈgra-mər\ | noun **|** **gram** - ar **|** \ˈgra-mər\ | ||
| - | Simply put, a gramar is a tool that can generate up to 95% (historically speaking, ex business logic) of a component for almost any given software architecture. Past examples of supported architectures include: | + | A gramar is a lightweight development tool that can generate up to 95% (historically speaking, ex business logic) of a component for almost any given software architecture. Past examples of generated architectures include: |
| - | - Hadoop applications (Storm topologies, Mapreduce job flows, Kafka components) | + | - Hadoop applications (Storm topologies, Mapreduce job flows, Kafka components, Oozie flows, Sqoop jobs) |
| - Database persistence layers, both relational and NoSQL (HBase, Cassandra, Elasticsearch) | - Database persistence layers, both relational and NoSQL (HBase, Cassandra, Elasticsearch) | ||
| - | - J2EE programming models (Servlets, EJB's, portlets, JSP tag libraries) | + | - J2EE programming models (Servlets, EJB's, ESB's, Portlets, JSP tag libraries) |
| - Eclipse tools (Text editors, Multi-page editors, UML schemas, Popup actions) | - Eclipse tools (Text editors, Multi-page editors, UML schemas, Popup actions) | ||
| + | - Documentation (HTML, wiki) | ||
| - Gramars themselves | - Gramars themselves | ||
| - | To be a bit more formal, a gramar is a set of production rules for source and other files in a component implementation adhering to a specific software architecture. Each gramar has an associated schema that models the allowed points of variability between instances of that software architecture. Each production describes how to generate a file from those points of variability and is often applied multiple times, depending on the cardinality of the model. A grammar does not describe the meaning of the generated files nor what can be done with them. It only captures and generates their content. | + | To be a bit more formal, a gramar is a set of production rules for source and other files in a component implementation adhering to a specific software architecture. Each gramar has an associated schema that models the allowed points of variability between instances of that software architecture. Each production describes how to generate a file from those points of variability and is often applied multiple times, depending on the cardinality of the model. A gramar does not describe the meaning of the generated files nor what can be done with them. It only captures and generates their content. |
| The Gramar toolset supports the creation, authoring, distribution and application of individual gramars accross a number of IDE's and runtime environments. | The Gramar toolset supports the creation, authoring, distribution and application of individual gramars accross a number of IDE's and runtime environments. | ||
| Line 27: | Line 28: | ||
| - As a single zip file, again deployed on the file system or the classpath | - As a single zip file, again deployed on the file system or the classpath | ||
| - As a jar file | - As a jar file | ||
| + | - As a project in an Eclipse workspace | ||
| + | - As an Eclipse plugin (although technically that's just another variant of a class path) | ||
| ==== Productions ==== | ==== Productions ==== | ||
| Line 32: | Line 35: | ||
| A production is a text file whose boilerplate content generally resembles the file content it's meant to generate. Imbedded in its text content are gramar tags that can: | A production is a text file whose boilerplate content generally resembles the file content it's meant to generate. Imbedded in its text content are gramar tags that can: | ||
| - | - Read data from the model and insert in-place within the template boilerplate | + | - Read data from the model using standard XPath expressions and insert in-place within the template boilerplate |
| - Transform and write data back into the model | - Transform and write data back into the model | ||
| - Conditionally process nested boilerplate and tags. The conditional processing includes **if**, **case** and **iterative** behaviors. | - Conditionally process nested boilerplate and tags. The conditional processing includes **if**, **case** and **iterative** behaviors. | ||
| Line 38: | Line 41: | ||
| As such, the processing of a production is effectively top-down procedural with possible side effects to the model and, in the case of **main.prod**, the creation of projects, folders and files. | As such, the processing of a production is effectively top-down procedural with possible side effects to the model and, in the case of **main.prod**, the creation of projects, folders and files. | ||
| - | |||
| ==== Background ==== | ==== Background ==== | ||
| - | Gramar is a next-generation greenfield implementation of both Eclipse Model-to-Text JET and, before that, the Design pattern Toolkit from IBM. A gramar can be applied not just in Eclipse, but in IntelliJ, as a stand-alone java application, within a web application or in any other environment. | + | Gramar is a complete, next-generation rewrite of Eclipse Model-to-Text JET and, before that, the Design pattern Toolkit from IBM. A gramar can be applied not just in Eclipse, but in IntelliJ, as a stand-alone java application, within a web application or in any other Java execution environment. |
| + | |||
| + | Back to [[start|Home]] | ||