This proposal is a collection of features and changes that I think are necessary for Maven to not suck. Obviously, not sucking is a completely subjective goal so it is defined as making Maven do what Don Brown thinks it should do. I've created a branch in the Maven sandbox to collect my changes and facilitate any collaboration. I'll be converting any new features or changes into Maven JIRA issues to encourage the code to get back into the Maven project, however it is anticipated that many changes will be rejected as they may go against the official Maven direction.
The deliverable from this proposal is a set of sandbox "releases" or versioned snapshots that I will be using in my open source and commercial work, however, I hope other people will find them useful. I'll be making the changes on the latest released version of Maven to ensure stability.
Features
| Feature | Issue | Accepted | Rejected | -db version |
|---|---|---|---|---|
| HTTP Wagon to use standalone HTTPClient | WAGONHTTP-17 | 2.0.9-SNAPSHOT-db1 | ||
| Parallel artifact retreival | MNG-3379 | 2.0.9-SNAPSHOT-db1 | ||
| Specify plugin versions in super POM | NabbleMNG-3395 | |
2.0.8-db1 |
Changelog
| Version | Date | Description |
|---|---|---|
| 2.0.8-db1 | 3 Feb | Plugin versions in super pom, full release, went back to 2.0.8 for stability |
| 2.0.9-SNAPSHOT-db1 | 29 Jan | Only uber jar, Java 1.4 compliant, no Commons Logging issues |
How to install it
Uniquely versioned snapshots can be found here:
Download the release file that best suites your environment and install it like any normal Maven installation.
How to develop it
- Checkout the code
svn co http://svn.apache.org/repos/asf/maven/sandbox/branches/maven/maven-db/ - Install the standalone version of httpclient in your local Maven repository:
cd maven-db mvn install:install-file -DgroupId=commons-httpclient -DartifactId=commons-httpclient -Dversion=3.1-standalone -Dpackaging=jar -Dfile=commons-httpclient-3.1-standalone.jar
- Install the wagon http
cd wagon-http-trunk mvn install
- Build Maven
cd ../maven-2.0.8 mvn install
You should now have built the release available in the maven-2.0.8/maven-core/target directory.
Comments (6)
Feb 02, 2008
Samuel Le Berrigaud says:
Hey Don, I see that the feature Specify plugin versions in super POM has been r...Hey Don,
I see that the feature Specify plugin versions in super POM has been rejected by the maven guys already. Is there not a way to make it happen though.
I mean there is a need to be able to define a set of plugin versions to be used with a given maven version. I know the maven guys are working on a plugin registry for maven 2.1. Maybe specifying the versions in the super POM is not what they want and we could come up with another solution – that they would agree with – solving the same issue?
What do you think?
Feb 03, 2008
Antony Stubbs says:
Hi Don, Couldn't find a way to contact you on your blog. Regarding evolving sch...Hi Don,
Couldn't find a way to contact you on your blog.
Regarding evolving schemas - I wanted Liquibase.
Feb 06, 2008
Nathan Voxland says:
Note that there is a liquibase maven pluginnow available.Note that there is a liquibase maven pluginnow available.
Feb 14, 2008
Ben Tatham says:
As per the Specify plugin versions in super POM feature, our company has o...As per the Specify plugin versions in super POM feature, our company has our own common-pom that is the parent of all our projects anyway. I think this is likely a better place for plugin versions. It makes it easier for us as a company to decide when to upgrade to the latest and greatest, and not have to wait or override the Maven Super-POM. I do think its a great idea to specify them though. You made an argument that it makes the pom ugly. True enough. But if its all in the company super-pom, its all good. The problem with it being in the super pom is that the company cannot decide it does want to auto-update plugins -- Unless maven provides a new feature to override a hard-coded version with nothing, in which case we could override the super pom plugin version with <version>auto</version, or something like that.
What would be great, as a replacement for a worldwide super pom freeze, would be a tool to tell you the current versions (dependency:resolve-plugins), but also tell you what the latest version is in the maven repo, so you can know if you what there is to upgrade to, and then look into it. And additionally, and auto-updater...If I want the latest and greatest, but hard coded as of now, the plugin would edit the pom and put the latest versions in. It could also be used to generate the parent pom as well...get the latest and greatest and freeze it in a pom, based on all the plugins the dependency:resolve plugins tells you.
I have our own internal plugin that updates poms of depdending projects whenever a project is released, in our SVN trunk (we use the branching style where the trunk is also buildable -- and this way CI will tell us when a library change needs to be refactored into another project). Perhaps I can modify that plugin to do this new feature and give it back to the world.
Feb 15, 2008
Brian Fox says:
The plugin versions in the super pom is being discussed and will most likely be ...The plugin versions in the super pom is being discussed and will most likely be introduced with 2.0.9
Feb 19, 2008
Michael Descher says:
I just built your Maven branch and had some difficulties first. The "mavenVersio...I just built your Maven branch and had some difficulties first. The "mavenVersion" property is set to 2.0.8 in the topmost pom.xml file. This results in 2.0.8 dependencies being used instead of the 2.0.8-db1 ones being built. Setting it to 2.0.8-db1 made it work. Is this a bug or done intentionally and I missed something? Also the version in the pom.xml of "maven-plugin-registry" is set to 2.0.8 instead of being taken from the parent pom. Again, a bug or done intentionally?
Michael