Code Monkey home page Code Monkey logo

rug's Introduction

DEPRECATED 'rug'

Build Status

The Rug runtime: Support for Atomist project operations and handlers (aka rugs). Rugs are authored in JavaScript or any language that compiles to JavaScript capable of executing in Nashorn. We recommend TypeScript and provide TypeScript interfaces for the Atomist project and team model.

Key areas of functionality of this project:

Area Purpose Base Package/Path Remarks
Tree model Models project and file structure (e.g. ASTs) as a unified tree com.atomist.tree Used by parser and path expressions
Project operation support Editors and executors com.atomist.project Project operations are authored in TypeScript, JavaScript or any language that compiles to JavaScript.
Parsing support Support for parsing files and preserving positional information to allow clean in-place updates com.atomist.tree.content.text Integrates with Scala parser combinators and Antlr.
JavaScript/TypeScript integration Allows project operations to be written in JavaScript/TypeScript com.atomist.rug.runtime.js Uses Nashorn
Path expression language XPath-like language for conveniently navigating trees com.atomist.tree Central concept for navigating project and model structure
TypeScript library A node module to simplify authoring TypeScript rugs src/main/typescript See architectural overview. Will eventually be moved into a separate project.

See

Using

Most users will not need to use this project directly, but will use tools, e.g., rug-cli, that build on this project.

If you wish to develop tools using this project, you will need to add this project as a dependency and the maven repository where it is published to your build tool's configuration. For example, if you use maven, add the dependency to the <dependencies> section and the repository to the <repositories> section of your pom.xml:

<?xml version='1.0' encoding='UTF-8'?>
<project
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://maven.apache.org/POM/4.0.0">
	<modelVersion>4.0.0</modelVersion>
    ...
    <dependencies>
        ...
		<dependency>
			<groupId>com.atomist</groupId>
			<artifactId>rug</artifactId>
			<version>0.3.2</version>
			<exclusions>
				<exclusion>
					<groupId>ch.qos.logback</groupId>
					<artifactId>logback-classic</artifactId>
				</exclusion>
				<exclusion>
					<groupId>ch.qos.logback</groupId>
					<artifactId>logback-access</artifactId>
				</exclusion>
			</exclusions>
		</dependency>
        ...
	</dependencies>
    ...
	<repositories>
		<repository>
			<id>public-atomist-release</id>
			<name>Atomist Release</name>
			<url>https://atomist.jfrog.io/atomist/libs-release</url>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
	</repositories>
    ...
</project>

Be sure to change the <version> to the one you want to use.

Support

General support questions should be discussed in the #support channel on our community slack team at atomist-community.slack.com.

If you find a problem, please create an issue.

Development

You can build, test, and install the project locally with Maven.

$ mvn install

This will build, test, and locally install the Rug library. To build the Rug TypeScript @atomist/rug and @atomist/cortex modules, the "npm-release" profile must be used. Unlike the cortex build, the cortex model is not downloaded dynamically because Rug tracks the latest, perhaps unreleased, version of the model.

To build the TypeScript modules and their documentation, generated from the TypeScript modules using TypeDoc, execute at least through the Maven lifecycle test phase using the npm-release profile.

$ mvn -P npm-release test

The documentation for all of the Rug extensions will be in a directory named target/typedoc.

Development versions of the @atomist/rug npm module are published to https://atomist.jfrog.io/atomist/api/npm/npm-dev. The most straightforward way to get these versions without making changes to your configuration is:

$ npm install @atomist/rug --registry https://atomist.jfrog.io/atomist/api/npm/npm-dev

Alternatively, if you always want the latest snapshot, you can change your config for the @atomist scope:

npm config set @atomist:registry https://atomist.jfrog.io/atomist/api/npm/npm-dev

Release

Releasing Rug involves releasing the JVM artifacts to a Maven repository, the TypeScript module to NPM, and the documentation to GitHub pages for this repository, available at http://apidocs.atomist.com/ . Releasing Rug can be a multi-stepped process, depending on the changes that have been made.

If there are no changes to the TypeScript API, to create a release simply push a tag of the form M.N.P where M, N, and P are integers that form the next appropriate semantic version for release. For example:

$ git tag -a 1.2.3

The Travis CI build (see badge at the top of this page) will upload the needed artifacts and automatically create a GitHub release using the tag name for the release and the comment provided on the annotated tag as the contents of the release notes. The released artifacts are:

Note that while the @atomist/cortex module is built as part of the rug build, it is published by the cortex repository build. The cortex release process also publishes the cortex TypeDoc to http://cortex.atomist.com . So if the API of cortex has changed at all, you will need to initiate a release of that repository. This confusion will need to be resolved at some point in the future.

If there have been changes to either the @atomist/rug or @atomist/cortex TypeScript APIs, you will need to update the dependencies in the rugs repository package.json and initiate a new release of that repository to publish a new version of the @atomist/rugs TypeScript module, which is the dependency everyone uses to bring in rug and cortex. This should all be automated, perhaps in a separate repository or by chaining events to span repositories.


Created by Atomist. Need Help? Join our Slack team.

rug's People

Contributors

alankstewart avatar atomist-bot avatar cdupuis avatar claymccoy avatar ddgenome avatar eddumelendez avatar janekdb avatar jessitron avatar jessitron-stripe avatar johnsonr avatar jrday avatar justinedelson avatar kipz avatar lawouach avatar russmiles avatar slimslenderslacks avatar whostolebenfrog avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rug's Issues

Failing to parse parameter pattern should indicate which parameter from which rug

I have got a bunch of editors which have a pattern that rug doesn't validate, but when it compiles them, it doesn't tell me which parameter is at fault, nor where to find it.

14:32 $ ../rug-cli/target/rug-cli-0.16.4-SNAPSHOT-bin/rug-cli-0.16.4-SNAPSHOT/bin/rug test -X
Resolving dependencies for atomist-rugs:python-library:0.1.0 ← local completed
Loading atomist-rugs:python-library:0.1.0 ← local into runtime failed

com.atomist.rug.InvalidRugParameterPatternException: Parameter pattern must contain anchors: .*
	at com.atomist.rug.parser.ParserCombinatorRugParser.$anonfun$paramPattern$2(ParserCombinatorRugParser.scala:32)
	at scala.util.parsing.combinator.Parsers$Success.map(Parsers.scala:137)
	at scala.util.parsing.combinator.Parsers$Success.map(Parsers.scala:136)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$map$1(Parsers.scala:237)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$map$1(Parsers.scala:237)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Success.flatMapWithNext(Parsers.scala:143)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$flatMap$1(Parsers.scala:234)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$map$1(Parsers.scala:237)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers.applyp$1(Parsers.scala:718)
	at scala.util.parsing.combinator.Parsers.continue$1(Parsers.scala:724)
	at scala.util.parsing.combinator.Parsers.$anonfun$rep1$1(Parsers.scala:728)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$append$1(Parsers.scala:249)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$map$1(Parsers.scala:237)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Success.flatMapWithNext(Parsers.scala:143)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$flatMap$1(Parsers.scala:234)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$flatMap$1(Parsers.scala:234)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$flatMap$1(Parsers.scala:234)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$flatMap$1(Parsers.scala:234)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$map$1(Parsers.scala:237)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$append$2(Parsers.scala:249)
	at scala.util.parsing.combinator.Parsers$Failure.append(Parsers.scala:197)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$append$1(Parsers.scala:249)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$append$1(Parsers.scala:249)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$append$1(Parsers.scala:249)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers.$anonfun$rep1$1(Parsers.scala:727)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$Parser.$anonfun$flatMap$1(Parsers.scala:234)
	at scala.util.parsing.combinator.Parsers$$anon$3.apply(Parsers.scala:217)
	at scala.util.parsing.combinator.Parsers$$anon$2.$anonfun$apply$2(Parsers.scala:882)
	at scala.util.DynamicVariable.withValue(DynamicVariable.scala:58)
	at scala.util.parsing.combinator.Parsers$$anon$2.apply(Parsers.scala:882)
	at scala.util.parsing.combinator.RegexParsers.parse(RegexParsers.scala:156)
	at scala.util.parsing.combinator.RegexParsers.parse$(RegexParsers.scala:155)
	at com.atomist.util.scalaparsing.CommonTypesParser.parse(CommonTypesParser.scala:24)
	at com.atomist.util.scalaparsing.CommonTypesParser.parseTo(CommonTypesParser.scala:335)
	at com.atomist.rug.parser.ParserCombinatorRugParser.parse(ParserCombinatorRugParser.scala:248)
	at com.atomist.rug.InterpreterRugPipeline.$anonfun$parseRugFiles$2(InterpreterRugPipeline.scala:37)
	at scala.collection.TraversableLike.$anonfun$flatMap$1(TraversableLike.scala:241)
	at scala.collection.mutable.ResizableArray.foreach(ResizableArray.scala:59)
	at scala.collection.mutable.ResizableArray.foreach$(ResizableArray.scala:52)
	at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
	at scala.collection.TraversableLike.flatMap(TraversableLike.scala:241)
	at scala.collection.TraversableLike.flatMap$(TraversableLike.scala:238)
	at scala.collection.AbstractTraversable.flatMap(Traversable.scala:104)
	at com.atomist.rug.InterpreterRugPipeline.parseRugFiles(InterpreterRugPipeline.scala:36)
	at com.atomist.rug.InterpreterRugPipeline.create(InterpreterRugPipeline.scala:29)
	at com.atomist.project.archive.ProjectOperationArchiveReader.findOperations(ProjectOperationArchiveReader.scala:43)
	at com.atomist.rug.loader.DefaultOperationsLoader.loadArtifact(DefaultOperationsLoader.java:161)
	at com.atomist.rug.loader.DefaultOperationsLoader.load(DefaultOperationsLoader.java:85)
	at com.atomist.rug.cli.command.AbstractCommand.doLoadOperations(AbstractCommand.java:89)
	at com.atomist.rug.cli.command.AbstractCommand.lambda$loadOperations$0(AbstractCommand.java:82)
	at com.atomist.rug.cli.output.ProgressReportingOperationRunner.run(ProgressReportingOperationRunner.java:20)
	at com.atomist.rug.cli.command.AbstractCommand.loadOperations(AbstractCommand.java:80)
	at com.atomist.rug.cli.command.AbstractCommand.loadOperationsAndInvokeRun(AbstractCommand.java:113)
	at com.atomist.rug.cli.command.AbstractCommand.run(AbstractCommand.java:53)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.atomist.rug.cli.command.ReflectiveCommandRunMethodRunner.invokeCommand(ReflectiveCommandRunMethodRunner.java:20)
	at com.atomist.rug.cli.command.ReflectiveCommandRunner.runCommand(ReflectiveCommandRunner.java:66)
	at com.atomist.rug.cli.Runner.runCommand(Runner.java:122)
	at com.atomist.rug.cli.Runner.run(Runner.java:44)
	at com.atomist.rug.cli.Main.main(Main.java:17)

Support more than one operation in a Rug test

Use case:
I want to test whether an editor is idempotent. I want something like:

given
  ArchiveRoot
  UpgradeToBeginnerProgram

when
  UpgradeToBeginnerProgram

then
  NoChange

Currently we can only run exactly one editor. I want to be able to run more please. Either in the given or the when or both.

referencing a parameter changes behavior of editor.

From @jessitron on November 20, 2016 0:34

This is super weird and I don't have any idea what it means, but it's reproducible and it's was terrible so check it out:

Take this as a starting project:
https://github.com/jessitron/yow-test-1/tree/ready-to-upgrade-to-beginner-program

And then take this version of my templates:
jessitron/elm-template@2e8e090

And run the UpgradeToBeginnerProgram editor on that starting project.
It prints (among other things)

Upgrading from static to beginner program
Adding import Html to module Main in Main.elm
 looking for import
Running editor UpgradeToBeginnerProgram of jessitron:elm-template:1.0.0 → local completed

and it does not change the line "import Html" in src/Main.elm. It should be changing that to "import Html exposing Html" in the AddImportExposure editor, called here.

It doesn't find the import line though, based on the printing.

This commit fixes it: jessitron/elm-template@3d34ed6

WHY DOES THAT FIX IT
It adds a check to the elm module (which it was already finding), to see that it matches a totally different parameter.

Running the editor then prints:

Upgrading from static to beginner program
Adding import Html to module Main in Main.elm
 looking for import
time to add the exposure to <Html>
Running editor UpgradeToBeginnerProgram of jessitron:elm-template:1.0.0 → local completed

and it does add the exposure and all is well.

Add support for java.util.Set for exported functions

From @snewman on November 23, 2016 6:11

Currently when returning collections from exported functions, only java.util.List is supported - it would be nice to add support for other collection types, specifically java.util.Set.

For the record, here is the stacktrace you get when using java.util.Set:

- should generate typescript file *** FAILED ***
  java.lang.UnsupportedOperationException: Unsupported type [Seq]
  at com.atomist.rug.ts.TypeScriptGenerationHelper.javaTypeToTypeScriptType(TypeScriptGenerationHelper.scala:35)
  at com.atomist.rug.rugdoc.TypeScriptGenerator$$anonfun$generateType$2.apply(TypeScriptGenerator.scala:82)
  at com.atomist.rug.rugdoc.TypeScriptGenerator$$anonfun$generateType$2.apply(TypeScriptGenerator.scala:73)
  at scala.collection.TraversableLike$WithFilter$$anonfun$foreach$1.apply(TraversableLike.scala:733)
  at scala.collection.mutable.ArraySeq.foreach(ArraySeq.scala:74)
  at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:732)
  at com.atomist.rug.rugdoc.TypeScriptGenerator.generateType(TypeScriptGenerator.scala:73)
  at com.atomist.rug.rugdoc.TypeScriptGenerator.com$atomist$rug$rugdoc$TypeScriptGenerator$$generate$1(TypeScriptGenerator.scala:119)
  at com.atomist.rug.rugdoc.TypeScriptGenerator$$anonfun$emitInterfaces$2$$anonfun$apply$3.apply(TypeScriptGenerator.scala:140)
  at com.atomist.rug.rugdoc.TypeScriptGenerator$$anonfun$emitInterfaces$2$$anonfun$apply$3.apply(TypeScriptGenerator.scala:140)
  …

Expose backing archive (.atomist) directory to PathExpressionEngine

Otherwise it's hard (impossible?) for Editors to get hold of types to manipulate files in the .atomist/ directory

From @johnsonr:

ok, to do that you’d need to expose a PMV for the backing archive

[12:26]
add a method to PMV itself for that

[12:26]
and the backing archive for the backing archive PMV is empty 🙂

[12:26]
then you could run path expressions against it

[12:27]
so pass to the path expression engine project.backingArchiveProject instead of just project

[12:27]
should work

this.eng.with(project.backingArchiveProject, "…path.expr", n => {
///
})

Editor parameter not validated

I ran rug edit jessitron:elm-rugs:AddTextInput input_name=FavoriteColor
and got an Elm parse exception when it used the input_name in a place where it's expected to start with a lowercase letter.
The editor's parameter requires that it start with a lowercase letter:
param input_name: [a-z][\w]*
This wasn't checked; the editor proceeded to execute and fail in a less-scrutable way.

parameters should be validated against their regex before running the editor, eh?


Moved from atomist-attic/rug-cli#26

comment by @cdupuis : CLI call to rug to validate parameters: https://github.com/atomist/rug-cli/blob/master/src/main/java/com/atomist/rug/cli/command/AbstractParameterizedCommand.java#L24

Improve TypeScript interface generator

The current com.atomist.rug.ts.TypeScriptInterfaceGenerator implementation needs improvement in several respects.

  • It should be in a separate open source project downstream of rug to allow it to work on Rug types that aren't defined in rug core
  • It should generate separate files for each Type
  • It does not handle inheritance. E.g. there are methods shared on the various "file" types and on all types, such as fail. These should appear in a super-interface in TypeScript instead of simply being duplicated as now.
  • It does not properly export comments for methods or headers.

Together with this, we should also look at generating TypeDoc docs to help users.

Define the future of Rug types

From @johnsonr on November 20, 2016 4:57

Rug types fall into a number of categories, depending on their closeness to Rug infrastructure:

Category Provided by Examples Remarks
Random user-defined behavior without connections to Atomist model or dependencies on our parsing infrastracture End users chucklet Could even run on Lambda. We would probably need to whitelist certain node packages to allow useful functionality to be implemented. Allowing such behaviors would help replace Hubot and Hubot derivatives.
Types derived from other Rug types End users or Atomist or community contributors Spring project type, which needs the low-level parsing infrastructure defined in the Java types, but doesn't access any new low-level functionality
Transforms files without accessing model or using grammars End users Changes to unstructured files using simple replace or pure regex Author in TypeScript with TypeScript/JavaScript regex primitives. Users can expose to colleagues or publish via a TypeScript class library.
Transforms files without accessing model, but using Atomist microgrammar support or code that can possibly be compiled to JavaScript using Scala.JS. Includes parser-combinator based parsers such as Elm support. End users Potentially this could include anything which our microgrammar support can handle. This feels like a major potential benefit and decision point. Scala.JS may be very important to us.
Transforms files using ANTLR-based model, or a model such as our JavaParser based support that requires a Java library Atomist or rug-lib contributors The major benefit of ANTLR is the existence of so many mature ANTLR grammars
Type that requires acccess to the Neo model Atomist Issue type We provide a mechanism to allow testing in TypeScript or other JavaScript runtimes, but do not aim to decouple such types from our Nashorn-based runtime. We should allow users to define and link custom types, but that's a future discussion.

Conclusions:

  • There should be an Atomist open source library for TypeScript, containing derived types and convenience functionality
  • Whenever we create a new type, we should ask why it's not written in TypeScript, rather than as part of rug-lib's JDK runtime
  • It should be possible to add additional methods to generated TypeScript classes and interfaces, with the generation process preserving them
  • We should prioritize establishing whether Scala.JS can be used to target some of the existing types (and the underlying TreeNode support) to a JavaScript runtime. If this is possible, we should minimize the use of Java or dependencies on Java libraries in rug-lib.

Create JS bindings for rug-cli

So that we can call the main CLI functions from JS build tools such as gulp, grunt etc.

Probably makes sense to distribute as an npm module

Split out language extensions in to separate projects & builds

Currently there are quite a few extensions in this project, which as a few issues:

  • they share different lifecycles, and generated TS interfaces should be separate
    • changes to these extensions cause Rug and the other extensions to rev
  • the rug project is getting very large and unwieldy to build/test

Triple double-quoted strings do not ignore single double-quotes within them

When using triple double-quoted strings in a test file, the parser fails to ignore single double-quotes inside the triple double-quoted string.

.atomist/tests/TestTests.rt:7:43: Failure: string matching regex `given' expected but `"' found
let pom_content = """double "quote" right"""
                                          ^
	at com.atomist.util.scalaparsing.CommonTypesParser.parseTo(CommonTypesParser.scala:336)
	at com.atomist.rug.test.ParserCombinatorTestScriptParser$.parse(ParserCombinatorTestScriptParser.scala:82)
	at com.atomist.rug.test.TestLoader$$anonfun$loadTestScenarios$2.apply(TestLoader.scala:20)
	at com.atomist.rug.test.TestLoader$$anonfun$loadTestScenarios$2.apply(TestLoader.scala:20)
	at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
	at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
	at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
	at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
	at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:241)
	at scala.collection.AbstractTraversable.flatMap(Traversable.scala:104)
	at com.atomist.rug.test.TestLoader.loadTestScenarios(TestLoader.scala:20)
	at com.atomist.rug.cli.command.test.TestCommand.run(TestCommand.java:49)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.atomist.rug.cli.command.AbstractAnnotationBasedCommand.invokeCommandMethod(AbstractAnnotationBasedCommand.java:55)
	at com.atomist.rug.cli.command.AbstractAnnotationBasedCommand.run(AbstractAnnotationBasedCommand.java:43)
	at com.atomist.rug.cli.command.AbstractCommand.loadOperationsAndInvokeRun(AbstractCommand.java:115)
	at com.atomist.rug.cli.command.AbstractCommand.run(AbstractCommand.java:53)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.atomist.rug.cli.command.ReflectiveCommandRunMethodRunner.invokeCommand(ReflectiveCommandRunMethodRunner.java:20)
	at com.atomist.rug.cli.command.ReflectiveCommandRunner.runCommand(ReflectiveCommandRunner.java:66)
	at com.atomist.rug.cli.Runner.runCommand(Runner.java:122)
	at com.atomist.rug.cli.Runner.run(Runner.java:44)
	at com.atomist.rug.cli.Main.main(Main.java:17)

Rug DSL Editors seem to return only information about last operation

I was putting together an Editor to update the Rug dependency version. It needed to handle either the manifest.yml or a package.json. The code looked like this:

let manifest = ".atomist/manifest.yml"
let pkgJSON = ".atomist/package.json"
with project p
  begin
    with file f when path = manifest
      do regexpReplace "requires:.*" { 'requires: "' + manifest_version + '"' }

    with file f when path = pkgJSON
      do regexpReplace "\"@atomist/rug\"\\s*:\\s*\"[^\"]+\"" { '"@atomist/rug": "' + package_version + '"' }
  end

The problem is that when it was run on an archive having a manifest.yml, the Editor would return NoChange. If I remove the handling of the package.json, all is well.

Failed to parse comments starting with # on Windows

Running on Windows 10, I got the following error from the CLI:

C:\Users\sylvain\Documents\spring-boot-rest-service>rug generate -C %temp%\mysvc -R -X -l NewSpringBootRestService myapp
Resolving dependencies for atomist-rugs:spring-boot-rest-service:0.1.0 ? local
Resolving dependencies for atomist-rugs:spring-boot-rest-service:0.1.0 ? local completed
Loading atomist-rugs:spring-boot-rest-service:0.1.0 ? local into runtime failed

.atomist/editors/NewSpringBootRestService.rug:83:1: Failure: string matching regex `[A-Z]' expected but `#' found
# Pattern to replace in old class name.
^
        at com.atomist.util.scalaparsing.CommonTypesParser.parseTo(CommonTypesParser.scala:336)
        at com.atomist.rug.parser.ParserCombinatorRugParser.parse(ParserCombinatorRugParser.scala:247)
        at com.atomist.rug.InterpreterRugPipeline$$anonfun$parseRugFiles$1.apply(InterpreterRugPipeline.scala:37)
        at com.atomist.rug.InterpreterRugPipeline$$anonfun$parseRugFiles$1.apply(InterpreterRugPipeline.scala:36)
        at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
        at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
        at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
        at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
        at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:241)
        at scala.collection.AbstractTraversable.flatMap(Traversable.scala:104)
        at com.atomist.rug.InterpreterRugPipeline.parseRugFiles(InterpreterRugPipeline.scala:36)
        at com.atomist.rug.InterpreterRugPipeline.create(InterpreterRugPipeline.scala:29)
        at com.atomist.project.archive.ProjectOperationArchiveReader.findOperations(ProjectOperationArchiveReader.scala:35)
        at com.atomist.rug.loader.DefaultOperationsLoader.loadArtifact(DefaultOperationsLoader.java:161)
        at com.atomist.rug.loader.DefaultOperationsLoader.load(DefaultOperationsLoader.java:84)
        at com.atomist.rug.cli.command.AbstractCommand.doLoadOperations(AbstractCommand.java:89)
        at com.atomist.rug.cli.command.AbstractCommand.lambda$loadOperations$2(AbstractCommand.java:82)
        at com.atomist.rug.cli.output.ProgressReportingOperationRunner.run(ProgressReportingOperationRunner.java:20)
        at com.atomist.rug.cli.command.AbstractCommand.loadOperations(AbstractCommand.java:80)
        at com.atomist.rug.cli.command.AbstractCommand.loadOperationsAndInvokeRun(AbstractCommand.java:113)
        at com.atomist.rug.cli.command.AbstractCommand.run(AbstractCommand.java:53)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.atomist.rug.cli.command.ReflectiveCommandRunMethodRunner.invokeCommand(ReflectiveCommandRunMethodRunner.java:20)
        at com.atomist.rug.cli.command.ReflectiveCommandRunner.runCommand(ReflectiveCommandRunner.java:69)
        at com.atomist.rug.cli.Runner.runCommand(Runner.java:122)
        at com.atomist.rug.cli.Runner.run(Runner.java:44)
        at com.atomist.rug.cli.Main.main(Main.java:17)

Replacing the # in the various rugs with /* */ got that command to work as expected.

Upgrade to Typescript 2.1

08:53]
cd we have one failing test with TypeScript 2.1.4

[08:53]

 com.atomist.rug.compiler.typescript.TypeScriptCompilationException: .atomist/ConstructedEditor.ts(41,11): error TS2365: Operator '!=' cannot be applied to types '1' and '0'.
.atomist/ConstructedEditor.ts(124,35): error TS2365: Operator '!=' cannot be applied to types '1' and '2'.
 at com.atomist.rug.compiler.typescript.TypeScriptCompiler.handleException(TypeScriptCompiler.java:86)
 at com.atomist.rug.compiler.typescript.TypeScriptCompiler.lambda$compile$0(TypeScriptCompiler.java:52)
 at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
 at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1374)
 at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
 at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
 at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
 at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
 at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
 at com.atomist.rug.compiler.typescript.TypeScriptCompiler.compile(TypeScriptCompiler.java:55)```
(edited)

[08:53]  
^ @kipz

[08:54]  
https://github.com/atomist/rug-typescript-compiler/commit/3356ea7ba5a9c56781afae43dfc010a6e1dec5aa

Provide equivalent of Rug Test support in TypeScript

Allow users to test the behavior of editors in memory using TypeScript, in the same way as they can in Rug Test.

Most likely, this means allowing a TypeScript backed equivalent of the com.atomist.rug.test.TestScenario class, analogous to a TypeScript-backed ProjectEditor. We can probably provide a TypeScript library for assertions such as FileSpec implementations.

Change from interpreting Rug AST to transpiling Rug into TypeScript

This has several major advantages:

  • It removes a good deal of complex code, while the new code to be added is less complex. It's a good moment to do this before open sourcing and handover.
  • It removes any hurdle in upgrading to TypeScript: Simply start working on the generated TypeScript
  • It may enable the MutableView hierarchy to be replaced by TreeNodes, allowing harmonizing with tree path expressions
  • It enables us to keep all the existing tests expressed in Rug
  • The transpiler will offer greater opportunity to optimize than the present Rug with block handling internals

Support complex parameter validation in TypeScript

From @johnsonr on November 19, 2016 11:42

Most parameters should be defined with simple metadata such as regex patterns. But some parameter classes and scenarios will want custom validation. It should be possible to

  • Write a custom validation for a submitted parameter validation. This should be reusable across parameter classes.
  • Add a validate method on a parameter class that can perform cross-parameter validation.

Microgrammar support

From @johnsonr on November 19, 2016 11:40

Support for microgrammars is crucial for offering a consistent, extensible search and replace capability that exceeds the power of regular expressions. No such library exists and we must provide it.

Microgrammar support should:

  • Not depend on ANTLR or other Java dependencies, in case we want to compile it to JavaScript using Scala.JS
  • Be easy to use from both Rug and TypeScript
  • Offer a concise, testable and readable syntax that's easy to learn
  • Be fully integrated with TreeNode hierarchy.

The first 2 steps are:

Complete the implementation in the com.atomist.tree.content.text.microgrammar package
Create TypeScript facades to allow microgrammars to be used from TypeScript
Further refinements will be added in new issues

Useful references include:

https://web.stanford.edu/~mlfbrown/paper.pdf
Various resources on the SNOBOL language

Rug: condition for 'contains'

In Rug, can I say

with file f when f contains "blah"
please?

because { f.contents().indexOf("blah") > 0 } is not nearly as readable.

/cc @gotcha who wanted this

Copy a file in, with correct permissions

Currently to inject a file into a project using an editor, the contents come from a velocity template.
I've been adding ".vm" to filenames and using this as a way to copy files in. However, when the script.vm file is executable, the resulting file in the project is still not.

A "copy file from rug archive to project" (without that file being in the generated project) would be nice.

Standard Rug Parameter Validation Patterns not accessible from TS rugs

From slack:

17:19]
dd @kipz do you know how one would access the predefined parameter validation patterns from TypeScript? Here's how you do it from rug param p_name: @url, where @url is the pattern defined in https://github.com/atomist/rug/blob/master/src/main/scala/com/atomist/param/ParameterValidationPatterns.scala#L26

[17:20]
kipz I think it’s the same, but it could be with a $ instead.

[17:20]
I’ve not tried it. Lemme check.

[17:26]
kipz hmmm…I can’t get either to work. Regexp work, but the lookup isn’t. I expect it’s related to how we populate the parameter model when parsing the TS annotations.

Establish which parts of Rug Scala code can be compiled with Scala.js

From @johnsonr on November 19, 2016 8:22

Some parts of our Scala code, such as microgrammar support, would be very useful to Rug users if they were able to run in JavaScript, and be available from TypeScript tests.

Obviously anything that depends on Java won't work, such as the Neo mappings, but microgrammars and the basic tree structure behind them should be a candidate.

Create TypeScript extension

From @johnsonr on November 19, 2016 11:56

This is important both to improve language support in the JavaScript ecosystem and to enable us to create and evolve rugs written in TypeScript.

Microgrammars may be sufficient

Failing to do a clean clone on Windows

Trying to clone this repository on Windows 10, I got the following message

C:\Users\sylvain\Documents> git version
git version 2.10.2.windows.1

C:\Users\sylvain\Documents>git clone https://github.com/atomist/rug.git
Cloning into 'rug'...
remote: Counting objects: 3581, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 3581 (delta 0), reused 0 (delta 0), pack-reused 3569
Receiving objects: 100% (3581/3581), 751.67 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1806/1806), done.
error: unable to create file src/test/resources/templates/spring-boot/static/${base_source_path}:${package_path}:${application_class_name}.java_.vm: Invalid argument
error: unable to create file src/test/resources/templates/spring-boot/static/${base_source_path}:${package_path}:${configuration_class_name}.java_.vm: Invalid argument
error: unable to create file src/test/resources/templates/spring-boot/static/${base_test_path}:${package_path}:${startup_test_name}.java_.vm: Invalid argument
error: unable to create file src/test/resources/templates/spring-boot/static/${base_test_path}:${package_path}:${web_integration_test_name}.java_.vm: Invalid argument
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

Change from interpreting Rug AST to transpiling Rug into TypeScript

From @johnsonr on November 19, 2016 8:28

This has several major advantages:

  • It removes a good deal of complex code, while the new code to be added is less complex. It's a good moment to do this before open sourcing and handover.
  • It removes any hurdle in upgrading to TypeScript: Simply start working on the generated TypeScript
  • It will enable the MutableView hierarchy to be replaced by TreeNodes, allowing harmonizing with tree path expressions
  • It enables us to keep all the existing tests expressed in Rug
  • The transpiler will offer greater opportunity to optimize than the present Rug With block handling internals

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.