On Feb 20, 2010, at 1:51 AM, tbee wrote: > > > > jvanzyl wrote: >> >> Sure, if you're dealing with a single module there's no benefit of >> inheritance. If you really find you want goals of certain plugins to be >> executed automatically then yes, you make a custom packaging and make it >> transparent by referring to the packaging. This is all with Maven 2.x. >> With Maven 3.x this will be easier with mixins and we can learn from our >> experiences with Maven 2.x. >> > > The reason why I'm back at Maven, is 3.0. I made a round trip in the last > few months; we have Ant, so I started with Maven 2, then fell back on Ivy, > really made an effort with Gradle (but it was lacking in documentation) and > after a few other tools I examined, I'm back at Maven 3.0. This time I > included setting up a Nexus repository to get the "whole experience". >
Repository manager or not isn't going to change the experience, Maven 3.0 is meant to be fully backward compatible while making the way for new features post 3.0. Polyglot Maven with Groovy, Ruby, Clojure and Scala support is experimental at best. > Unfortunately I'm not experiencing much difference between 2.0 and 3.0; I > tried to use to Groovy style, because it combines easy custom actions with > the standard phases, but there is no documentation (yet) on how to invoke > maven. So I went for the basic pom.xml, but run in the same issues that I > would have with 2.0. > > All in all Maven 2 is simply too complex; there is enough feedback on that > by people with higher profiles than me, so no need to add. Most people we deal don't actually find that, it's usually not understand the tool and the impatient find it easier to roll their own solution. > Concept is good, > implementation is lacking. > You'll find that implementing something yourself is just as difficult and Ant makes this no easier for a general solution. For a one off where not too much worried with the interaction with the outside, don't have to worry about resource staff and want to rewrite everything yourself then Maven is not for you. We've used it on multi-million line builds with 10s and 100s of developers and Maven works just fine. Then if you want integration with Hudson, or Eclipse, or leverage any of the other 3rd party tooling you're just going to end up rewriting that as well. So you can complain about what specifically doesn't work for you, or contribute to fixing something that a lot of people use. I think you'll find that anything used by as many people as Maven so for many things is going to be lacking. The build is not an appendage to your application, it's requires as much discipline as anything else. Any large company Sonatype has dealt with does the analysis. Any good engineer can roll a build system that works in the short term, the companies we deal with know this. So there is really not much difference in cost in the very short term. Try and get an IDE setup, the CI system, a reporting system, manage your artifact, a complicated J2EE system, an OSGi application, an Eclipse plugin and then you're into a serious amount of engineering. That's just the nature of infrastructure. That's certainly not to say we've been complacent, we have thousands of many hours in Maven 3, but the first priority is backward compatibility with an eye to the future. So there aren't many flashy changes in 3.0, the interesting changes from a user perspective will come post 3.0. So you can either help fix the lacking implementation, or roll something no one else in the world is going to understand. And when you get tired of maintaining, which is often the case, then you leave your organization at risk being the only one who really knows how it works along with all the other bits and pieces you've made which have. There will never be standard Ant builds, if you leave the avenue to vary it will vary. Look at 100 Ant builds and they all look the different, work different, and behave different. Fine for one offs, but not what large organizations are looking for. But in the end, to each their own. > > jvanzyl wrote: >> >> Most of us are aware of the problems you're facing and we'll fix a lot of >> that with Maven 3.x. But in the meantime we can't radically change things >> without harming a lot of users. Maven 3.x is almost 100% backward >> compatible but will allow users to try out new features incrementally >> (that is a lot harder then it sounds). >> > > I understand completely. I had a pretty large piece of text here, but let's > summarize that with the statement that I totally agree with Kirill (author > of the Substance look and feel) on this point: on any major version release > you have to restructure so that the new version matches what is believed to > be the best implementation of the problem at that time, even if this means > breaking API compatibility. But there is nothing wrong with shipping a 2.0 > parser that mimicks the 2.0 onto the 3.0 API. > > At the moment, after trying all these build systems intensly, I'm wondering > if I need to introduce MAVANT; maven build cycle where ANT tasks are > attached to the phases, using Ivy for reference resolving. But that sounds > an awful lot like Gradle. > > First see what Maven 3 will bring. Is there any documentation aside the > teaser articles, on how to use the new features? > -- > View this message in context: > http://old.nabble.com/custom-maven-plugin-default-phase-tp27626122p27664065.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ----------------------------------------------------------
