I was trying to figure out how mixins are defined in Maven 3, but couldn't find anything other than buzz. It is propagated as one of the big new features here and here. I am currently feeling the pain of the hierarchical structure and would like to give it a spin. Does anyone have a pointer to documentation or the source defining the syntax even?
In a comment to this answer, Brett Porter wrote:
Maven 3.0 doesn't offer mixins yet, however. – Brett Porter Feb 16 at 8:18
And AFAIK, mixins still aren't there.
Jesse Glick pointed to Maven issue 5102, so I just wanted to mention that the most recent comment there (2 Oct 2012) links to a new maven plugin that offers mixin behavior: maven-tiles. This seems to be the best option until mixin support is actually baked into Maven (something that has been delayed for several years now).
Edit 2015-Jan: tknerr pointed out that this issue has been flagged for review for Maven 4 inclusion. The Maven devs seem to believe that POM format changes are required to support this feature correctly. (As a long-time Maven user, I'm not surprised by this.)
You can use open-source plugins to introduce mixin into your pom.
There are several plugins which tackle the hierarchy complexity in form of mixin.
One of them is designed to solved the hierarchy in plugin / plugin management section.
It reads all the imported POM files and merge them to the POM file in the same manner Maven calculates the effective-pom. The plugin merges only the build, properties and profiles sections and does not merge any other elements of the pom such as dependencies, repositories, etc…
In the below snippet, the artifact sample-mixin will consume the plugin management configuration as defined in the sample-mixin pom file. No need to inherit any parent /base pom for this..
<plugin>
<groupId>com.github.odavid.maven.plugins</groupId>
<artifactId>mixin-maven-plugin</artifactId>
<version>0.1-alpha-23</version>
<extensions>true</extensions>
<configuration>
<mixins>
<mixin>
<groupId>mixin-example</groupId>
<artifactId>sample-mixin</artifactId>
<version>${project.version}</version>
</mixin>
</mixins>
</configuration>
</plugin>
For further reading, check it out:
http://rethinkingswd.blogspot.co.il/2014/09/mixin-maven-plugin-reusable-project.html
Mixins are currently scheduled for Maven 3.2 as bug MNG-5102. They are among many highly voted bugs that have not been addressed in the candidate Maven 3.1.
So much for "Paving the desire lines".
Related
I understand that the maven-compiler plugin is used to compile the code. Some of my project does not have that plugin in the pom file? When is it required?
I am trying to answer my own question based on what I learned since posted this question. If this answer is correct or incorrect please comment. Thanks.
If this plugin is not defined, the Maven Super POM contains all the default plugins you will be using. It works fine for small and non-serious projects. However, the best practice is to define these plugins in a company-wise POM and so that when you upgrade maven, you would not end up using a different version of plugin.
Have a look at the Goals Overview Section in Apache Maven Compiler Plugin
The Compiler Plugin has two goals. Both are already bound to their proper phases within the Maven Lifecycle and are therefore, automatically executed during their respective phases.
You only have to add it if you want to change the default parameters
It's a long story. My current place uses Ant for builds. They create about 20 different foundation class jars that are used in multiple projects. Originally, the projects would check in the particular versions of the various jars they needed and then never updated them. That meant that each application had incompatible jars with other projects and our servers. Hilarity ensued.
To handle this, I immediately brought in a Maven repository, and integrated Ivy into our Ant builds. No more checking in jars. Instead, you fetch the correct version from the Maven repository. Originally, I expected the developers to keep the version numbers in the ivy.xml up to date, but they never did. Instead, the Ivy integration and setup depends upon an external Subversion project. This allowed me to integrate Ivy with minimal changes to the old build.xml files. I added a ivy.version.properties file to that external ivy project and maintain the version numbers of various jars in there. There's a corporate wide version number.
The various projects use the ${corporate.version} property for our foundation jars version numbers. When I update that ivy.version.properties file, all projects get updated with the right version number for our foundation classes. We use <ivy:makepom> to generate a pom.xml for our projects and use this to deploy our jars and wars into our Maven repository.
The result: I no longer have to worry about the developers keeping the version numbers of their projects in sync. I, as the release engineer handle that by updating that one ivy.version.properties file. All projects are in sync.
Now, we're moving to Maven, and I want to be able to do the same thing. I doubt developers will remember to update their pom.xml with the correct version numbers, so I want to read that in from another file, and use that.
There are two issues: One is that Maven first reads in the version number of a project before it executes any goal. No version number in the pom.xml, no version number for the generated jar.
Even if I manage to get by that first step, we have the fact that the pom.xml has no version number in it for foundation classes. When Maven pulls down the pom.xml to get the dependencies, it can't figure out which revision.
Yes, I could put that into a corporate pom.xml and have that as a parent project for all of the other projects. We already have a parent project to help set up various aspect of all projects. I could put a foundation class version number in there. However, that means that the developers now have to update the parent project's version number with each release. If developers can't be trusted to update the version number of their project with each release, what makes you think they'll do that with the parent's version for each release?
I know other people must have run into a similar issue. How do you handle this?
I could have an Ant script that generates the pom.xml from a template pom.xml, but that seems a bit silly.
I was wondering if is it possible for Maven to generate a pom.xml on the fly and then to use that to continue the executing the right goal. For example, I type in mvn package, and Maven will take a template.pom.xml file, fill in the missing version numbers to generate a generated.pom.xml file, then execute mvn package on that generated pom.
Or, is there a better way to solve this issue? Basically, I need to control the version number of our releases across all projects. This way, all projects are using the same version of our foundation classes. Also, I control some other versions of other jars (like log4j) this way. I've done this with Ant and Ivy, and now I want to move to Maven.
I think the best option is to create a pom.xml with all the dependencies to your packages in its and then import it in your developer project paren pom.xml using import
So, in the project parent POM:
<properties>
<corporate.version>...</corporate.version>
<properties>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.mycompany.libs</groupId>
<artifactId>foundation<artifactId>
<version>${corporate.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
...
</dependencies>
</dependencyManagement>
So for new set of foundation libraries, you deploy a new pom.xml with all the versions in it and update the ${corporate.version} in the relevant parent pom.xml file. You can even have when the versions are not yet fixed define a -SNAPSHOT artifact with these version numbers.
for more information, see: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies
We actually have the same kind of problem and I know that there is trade-off between "lazy programmers" who never update their poms and the stability aspect: Changing the versions of the foundation jars "suddenly" which may cause unexpected build fails.
If you really want the behaviour you describe, I would put the desired dependencies into a SNAPSHOT pom and use it either as a parent pom or import it as a BOM. In this way, you can change the content and everybody pulls in the new content with the next update.
I've decided that this a stupid idea and should never have been done. It's the developers' responsibility to update their own damn POM and make sure they're pulling the correct version. This is the way it really should be and developers should simply learn to do it (what's the technical term? ...oh yeah) the Correct Way.
I originally implemented this because the company had something like this (which wasn't working) and I had problems getting the developers to do what should be their job. And, the developers liked it because I was now officially responsible when something goes wrong rather than them. It's what you get when you do someone else's job.
I've convinced the company to stop trying to keep all our core jars (the jars used in our other projects) and our releases at the same version number. Instead, every project will have its own versioning. Jars will version only when there's an actual change and not when we force an upgrade to the version. And, the developers must know what versions of the various jars they depend upon.
Use the maven-release-plugin. This plugin can stamp a version number on all pom.xml files. The plugin also understands version control and knows how to tag a maven project for release (or branching).
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.
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"
Spring Roo can be use in existing projects that follow standard maven layout.
So far this appears to mean that projects that doesn't use maven are out of luck.
I am wondering what (if any) are the options for such existing projects.
Re-arrange the project layout to conform to Maven layout? This appears to be very difficult path for projects with years of history in CVS due to the fact that method for moving around directories in CVS is extremely invasive.
Are there any other options like modifying Maven configuration to work with non-standard layouts? What I recall from my earlier reading about this subject, Maven's CoC approach doesn't favor such non-standard layouts.
Edit:
Rich's answer below shows that over-riding the defaults in super-pom is trivial. That leaves us with the question whether Spring Roo will play nicely with such modifications. This is doubtful given the fact the Spring Roo doesn't use Maven itself.
Edit:
Rich's updated answer shows that, by default, ROO will use hard coded paths and will not pick modifications in your pom.xml
So answer so far appears to be that it isn't possible out-of-the-box but can be done by some custom coding (or asking ROO team to support this)
There's no reason we (the Roo team) cannot make the MavenPathResolver allow custom paths to be used, and one of the intentional reasons I created a PathResolver abstraction was to support customisation of common path locations not only to Maven non-default locations but also to other build systems like Ant+Ivy. all base Roo add-ons have been written to use the PathResolver so it shouldn't be a major effort to support this. Please add an enhancement request to the Roo Jira instance if you'd still like this support.
You can modify Maven to use a different set of conventions. The standard set are inherited from the Maven super POM and can be overridden by redefining the relevant property.
For example, to change the sources directory from src/main/java to src, the test directory to test-src, and the resources directory from src/main/resources to resources you would set the following in your POM:
<build>
<sourceDirectory>src</sourceDirectory>
<testSourceDirectory>test-src</testSourceDirectory>
<resources>
<resource>
<directory>resources</directory>
</resource>
</resources>
</build>
Be aware that a few plugins might not use the standard properties to access the locations (e.g. hardcoding target/classes instead of using ${project.build.outputDirectory}, so you might have the odd problem.
Update: It looks like Roo currently has these properties hardcoded. You may be able to replace the MavenPathResolver or add an additional resolver to use the custom properties.
If this is a real problem for you, you can raise a request to get the MavenPathResolver modified to allow custom locations.
As of Roo 1.2 it is not implemented.