> I have spent a little while trying to get Maven integrated as > the build and deploy system for one of our products at my day > job.
A lot of people here have done this. I agree it could be easier, especially in terms of doco, but I'm sure that will improve as we go towards 1.0. Feedback and experiences definitely help! > 1) Project xml and Project properties. > Maven sells itself as 'wite a project xml and you are done'. > But in reality this is not the case. Many parameters are > controlled in the project properties, and still others have > to be hacked into the maven xml. This is very confusing. The > roles of each of these files needs better defining. I agree to some extent here. Utilising certain plugins requires properites, and we can only get around that by making the POM extensible. I think this might be a good long term goal, but for now explaining what goes where is done reasonably well by the individual plugin docs. There are some things that definitely don't go in the POM, like... > For example, it would seem more sensible to include the > location of the central repository in the project xml file. > I'm sure there is a reason why its not, but its not clear. Are you talking about where you upload the artifacts too, or where you download them from? I assumed download them from initially - and that's definitely not a per-project sort of setting (Although you can always override it per-project which is helpful). If its upload to - I agree that the distribution/site properties should also be able to handle any type of artifact upload, but again this needs to be overriden as you may upload it to some other repository on an infrequent basis (partial mirrors, for example that take releases and not snapshots). > 2) Repository is an over used term > The main project xml has a <repository> element. But this is > not what you would expect as it does not define details of > the central or local repositories. Instead it defines scm. > PLEASE rename this element. Fair enough - but anyone that has read the project descriptor documentation or seen one example will realise this immediately. > 3) No mid-level repository > A corporate environment wants three levels of repository, not I have no problems using 2 remotes (one intranet, one internet) + a per-user local for our environment. Deployments are all done to the intranet version, which are controlled by separate properties at the moment. You might also check out Ben Walding's maven proxy app - I think this is what you want if the above is not good enough. > 4) Releases with jars > To include the jar files in the output zip files requires a > change to maven xml. This seems like a very normal kind of a > requirement, but is difficult to achieve. I suggest that the > project xml needs a way to define which dependencies to > include in the zip. I've already built an installer plugin for our environment. I plan on integrating it into the dist plugin "real soon now" :) > 5) Assumptions from OSS > Too much assumes the OSS model, where deployments are via > scp/ssh. A corporate environment will use file copies far > more often. I suggest that each place where communication > takes place should use a uniform definition of communication. I think you are assuming a lot about a typical corporate environment :) I would think most have separate networks and machines for building, deploying, developing, and they have to get around either by ftp or ssh. Both are available in the aritfact plugin, as well as file. > For example, at present, I still don't know how deploy the > zip files via a file copy. dist:deploy seems determined to > talk to ibiblio, which of course fails. The pom:deploy plugin > uses one property while site:deploy uses another. I suggest > this desparately needs unifying. Agreed. More things need to move to the artifact plugin (like site, dist, jar:deploy...). Currently pom and war do. > 6) Maven-propaganda logo. I personally agree, but a vote was held at the time. Maybe another vote is in order for 1.0 because a few people have said this (I changed it myself to the bolt one). > 7) Plugin documentation > There is lots of documentation in terms of pages, but often > very little real information of value. The plugin pages are > often very weak. I suggest some redesign is needed. Volunteering? :) > For example(2), the plugins list includes both very basic > functions (java, jar, site, dist, deploy) and many, many > others. Trying to work out what you actually need to know is > VERY difficult. I suggest breaking out a core set of plugins, > at least in terms of documentation. And these core plugins > need to be very well documented. There's been a reasonably long discussion about this on the -dev list, with all extremes given (distribute all or none :) It will be reduced in the medium term, but by how much I don't know. > 8) Getting started/User guide are too complex > The Maven concept isn't that hard really. But the > documentation makes it seem hard. A document that says how > you should layout your files and what the 5 or 6 basic plugin > calls are would make a great difference. It should also link > to other docs for more info. Fair comment. Often it is better to get someone new in to write these sorts of docos as they are more in tune to what is needed starting out (I've forgotten after just 8 months...) > - copy the zips to a file location of my choosing Does maven.repo.central=file:///path/to/new/repo work? Otherwise you may need to go to maven.xml to do this as a goal after "dist" > - label the CVS scm:prepare-release? > - increment the currentVersion property scm:prepare-release? > - do a release with a single maven call scm:prepare-release? > In the end you start to wonder whether it really benefits you > over Ant. I'm convinced it does. Gee, you were doing so well with the constructive criticism until you got to this line :) > Please don't misunderstand me, Maven works well when it > works. But it is incredibly fustrating when it doesn't. Well, this is the case for 100% of software. What we need to figure out is how to marke it work well more often, and communicate how it works well for the things that aren't that obvious. My belief is we need a large number of tutorials written for a variety of tasks (the recent devX article was very good). Volunteers are needed and welcome. Thanks for sharing your experience Stephen, its rare to see something written well and 99% anti-inflammatory about what may have been a frustrating experience. I hope I've cleared a few things up for you. Cheers, Brett
