Ugh, what a long thread to wake up to when you've got a headache :) I think there have been some very good answers here already, but I'll add my own thoughts for completeness.
On 9/20/05, Ashley Williams <[EMAIL PROTECTED]> wrote: > > Sincere apologies to the dev team if this email seems like a troll, I > absolutely don't mean it to be. I'm aware that they continue to do > outstanding work and are few in number. Thanks, much appreciated. Constructive criticism is always welcome :) 1. Usability from Ant - there are hundreds of Ant targets out there > that are useful for me today. I can't justify waiting for them to be > rewritten as Maven equivalents not only because I need functionality > today, but also because I don't see why I have to abandon my > experience with ant. So far we've only addressed usability OF Ant. You can run ant scripts at phases of the lifecycle using antrun, you can write java plugins that use the Ant API, and Chris and John are putting together Ant plugins. You can already sort of do this with Marmalade (at least that was the intent). The key is that you still get the reusable infrastructure that Maven provides which is what we view as the most important feature of Maven (yes, its not dependency management!) Funnily enough, before I logged in this morning, I was pondering starting the long overdue discussion with the Ant team on how we can best work together to move forward. Ant and Maven are completely different applications, but they could share a lot of code at the task/plugin level. As Jason said, we've been working to do this in the form of common libraries as they are also usable outside of both Ant and Maven, and it'd be good to get a shared direction happening there. Using Maven from Ant? I'm not sure if that is what you meant, but that would be possible too and there is an open JIRA. So far, just dependency management is available. 2. Usability from Eclipse - when will I be able to ditch the command > line and create and manage projects entirely from eclipse I'm really surprised this is #2, but as others have pointed out its high on our list too. But we need to finish Maven first, then work on integration. 3. Need to do a myriad of simple things such as automatically run > java command or deploy to tomcat. I used to do this all the time in > my ant scripts, ie run my build.xml script and at the end it would > run my app on completion. It's a credit to those on this list who > reply with ideas and workarounds - however this is kind of related to > 2 above, where there are lots of ant tasks out there that are tested > to death and that I should be able to use today. Are you sure they are tested to death? :) But as stated in 1), you should be able to do this just fine. The important thing is that you are encouraged to spend the small amount of time making it reusable for other projects of your own, and hopefully if something comprehensive is put together then it is shared with all Maven users. 4. Online documentation. Simple example was trying to get the > assembly plugin to work which Daniel Shomer had to look into the > source code to advise me of what to do. This is just one example of > many. Yep, we're working on it. I don't think the emphasis should be on javadocs (With the exception of the plugins, where that is what generates the plugin reference). Short howtos are the approach we are taking for the Maven doco itself. Contributions are welcome, there is a wanted list on the web site. 5. Other project structures. Sometimes I will encounter a project > where all the source code is in one tree (beginning with com/). I'm > not saying its any better than one directory per artifact, but I am > saying I encounter such projects in my career and as such I know I > wouldn't be able to use maven. Oh well, its not a silver bullet. There are probably a lot of other things you can't do with that structured project, and maybe you don't need to. If at some point the benefits of restructuring and using Maven outweigh the costs, then go for it - in the mean time, use whatever is already there. There's no way this would make it to #5 on my wish list :) 6. Contribute to the code. I have tried to get a foot in the door in > order to fix some of my own critisisms, but the lack of javadocs mean > that I really can't do this other than for some simple plugins. That > is unless I had lots of time to spare which I don't. In turn that > makes me concerned how the project will attract other developers to > move things along quickly. Yes, we're working on that too. We've had several new contributors, but there are some barriers to entry. Specific pointers to things that are too hard are good. Now I'll turn my attention to Ivy. I've began to look at this product > and it seems to offer many of the features of Maven including > > 1. transitive dependencies many != 1 :) As Jason said, apples and oranges. Ivy is a very good dependency manager. So is Maven. Ivy doesn't do anything else. Maven does. 2. compatibility with the ibiblio repository otherwise known as leveraging all our hard work :) The Maven team and community (through upload requests) created and maintain that repository, and established automated sync processes with open source organisations and hope to grow that. BTW, we offered for Ivy to use our metadata as well, and had some discussions, but they declined. So as of today they still have 29 artifacts usable OOTB (the same as when Ivy 1.0 was released). Maven adds that many every day, usable now. Some of it has some crud to clean up, but we're working on that this month too. Ivy has a sandbox with more - no idea how much or how usable it is - it basically seems to be the result of the spring build. Here's a short feature comparison, just in terms of dependency management tasks (excluding all the other things maven brings). These are things Ivy don't actually list on their comparison page that you later refer to, but are lumped under "transitive dependencies". In all other aspects I consider Maven to be as good as or better than Ivy (with the exception of no eclipse plugin :) Dependency ranges: - Ivy supports simple notation of 2.1+ which is equivalent to Maven's [2.1, 3.0) - Maven supports any range you can specify, using set notation, eg [1.0,1.4 ),(1.4,2.0) which is the latest 1.x version that fits, but I don't want 1.4. I expect this would be rarely used, but it is powerful. Versions: - Ivy supports string comparison for determining the greater version - Maven supports a defined ordering (so 0.10.0 > 0.9.0) modelled on best practices. If the version doesn't match that pattern, it uses string comparison. We intend to make this strategy pluggable. Different conflict resolution techniques: - Ivy seems to support a few here: all, latest-time, latest-revision, fixed - Maven is yet to support this completely, but essentially supports "nearest" and "fixed". Nearest is the closest in the graph, which becomes fixed when it is in the current POM. All (you can't use 2 versions at once) and latest-time (we don't use file timestamps, but instead snapshot metadata) don't make sense in Maven. The others we intend to add are "newest" (latest-revision), "oldest" and "fail" (if they don't all match, fail), as well as making it pluggable. It narrowly missed beta-1 and should be in the 2.0 release (one of the few new features to add in a beta cycle because the infrastructure is already there and it won't break compatbility). "Continuous Integration" support: - Ivy supports publishing an integration build (like Maven's snapshots) - Maven supports a wide range of options controlling the use of snapshots, frequency of receiving updates, timestamping and build numbering Profile support: - Ivy supports "configurations" - hard coded ids that can be used to enable certain dependency sets. - Maven defines a consistent profile layer, that can be activated by not only ids, but by pluggable activators including the JDK version, operating system, and other environmental factors such as the user building the project. This applies to the whole project build process, not just dependencies. Scope support: - Ivy requires the use of overloaded configurations for this - Maven builds the notion of the lifecycle in to dependency management, so can do intelligent scoping of the dependencies (eg, compile scope dependencies are also available for runtime and tests) Filtering: - I couldn't find Ivy support for this, but since you create the metadata yourself most of the time it isn't surprising. - Maven allows you to exclude dependencies from the tree. It also allows you to apply a particular version or scope to a dependency. Multiple project support: - I thought I saw mention of very basic support of this, but couldn't find it on the web site. - Maven allows you to build multiple projects at once, and the results are used as the dependncies encountered in other projects. The order of the builds is determined by the dependencies. System scoped dependencies: - Ivy has no support for this (you would likely declare it yourself anyway) - Maven supports this for things like tools.jar. I should note that this is just friendly competition for us - please don't take it as an us vs them. If Ivy and Ant does what you need, go for it. But perhaps through our lack of documentation (which this should now be turned in to!), many people don't realise that Maven meets and exceeds the capabilities of Ivy in all areas bar one on which it is very close. and in addition > > 1. the online docs are excellent even if they are in broken english Yes, its important. They only got that way after they declared 1.0 though. Give us the same benefit of the doubt that we'll get there :) 2. Can manage projects from with eclipse, since they are just ant > projects (with simple projects, haven't tried anything tricky) This isn't a feature of Ivy. You can generate Ant scripts from Maven too, or use the Maven ant tasks for dependency management. 3. Can manage maven style module directory structures or single > source trees. Obviously being Ant, it can manage any structure you > like, but these are the only two sane ones I know. Again, this isn't a feature of Ivy. You can generate Ant scripts from Maven too, or use the Maven ant tasks for dependency management. Yes there is stuff that it doesn't have such as a built in lifecycle, > but with what I've learnt from the maven layout, I feel I could quite > easily replicate that in ant in a reusable way. Yes, you could. And it would be different to everyone else's. And then, every time you need a new feature, or tool integration into that cycle, you could implement that too. Do you have time? That said I would > prefer not to have to. I suppose I'm looking for reassurance as to > why Maven is the way to go because there seems to be considerable > overlap with Ivy. Yes, there is considerable overlap. Maven completely overlaps it :) That's about 15-20% of Maven's functionality, though, as I've said above. I realize that I am being very selfish here, but I have to think very > carefully about what I invest my time in. Maven has all the hallmarks > of being that software that I felt was missing during my career, > which is why I care enough about it to spare the time for these > critisisms. I just want to be sure it has a chance of gaining > critical mass. I'm not sure what you mean by critical mass? We've exceeded a lot of the milestones we'd have thought unachievable in the past and it has grown much more strongly than expected in recent months. We've got a lot of work to do, and we welcome help. But we're still on the upward curve. Maybe the gatekeeper/guardian of this project needs to write some > sort of Jerry Maguire style memo that says what Maven's purpose is > and plans are so that we can all keep focused on that. We try to educate all new committers in the ideals of the project, and I think we all agree on therm, which is why among the developers there is rarely friction. As an open source project, there is no gatekeeper/guardian. Everyone that participates gets a say. That includes you :) Hope this was of assistance! Thanks, Brett
