On 8/30/06, Pierre-Yves Saumont <[EMAIL PROTECTED]> wrote:
I switched to Maven 2 because I was tired of Ant. When one looks at a good Java project, one can find its way easyly because there are well known architecturing and coding standards. There are no such things with Ant. I remember trying to find my way in Ant scripts calling other Ant scripts, and that was kind of a nightmare. (Even with scripts I had written myself few monthes before :-) Maven is exactly what I need. The maven way to do things might not be the best way, but it is consistent. Consistency is much more valuable than anything else. It is what I like the most in Java, and it is what I like in Maven. The big problem is documentation. The Merger book is a good introduction, but it does not help very much to do your own work because as soon as you need something a bit different from the example, your are alone. I learned the most from two chanels : The Maven 1 documentation (many things work the same) and looking at Poms in other projects. (For example Wicket). What is urgently needed (IMO) is a Reference documentation with the list of all configuration options and all possible values. I decided to spend 6 week to learn Wicket, Maven 2 and EJB3 before I start my next project. Until now, I am very satisfied with Wicket and Maven 2. What I miss the most is aggregation. Some reports seems not to aggregate at all, somes have problems (aggregating Javadoc AND Xref). I also have problems to understand complicated transitive dependencies (I ou're using JBoss, you better be sure that there is not a wrong version of a jar in the classpath ;-)
Yeah, I have endless problems fighting with JBoss. So much so, that I created a plugin at work that does the following: product:deploy-files: Recurse through a project (well, directory structure) and deploy all jars,wars,ears (anything requested) to a repository w/ the same groupId and version number (presumably the gID/version of the project, such as jboss: 4.0.4) product:product / deploy Generates an assembly for the remaining files (xml, directories, etc) and builds a zip of the product with a pom, so you can deploy it to a reposiory. product:install Grabs the product (zip) from the repository and unpackages it to the given directory. What I was thinking here was a sort of "Mavenized" APT or MSI for installing specific versions of an entire product. I'm not certain if it is an abomination against nature, or has any merit at all (naturally, there can be problems with exact copies of artifacts under different coordinates, eg., jboss:junit:4.0.4 vs junit:junit:4.0 ). Pierre-Yves
Eric Redmond a écrit : > Hi all Maven users! > > I'm beginning a study to outline the real reasons that people have for > avoiding Maven. My questions to you all are: > What were your anxieties about using Maven? If you use Maven: what helped > you make the decision? If you don't: why did you avoid it? > > Here are some that I have heard in the past: > > * Lack of good documentation. > * Community unwilling to help me with my problems. > * Not "industry supported" or "mainstream" enough. > * I don't like conforming to the Maven project layout. > * My project is too complex to switch. > * There are not enough plugins available. > * We already have a large investement in tool X. > * I have to build native/non-Java code. > > Any more reasons? Care to expand these ideas? > Thanks for your help! > ____ > Eric Redmond > http://codehaus.org/~eredmond > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Eric Redmond http://codehaus.org/~eredmond
