This new change introduces scope blocks, that make it cleaner to list/group dependencies, like:

project {
   modelVersion '4.0.0'
   groupId 'foo.bar'
   artifactId 'example'
   version '0.0.1-SNAPSHOT'
   dependencies {
      $test { //junit and mockito get the test scope
          dependency 'junit:junit:4.12'
          dependency 'org.mockito:mockito-core:1.10.19'
      }
      $compile {//list all compile scoped dependencies here
          dependency 'foo:bar:x.y.z'
          ...
       }
       dependency 'a:b:1.0.0' //also compile  scope
        ...
    } 
 }

The following scoped blocks are supported:

• $compile {...}
• $import {...}
• $test {...}
• $provided{...}
• $runtime {...}
• $system {...}

In the current implementation, dependencies can overwrite the outer scope like

$provided {
    'foo:bar:x.y.z:test' //will have the test scope
}

Signed-off-by: Fred Bricon [email protected]

This change adds an alternative preprocessor directive to the scala dialect.

In addition to #include <file>, now also //##include <file> is supported. The motivation behind this is, to improve the editing experience. The latter added version produces syntax-correct scala files, which in turn improves editors and IDEs, e.g. parsing, formatting and highlighting. The former version does not.

The unusual long prefix //## was choosen, to avoid confusion with a possibly commented out include (e.g. // #include).

Also, this change adds a hint how to debug the pom.scala script to the error message in case of a compile error.

After upgrading to Maven 3.6.2, all my builds that use polyglot-maven get an error like the following:

[FATAL] Non-readable POM /.../.polyglot.pom.kt: input contained no data @ 

To determine whether this was language-specific I've translated a pom.xml to ruby, groovy, and kotlin, and all of of them get the same error on Maven 3.6.2: "input contained no data".

I suspect this may be a bug in Maven due to the nature of the changes described in the release notes, but in my testing I've so far been unable to determine the exact cause of the failure.

I upgraded my cloned copy of polyglot-maven to Maven 3.6.2 and tests that were previously passing are now failing due to an inability to find some required components, but that might be a separate issue.

By using Twitters eval util, we also derive it's #include preprocessor, which by default is a bit unexact when it comes to potential source locations for includable files. Also the include path is unstable when Maven is run in (multi-project) reactor builds.

This patch removes the ambiguities and also makes include pathes more stable when run in reactor builds.

I'm wondering how the POM manipulations that the release plugin does could work on a polyglot maven POM. Wouldn't this require a major update to the release plugin, so it provides hooks the polyglot extensions can use to do the actual changes? Or is it feasible to reverse-engineer the changes the plugin did and re-apply those to the polyglot model? If the version is somehow derived or stored in a custom manner, these hooks would have to be passed to the model code, so e.g. a groovy script can update that source.

I'm writing this, because I have the exactly this problem with my pomx project and I'm wondering if you have already have some concept for this. I didn't find any.

The motivation behind this second goal is to avoid inconveniences with the 'translate' goal, which works on the complete reactor but does not handle errors well.

With this goal, the user can control in detail which projects should be translated and how errors are handled with the known mvn commandline options (e.g.: -N, -pl, -am, -amd, -fae)

This pull request leverages the previous work that was done and re-worked it to support the complete Maven model as well as the following features:

• Updates Kotlin to 1.3.21
• Full Maven model support (including support for previously unsupported elements)
• Gets the classpath for the Kotlin script engine from the Maven ClassRealm
• Includes support for execute tasks both with inline lambdas and external scripts.
• Unit tests provide 100% coverage for the Maven model.
• Adds integration tests
• Resolves ClassRealm issues that affected IntelliJ IDEA

As of commit bfc16c7, the creation of a .tesla.xxx.pom poses some new issues:

• developers will be expected to have their scm ignore .tesla* files;
• the encoding of a model to xml consumes more time vs using an xml directly; and most importantly
• the encoded .tesla.xxx.pom must conform to any restrictions imposed on the pom it was produced from.

I'm particularly concerned about the restriction conformance. For example on the tesla modules, the poms must have license headers. Generated poms do have such headers of course.

The approach of generating a .tesla.xxx.pom is concerning. According to commit bfc16c7 it is because the install plugin requires a pom.xml to deploy. Perhaps there's another way to approach this e.g. have a translate occur as part of the install plugin and reference the updated install plugin as part of the tesla build. The pom.xxx file should also be installed alongside any pom.xml. This approach would also require pom.xxx files to have a higher priority than pom.xml (which I think is a good thing anyhow).

The current polyglot-kotlin implementation uses a JSR-223 ScriptEngine to evaluate the pom.kts file. Since Kotlin 1.3.x the scripting support was improved by using a dedicated scripting host. For details see this KEEP: https://github.com/Kotlin/KEEP/blob/scripting/proposals/scripting-support.md.

In this PR I re-implemented the script evaluation for Kotlin to use the new scripting host. In the future JetBrains will add support to their IDE which will enable auto-completion support and syntax checking for the pom.kts script similiar to Gradle Kotlin scripts.

I also fixed the integration test which referred to an older (non-existing) SNAPSHOT of the polyglot-kotlin core extension. Oddly enough the integration does pass when building because there is also a very basic pom.xml in the integration test which does build (I think having a pom.xml is required for the maven-invoker-plugin to work).

Note that I removed the bindings for the MavenProject, MavenSession and Log classes. This is now impossible to implement because they are not (yet) available when building the Model the first time in the KotlinModelReader class. Initially I added them to the DSL class but Kotlin requires non-null instances of those classes which caused the compilation to fail. I've also tried to inject them using the Plexus container but for example the MavenProject is not available in the KotlinModelReader because the latter is used to create the MavenProject instance. To be honest I don't see why you would want to expose these instances in the Kotlin build script anyway, for me it feels like a smell. But please feel free to elaborate.

maven-tiles https://github.com/repaint-io/maven-tiles allows to have parts of build definition in separate files. Having part of build in parts can enable quicker adoption of polyglot thinking, and skip problem of having to translate parts, e.g. when find an example of plugin configuration.

Possibly this issue should sound like "support translating parts of pom"

ref https://github.com/repaint-io/maven-tiles/issues/61

I tried this for the first time, and it appears that the scala module is having issues.

@mosabua is the scala module been having issues lately?

My suggestion would be to put each of the modules that are not working on their own branch, and if anyone wants to tackle fixing them up they can.

Bumps snakeyaml from 1.17 to 1.32.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

There is a schema description language for json and thus also yaml: http://json-schema.org/ Plus a public repository of community schemas: https://www.schemastore.org/

IntelliJ IDEA even automatically picks this up. If there was one for pom.yml, we would get basic autocompletion and documentation inside the IDE.

Anyone willing to give it a try for polyglot Maven pom.yml? :-)

When defining dependencies, they are a dictionary with the different fields expected by maven. So far, so good. The examples use the flow-style of YAML to reduce the number of lines:

https://github.com/takari/polyglot-maven/blob/master/poms/pom.yml#L37

The flow-style is not that common in YAML. Even tho officially specified (https://yaml.org/spec/1.2.2/#chapter-7-flow-style-productions), people sometimes get confused about it. An example would be https://github.com/takari/polyglot-maven/issues/175 . It also resembles somewhat JSON without being JSON, which is even more confusing with the relation of YAML<->JSON.

This is also the reasoning why the library 'strictyaml' forbids the usage of the flow-style. (Note: Flow-style is only curly braces, the squared braces of arrays are fine). See https://hitchdev.com/strictyaml/why/flow-style-removed/

My suggestions would be:

• Allow the node 'dependencies' to be either an array of dictionaries with the different fields as is, or with a string-field 'id' that represents the coordinates of the dependency.
• This field is parsed by splitting it on every colon, expecting two or three elements representing the coordinates (group and artifactID, optional version)

This would allow allow specifying dependencies like this

dependencies:
  - id: "org.springframework.boot:spring-boot-starter-web"
  - id: "org.mapstruct:mapstruct:1.4.2.Final"

which is not only cleaner and without the flow-style, but also has some resemblance to Gradle. Things like scope would still need an extra line.

Some open questions are what happens if 'id' and the original fields are defined, but I think we could just choose one default behavior and document it.

Alternative ideas:

• encode possible extra settings completely in the string. The 'depencencies' array would then be an array of strings. But with optional fields, this is not very intuitive to add them to the coordinates. Also, with things like excludes, there is no canonical mapping. And when the array just has strings, then all elements would have to be strings. I do not think this is doable cleanly.

Would you be open for such a feature? I might even give it a shot to implement it myself if you believe it could be of interest but have no time yourself. :)

When using pom.rb, the Parser uses the coreExtension>io.takari.polyglot:polyglot-ruby classloader. When executing the mojos, the Thread context classloader is the plugin>io.takari.polyglot:polyglot-maven-plugin classloader with custom dependencies added, but JRuby still uses the "coreExtension" classloader.

Ruby execute blocks should pick up dependencies added:

# ...
plugin!('io.takari.polyglot:polyglot-maven-plugin', VERSIONS[:polyglot_version]) do
    dependency( 'org.apache.maven.shared', 'maven-dependency-tree', '3.2.1')
end

execute :install_gems, :'initialize' do |ctx|
    org.apache.maven.shared.dependency.graph.DependencyGraphBuilder # => Exception!
end
# ...

As execute blocks in languages (specifically Ruby that I'm interested in) can't declare java @Component annotations to access other maven plugins, this feature would allow a target language to use a new method on the ExecutionContex to retreive instances from the IoC container.

Would need a bit of polish, but I'm gauging interest before I spend time finishing this.

The docs for polyglot-kotlin still mention the Kotlin issue KT-27956, but this issue and the follow-up KT-33892 are marked as fixed since Kotlin 1.3.60.

Is the performance impact still present?