Babylon Tower problem, was: [feature request] multi-lingual in one file (in-lining or embedding?)

[paulvi]

Having many ways/language for doing the same may be attractive for some user groups, however it creates Babylon Tower problem when an example does not feat, because it was created for other language (sometimes with incompatible features).

Please consider way to incorporate e.g. XML parts into YAML or add YAML(groovy, scala, etc) into XML

https://en.wikipedia.org/wiki/Tower_of_Babel

[mkristian]

I guess I do not really understand the need.

let me look at a ruby pom.rb https://github.com/jruby/jruby/blob/master/lib/pom.rb with lot's of ruby in it. when this file gets "interpreted" it sets up a java POM which will be handed over to maven. where exactly shall the scala part come into such ruby file ? or groovy part ?

currently you can "translate" pom.xml into pom.rb or pom.scala or pom.yaml - what is the missing part ? if some of that translation does not work than it is a bug.

do you have an example what you mean ? do you have a concreate use-case which demonstrate the need of your request ?

[paulvi]

The idea is that once there are many languages to write code, there is new headache to translate between them.

Could lazy people just mix inline?

or e.g. take pom.xml and inline some ruby or scala,.... or

example

default_gems =
  [
   ImportedGem.new( 'jruby-openssl', '0.9.5.dev-SNAPSHOT', true ),
   ImportedGem.new( 'jruby-readline', '1.0.dev-SNAPSHOT', false ),
   ImportedGem.new( 'jruby-ripper', '2.1.0.dev-SNAPSHOT', false, '2.1' ),
   ImportedGem.new( 'rake', 'rake.version', true ),
   ImportedGem.new( 'rdoc', 'rdoc.version', true, '2.1' ),
   ImportedGem.new( 'json', 'json.version', true, '2.1' ),
   ImportedGem.new( 'krypt', 'krypt.version', true ),
   ImportedGem.new( 'krypt-core', 'krypt.version', true ),
   ImportedGem.new( 'krypt-provider-jdk', 'krypt.version', true ),
   ImportedGem.new( 'bouncy-castle-java', 'bc.version', true )
  ]

inline_xml = 
  <dependencies>
    <dependency>
      <groupId>com.google.inject</groupId>
      <artifactId>guice</artifactId>
      <version>3.0</version>
    </dependency>
    <dependency>
      <groupId>org.eclipse.sisu</groupId>
      <artifactId>org.eclipse.sisu.inject</artifactId>
      <version>0.1.0</version>
    </dependency>
  </dependencies>

[huntc]

I can tell you that people choose build systems based on the language their project build file uses. Scala uses sbt, groovy uses Gradle, js uses grunt... of course that is generalising things, but you get my point.

On 16 Apr 2014, at 12:33 pm, Paul Verest notifications@github.com wrote:

I think the best use case is when pom.xml can contain some active code

— Reply to this email directly or view it on GitHub.

[huntc]

Translation isn't seen as a common use case either. It is there primarily to translate XML into another target. Also, at the end of the day, the common denominator is the maven model. Everything translates to that.

I don't see any issue here.

[paulvi]

That is right, in the end it is just Java maven model.

Now as a developers I am looking how to solve some configuration problem. I use XML, but the example I have found is using Ruby, that I cannot use direct and needs to spend 5-30 minutes to translate and possibly fail with that.

So if you just add more languages to express maven model, you are creating Babylon Tower problem: a lot of people speaking many language that cannot work together to achieve one goal.

[paulvi]

from #16

But you were arguing for less languages on another issue, not more...

That was warning what result actually multi languages support can have.
The main idea is multi-lingual in one file, this issue was renamed to reflect that.

So it is about in-lining or embedding instead of translation. Of course it does not make sense for all combinations. XML and YAML seem to be candidates.

[mkristian]

@PaulVI if you have a concrete problem with the ruby DSL please file an issue. to add XML to the configuration of an plugin is already there but could need improvements. to allow YAML or JSON instead of XML could be an option for those configurations.

[jvanzyl]

I honestly don't think this is a good idea.

[paulvi]

OK, the idea lives in maven-tiles https://github.com/repaint-io/maven-tiles

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