On Tue, 2005-09-20 at 14:19 +0100, Ashley Williams wrote: > 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.
We are rapidly trying to make Ant functionality available in m2 by creating a plugin type that allows you to script up plugins using Ant's familiar XML scripting. If you can't wait and have a pending project then your stance is understandable. For the time being you can take advantage of what we've made available via Ant tasks. > 2. Usability from Eclipse - when will I be able to ditch the command > line and create and manage projects entirely from eclipse This is something that is actively being pursued and something will materialize sooner rather then later. We understand the critical nature of tool integration. The importance is not lost on us, we understand. > 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. Here our aims are different. We don't want everyone scripting up everything in their own way. It may be convenient in the short term but we would prefer to wait for someone to create a coherent, consistent way to launch an appserver for testing so that it benefits all Maven users. We feel in the long run this approach serves the community better but this notion is often at odds with folks who needs to get things done Right Now(tm). > 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. The documentation is admittedly lacking. I am actually working pretty much full-time on writing doco for the release so this is not lost on us either. We know that documentation is critical for successful widespread adoption. > 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. That's a choice you'll have to make. Many people have found making the switch to our default ways of doing things has numerous benefits. If it's not something you can do then we understand but we feel coherency, consistency, and comprehension win out over other concerns. Make a good plugin and all Maven users benefit. Make a one off script for your own setup and you've just isolated yourself from a great source of potential help. Making a decent plugin might take you an extra 20% in time but the ultimate savings in time has shown itself in our community over and over again. We also know that new projects are starting all the time and this is the ideal time to try Maven. For people who have different structures, you will probably also find that their build now works and in these cases I would never recommend switching from Make or Ant unless you are having serious problems with maintenance. > 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. We have actually attracted more developers in the last 6 months then ever before. We've got 4-5 new developers on the maven project and at least as many on the Mojo project. So things are actually looking great in terms of community involvement and I think it's only going to grow as we approach a final release. There is currently a barrier to entry but we've managed to overcome that and we're working on making getting involved easier: http://maven.apache.org/maven2/developers/development-guide.html > I realize there may be workarounds for some of the above, but I > couldn't stick my neck on the line for a dev team and recommend > sharing of eclipse hack scripts etc as a way of working. I'm also > putting my selfish hat on and say that I'd like to do the above > without defending it - there are a few threads on this list already > that deal with the pros and cons. > > *************************************** > > 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 > 2. compatibility with the ibiblio repository But this is a mere fraction of what Maven tries to accomplish. I don't think you can really compare the two. Ivy provides a very small subset of Maven's capabilities. > and in addition > > 1. the online docs are excellent even if they are in broken english Docs are docs, it's true. But we'll be in better shape for the final release. > 2. Can manage projects from with eclipse, since they are just ant > projects (with simple projects, haven't tried anything tricky) > 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. Eclipse support is coming, I promise :-) As far as allowing any structure, that's just not what Maven is about. We don't encourage that and never will. We just feel in the long run the build is not what developers should be focusing on. The build should apply standard patterns much like all other aspects of software development and the focus should be on enriching your application. That's where the value lies. Anyone who uses Maven can talk to anyone else who uses Maven and understand much of what the other is talking about because we employ and encourage these best practices. If you have an entirely isolated setup your chances of getting help are limited and you will remain isolated. We try to carry the whole notion of patterns into the build infrastructure so people save their valuable time by being able to communicate effectively about specifics of a build. > 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. We know from painful experience that is not the case. I know of many attempts to replicate what Maven does in many organizations and very few of them still live on today. A great deal of consideration went into m2's lifecycle and I sincerely doubt it could be easily replicated. > 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. Maven and Ivy are not really comparable. Apples and Oranges. Ivy simply does dependency management and nothing else. > **************************************** > > 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. Everyone's time is important and deciding what to spend your time on is critical. We know that Maven has some shortcomings (just look at our JIRA!) but issues are being fixed at a breakneck pace. We think that with the release of 2.0 we're going to have something pretty good. > 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. What kind of demo do you suggest? I've never seen Jerry Maguire :-) > Maybe my views aren't representative of a large enough demographic in > which case this email will just slip away into obscurity, but either > way thanks for reading and please don't take it as a troll Lots of folks have talked about the things you're talking about here. Everyone once in a while I respond just to refresh in my own mind why the project was started. It takes a while to get accustom to the way Maven works and what its goals are. In a nutshell Maven is an attempt to apply patterns to a build infrastructure in order to make things easier for everyone involved in Java (more languages later) software development. > -AW > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
