Little comments... "Stephen Colebourne" <[EMAIL PROTECTED]> wrote on 26/09/2003 07:09:02 AM:
> 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. > > 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. Agreed it's not too clear about the split, but in this case, the central repo is a cross project concern, and is not *usually* overridden. > 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. Agreed, but not for the 1.0 timeframe. POM changes are out until we get the release done. > 3) No mid-level repository > A corporate environment wants three levels of repository, not two. The > central ibiblio, the local one, and a shared network server in the middle. > Releases are made to the shared network server, not ibiblio. I suggest > building a middle level repository into the design. Have you seen maven-proxy? This would let you use your corporate server as the remote and download on demand from ibiblio. > I have been forced to set the local repository to be the shared network > server, which is fine for single site working, but not for cross site > working. I know that you can have multiple remote repositories, but what > would happen when I release the code (jar:deploy)? Would it update both? > There simply isn't enough clarity. Agreed. > 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. ? Can you be more specific with this one? Is this a 'dist'? If so, this makes some sense, e.g. <dist.bundle>true</dist.bundle> on the dependency properties? I'd also like the dist to include 'common' stuff that may exist, e.g. src/conf, src/bin etc. > 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. > > 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. Michal was working on the deploy plugin to allow this to happen easily, but seems to have stopped. > 6) Maven-propaganda logo. > This should not be the default. It caused raised eyebrows in my corporate > environment and I had to find the way to change it. (I'm sure you are all > aware of the significance of the red star). The maven feather image is much > more acceptable to corporate users (and also OSS if you examine > jakarta-commons lang/collections/...) Ask for a re-vote. That's how the first one got voted in to start off with. > 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. > > For example, the plugins page lists all the plugins at the top which link to > lower down the page before linking to the actual site for the plugin. This > is VERY annoying. Do you mean this page: http://maven.apache.org/reference/plugins/index.html ? We agreed a while back that it would be nice to have a better format, but noone has stepped up to define it, or write the piece for multiproject to allow it to be overridden. Raised as MAVEN-856. > 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. Better descriptions would probably achieve the same result. The problem is lack of information on the overview page, and then lack of information on the plugin page itself. > 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. Agreed. > At present I can > - build a jar (jar) > - build and deploy a site (site:deploy) > - create the zip files (dist) > - and after much, much trouble I can copy the jar to the repository > (jar:install) > But I still can't > - copy the zips to a file location of my choosing Did you change <distributionSite> in the POM? Or is this just the missing/inconsistent dist:deploy, vs dist:fsdeploy etc? > - label the CVS > - increment the currentVersion property > - do a release with a single maven call Have you looked at the scm plugin? It has some of these features. > In the end you start to wonder whether it really benefits you over Ant. If I look at the effort it takes to do simple things with Ant (jar, site, dist etc) vs Maven. It wins every time. For the more complex cases, I just remember we're not even 1.0 yet. > Please don't misunderstand me, Maven works well when it works. But it is > incredibly fustrating when it doesn't. And we'd love to get some more help in fixing these things. The best thing you can do is raise issues against Maven in Jira. That way we *HAVE TO* come back and consider it. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
