What happened to the Maven Polyglot project that used to be at http://polyglot.sonatype.org/?
As described in this article,
One exciting new feature in Maven 3 is it's ability to work with pom files written in non-XML notations. The Maven core now provides an underlying DSL to access the Maven internals, and write POM files in the language of your choice. This currently includes scripting languages like Groovy, Ruby, and others. In short, you will be able to write a DSL for virtually any scripting language you like that can hook into the Maven internals and pilot the Maven build process.
There are several additional articles on the web that I've found referencing the feature.
http://www.thinkplexx.com/learn/article/maven-learn-material/maven3/maven3-pom-using-groovy-ruby-scala-yaml-sonatype-polyglot
http://mattgivney.blogspot.com/2011/05/maven-3-polyglot-support.html
But the polyglot site now redirects to sonatype.org and I can find no mention of this feature in the Maven 3 release notes.
So what happened? Was it cut or is it in there and just not documented in the release notes? If it did make the cut for Maven 3 could you point to some documentation. I am also interested in the translator tool mentioned by the first article I linked to.
This project is now named tesla-polyglot. I've just completed the Scala DSL for it, and tesla-polyglot should be released very soon now. We're just waiting on Maven 3.1.1 to roll out of the door.
There has been an update on the maven users list from Jason van Zyl: http://maven.40175.n5.nabble.com/What-happened-to-Polyglot-Maven-td5715529.html
I'm still working on it along with a few others. Dhanji has the Atom markup working, Kristian has implemented a Ruby DSL, and Jason Dillon has implemented a Groovy DSL which creates synthetic plugins to bind arbitrary scripting to Maven's lifecycle. My original was to see how Maven's infrastructure could be leveraged by other markups and DSLs. These examples do render to an interoperable format insofar as consumers go. Maven itself obviously cannot run a Ruby DSL but if you like the Ruby DSL you can use it to build an not affect consumers: you can build and deploy to a Maven repository and someone else can consume the dependency with stock Maven.
I have all the early adopters I can deal with one-on-one right now, because I can't deal with many really, but if you have more than a passing interest feel free to email me privately.
looks like it is still alive :-)
You won't believe it, but it's released (if you can call a 0.1 version a release).
As of April 2016,
the home page is https://github.com/takari/polyglot-maven ,
the latest release is 0.1.15
There is Polyglot Maven IDE Pack for Eclipse, that includes some plugins.
There is also maven-tiles project https://github.com/repaint-io/maven-tiles ,
and quick trying out what Maven flavor works well shows that Groovy does better than others.
Be aware of Babylon Tower problem, so it is actually better when most of developers use the same flavor.
The latest info comes from here
"Polyglot for Maven is still moving along and we've seen a lot of activity recently on the Ruby DSL by Cristian Meier from the JRuby team, and the Scala DSL by Chris Hunt from Typesafe. We hope that this initial work can serve as inspiration for helping the POM evolve. For those interested in what the XML alternatives can look like you can take a look at the existing implementations:
Ruby DSL
Groovy DSL
Scala DSL
YAML
Atom"
Related
As I am new to learn either maven or Gradle build tools. Therefore I wonder which one I select to study between maven and Gradle and which one has more requirement and demand in the industry. I want to use these build tools for Spring and Hibernate based projects. Any suggestion would be very helpful.
Thanks
Before this is closed for "not being a good question", I'll get some comments in.
You might want to learn the same thing that most other developers want to learn. Look at the third slide of the following slideware, which shows the results of Zeroturnaround's yearly developer survey. For this set of >2k developers, when asked what technologies they were interested in learning, Gradle was at the top of the list.
You can use either Maven or Gradle to build projects using Spring or Hibernate, but it's useful to point out that both the Spring and Hibernate code bases (not necessarily the applications using them) use Gradle to build their deliverables.
Maven provided the best build solution for quite a few years, but it's difficult to customize a build, and most Maven build scripts are very "noisy". Gradle solves those problems, while providing a smooth migration path from Maven or even Ant.
I am investigating possible frameworks for the future web-app I am tasked of building and Play framework 2.3 is pretty much sitting atop the list - however, I haven't used it until now (had used Spring and Maven in another life) and I have a particular requirement on the app itself so I wanted to hear advice/thoughts from people who have used Play so far (the language used will be Java 8).
The web-app consists of modules, some of which are stand-alone units that should be built as a jars (so that they can be accessed from command-line as a part of, say, batch script) as well as being built to function within the full-blown web-app.
Now, I've previously built apps with maven and I could imagine a way to do it with it but Play comes with its own build/dependency management tool (SBT) which I am unfamiliar with and don't know the capabilities of (is this even possible to achieve with SBT? How difficult would it be?).
That being said, I have done some cursory research on the subject and I know there is play2-maven-plugin, however the examples on the homepage deal with Scala (which I, as said above, unfortunately can't use).
What's certain is that I'd definitely like to escape from any "bridging" between SBT and maven - I wouldn't want to maintain two build systems and reconcile the differences between them together, that seems nightmarish.
Lastly, I've found in this SO thread, using maven with Play 2.3 may not even be an option (SBT apparently does somehow use Maven dependencies under the hood). After all, Play was conceived as partial departure from Java EE practices so it doesn't surprise me Maven is not natively supported. Also, Play integration with Maven proved to be troublesome.
I have no objection towards learning SBT or using just maven (if that's possible/advisable) - any of these approaches I am fine with, it's just the capabilities of SBT I am unfamiliar with (especially considering the requirement from above). Mixing SBT and maven seems frankly a bit scary and documentation on building Play with SBT seems scarce at this point.
Should I go with SBT or maven? What tutorials/docs would you recommend? Should I use Activator for getting to know SBT?
NOTE I was almost to flag the question as unclear what you're asking, but at the very end of it found the real questions I'm going to answer here.
Should I go with SBT or maven?
SBT or even better Typesafe Activator. Install it on your computer, and execute activator new myNewCoolPlayJava8App play-java to get started with Play and Java.
Apache Maven might be a viable option, but don't think it's going to be a time-saver (you'll be spending quite some time to get the configuration working).
What tutorials/docs would you recommend?
The official web site of Play Framework is enough to get started with the stack (and don't get stuck) - https://www.playframework.com/documentation. I very often use it and found it very informative. When I need a bit more in-depth information I use Google or StackOverflow (under playframework).
Should I use Activator for getting to know SBT?
No. SBT can live without Activator, but no vice versa. SBT's the foundation for Activator. See https://www.playframework.com/documentation/2.3.x/Build:
The Play build system uses sbt, a high-performance integrated build
for Scala and Java projects. Using sbt as our build tool brings
certain requirements to play which are explained on this page.
And from the Activator's docs (just at the very bottom of the page):
Activator applications use sbt under the covers. This means that
anything you can do in sbt you can do with an application in
Activator. For instance, sbt plugins can easily be added to
applications in Activator just like they would normally be added.
I am investigating the use of Maven 3's support for Groovy poms to aid the build process within my team.
From my initial readings, I can only find articles from 2 years ago mentioning it as a feature, although not part of core Maven.
Link to Polyglot Maven seem to redirect to the Sonatype homepage.
I have read the answer to this related question, I don't fully understand what it means.
Does this mean that Maven 3 supports the generation of Groovy poms or not? Would appreciate it someone could explain in simple terms as to what this means.
Thanks
It looks like Jason van Zyl, who is the founder of the Maven project and the CTO of Sonatype, is working on it, in sort of a private beta. It is not a part of the released version of Maven 3.
See this email from Jason
What's the problem with the build process? Do you need groovy poms to get it into your team? pom.xml files will usually not written by hand. You should IDE's for that purpose. Maven 3 does not support of Groovy pom's.
I'm a bit surprised at the sheer number of articles / blogs / questions / answers about Clojure mentioning Maven.
In about ten years working as a Java dev, working on both desktop apps and webapps, I've never ever used Maven once (typically --and that's a personal opinion but I know some people do think the same-- the projects I've seen using Maven where including the "kitchen sink" whereas the ones built with a more "controlled" build process where way "cleaner" and producing smaller jars, faster build time, etc.).
Is Maven a requirement when you want to build a Clojure app?
Is Maven mandatory when you want to use Leiningen? For example, can I add external jars as dependencies to a leiningen project "manually", without needing Maven?
I think my question boils down to this: can you, in the Clojure/JVM world get away without ever using Maven, just like you can build, test, package and ship both Java desktop, webapps and Android apps without ever needing Maven?
Short answer: No. Clojure's just a jar and you can use it as "raw" as you like, just like any other Java library.
Longer answer: Maven's not a requirement, but the tooling around Clojure, especially Leiningen, is highly Maven-aligned so your life will be easier if you just submit to Maven's will. But, with a little work, it's not that hard to get along without Maven. At work, I use a mix of Leiningen and our existing Ant/Ivy-based build infrastructure. I use Ant to resolve dependencies (from our curated internal repo) and then use a hack of Leiningen's :resource-paths to get it to pick up the non-Maven jars. At some point I'll make a true plugin to do this stuff, but it's been working fine for me so far.
Also, if you're an Eclipse person and use CounterClockwise, you can treat your project like any other Java project in Eclipse, managing the classpath manually. It just happens that you've got some Clojure code in there as well.
Of course, the drawback in either approach is that if you want to grab something that's available from either Maven central or Clojars, you'll either have to set up some kind of mirror for your infrastructure, or manually pull down the transitive dependencies and add them to your project.
You do not have to use maven, or leiningen, for that matter. You can run the clojure REPL with
java -jar clojure-1.3.0.jar
and it will work just fine. I know where you're coming from, because a year ago, I was in the same boat as you. never used maven, seen a couple of less than great projects that used it poorly, and generally distrusted maven. Ant+ivy works great, who needs maven?
As a result of using leiningen, and starting a new job where we have a very well setup maven config, I've changed my tune completely; I now think maven is great, and far prefer it to ant, which I've used for a long time.
Specifically with clojure, some advantages of leiningen are:
automagic project scaffolding: "lein new" sets up a new project for you. convention is important, it helps other developers understand your project and quickly ramp up on it.
dependency and plugin management. adding a dependency is trivial, and there isn't a great way that I am aware of to do non-maven dependency management that is tightly integrated with clojure.
"lein repl" sets up your classpath and everything correctly, so you don't have to fool with it, you can just start and run a REPL.
artifact creation: building a fat jar (lein uberjar) is straightforward, and already set up for you.
So, while it's definitely possible to use clojure without leiningen, I honestly don't see why you would want to. There are too many niceities for day to day development not to use it, in my opinion.
regarding "Is Maven mandatory when you want to use Leiningen?"
leiningen uses and wraps Maven so you can't truly avoid it, though you don't ever need to touch any XML
Maven is not mandatory for Clojure as others have rightly pointed out.
However, I would like to encourage you to embrace Maven (either directly or via leiningen). It has some big advantages in the Clojure world:
You will be more productive in the long run - once you've got it set up, it is pretty impressive to see a complex build, test and deployment execute in a single command. Do you really want to be manually setting classpaths, downloading dependencies, incrementing version numbers, uploading to FTP sites etc.?
One of the biggest advantages of using Clojure on the JVM is access to the Java library ecosystem. Maven is the tool of choice for automatically managing dependencies on Java libraries. Nearly everything you are likely to need will be in either the Maven Central or Clojars repositories.
Clojure tends to have small focused libraries - this is good because they are "simple" and you can pick and choose the functionality you like. At the same time, it also means that you are likely to have numerically more library dependencies. Hence a build management system is going to be more useful.
You can make Maven builds as "lean" as you like. Obviously you can pull in every dependency under the sun if you like, but you can also create very lean jars by excluding the unnecessary cruft. That's your choice.
It is the de-facto standard in the Clojure world. If nothing else, using it means that you will be able to collaborate with others more easily.
P.S. Like you, I didn't really see the point of Maven 5 years ago. Then I gave it a go and saw how powerful it could be for my workflow. Now I'm a convert :-)
I recently asked about a maven like tool for other languages but there hasn't been any responses (except for a few upvotes :). Given that, I've decided that maybe using Maven is good, but I'd have to write my own plugins to do simple things
This gives rise to a number of issues, and I'd like to hear about solutions that people are using in their daily process:
running other build/release systems and mostly use Maven for packaging/dependency management? (msbuild, vcbuild, cmake, setuptools)
working directly with other languages:
The native-archive-plugin supports C/C++, but does it integrate with visual studio?
Are there other plugins for more langugages, that I've missed?
how hard is it to write your own plugin for this?
Question:
What is your recommended approach for managing non-Java languages and artefacts with Maven?
I'm currenctly using maven-scala-plugin and it work just great. I only put my sources to src/main/scala instead of java and bind scala:compile goal to compile phase and that's it. But scala is very close to java, so the issues with c++ might arise.