Re: Why Maven is Hard?
Dennis Lundberg [EMAIL PROTECTED]: Steinar Bang wrote: Two things have locked us to 2.0.4: - a bug in maven proper (I think) where maven will ungzip a tar.gz or tgz file it downloads, before dropping it in the local maven repo, still with the same name, which breaks when an attempt is made at using the file [snip!] If you can't find issues for these problems in JIRA, please create new ones. Add the stack trace to the issue, by running 'mvn -e ...' I unintentionally verified that the ungzip problem is present on 2.0.7 tonight (I used the wrong maven version on a build server, and now I have to wait for the admin to clear up the build user's maven repository...), and I couldn't find any maven bugs containing gzip, uncompress, or tgz, so I reported it: http://jira.codehaus.org/browse/MNG-3233 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Dennis Lundberg [EMAIL PROTECTED]: Thanks for your input Steinar. But this isn't at all helpful. Because is to vague. In order for us (the Maven devs) to fix things we need you (the Maven users) to let us know *exactly* what is wrong. Please give us concrete examples, then we can fix them. Two things have locked us to 2.0.4: - a bug in maven proper (I think) where maven will ungzip a tar.gz or tgz file it downloads, before dropping it in the local maven repo, still with the same name, which breaks when an attempt is made at using the file - our use of profile gave maven 2.0.5 a nullpointer exception, and still breaks with error messages I don't understand, and haven't had time to look closer at, on 2.0.7 The profile problem is the reason I haven't been able to verify that we have the unpack issue on 2.0.7, which is why I haven't reported it as a bug. Trying to find out about the two above have been _major_ time wasters. We have spent days trying to track down what has been happening with the first one, and have spent days trying to understand profiles enought to fix the second one. So I guess profiles should definitely be classified as _hard_. Of course this does not really apply when documentation is totally missing. Well, the plugin that had documentation preceeding the currently released plugin was maven-dependency-plugin a way back. I was trying to use the analysis goal, which the documentation showed but the plugin didn't have. And also there were some exclude* parameters in copy-dependencies that were in the online docs, but not in the released plugin. This is hopefully outdated information, and has been fixed a long time back. However I avoid doing mvn -U, since I'm still on 2.0.4 (see above). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Steinar Bang wrote: Dennis Lundberg [EMAIL PROTECTED]: Thanks for your input Steinar. But this isn't at all helpful. Because is to vague. In order for us (the Maven devs) to fix things we need you (the Maven users) to let us know *exactly* what is wrong. Please give us concrete examples, then we can fix them. Two things have locked us to 2.0.4: - a bug in maven proper (I think) where maven will ungzip a tar.gz or tgz file it downloads, before dropping it in the local maven repo, still with the same name, which breaks when an attempt is made at using the file - our use of profile gave maven 2.0.5 a nullpointer exception, and still breaks with error messages I don't understand, and haven't had time to look closer at, on 2.0.7 If you can't find issues for these problems in JIRA, please create new ones. Add the stack trace to the issue, by running 'mvn -e ...' The profile problem is the reason I haven't been able to verify that we have the unpack issue on 2.0.7, which is why I haven't reported it as a bug. Trying to find out about the two above have been _major_ time wasters. We have spent days trying to track down what has been happening with the first one, and have spent days trying to understand profiles enought to fix the second one. So I guess profiles should definitely be classified as _hard_. Of course this does not really apply when documentation is totally missing. Well, the plugin that had documentation preceeding the currently released plugin was maven-dependency-plugin a way back. I was trying to use the analysis goal, which the documentation showed but the plugin didn't have. And also there were some exclude* parameters in copy-dependencies that were in the online docs, but not in the released plugin. This has been a source of confusion and frustration for users before. What we have done to improve the situation is to add support for @since annotations for mojo classes and parameters. If these annotations are added in the source code for a plugin, and they should be, the generated documentation for goals and parameters shows this. The dependency-plugin has a good example of this, where the class (goal) is available since 2.0-alpha-3 and a couple of parameters since 2.0-alpha-5: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html This is hopefully outdated information, and has been fixed a long time back. However I avoid doing mvn -U, since I'm still on 2.0.4 (see above). Thanks -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/30/07, Steinar Bang [EMAIL PROTECTED] wrote: Well, the plugin that had documentation preceeding the currently released plugin was maven-dependency-plugin a way back. I was trying to use the analysis goal, which the documentation showed but the plugin didn't have. And also there were some exclude* parameters in copy-dependencies that were in the online docs, but not in the released plugin. The experiment with publishing the latest plugin docs and marking new things since x.x.x admittedly hasn't gone too well. There's some configuration in the latest plugin parent pom that will allow us to easily publish snapshot docs under a different url, as well as archive the docs for each released version. Once that release happens and I have some spare time I'll pick up that project again... -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Dennis Lundberg schrieb: [...] Well, the plugin that had documentation preceeding the currently released plugin was maven-dependency-plugin a way back. I was trying to use the analysis goal, which the documentation showed but the plugin didn't have. And also there were some exclude* parameters in copy-dependencies that were in the online docs, but not in the released plugin. This has been a source of confusion and frustration for users before. And I think it still is. What we have done to improve the situation is to add support for @since annotations for mojo classes and parameters. If these annotations are added in the source code for a plugin, and they should be, the generated documentation for goals and parameters shows this. With this I think, you just try to medicate a symptom instead of healing the root cause (to speak in medical terms). The root cause is imho that the current plugin documentation is not what the useres expect it to be. When a user sees in the plugin index the entry for the dependency plugin with the version stated as 2.0-alpha-4 and then clicks on the link to the plugins documentaion she expects to read the documentation for *exactly* that version and not for some unreleased features. The dependency-plugin has a good example of this, where the class (goal) is available since 2.0-alpha-3 and a couple of parameters since 2.0-alpha-5: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html This is hopefully outdated information, and has been fixed a long time back. However I avoid doing mvn -U, since I'm still on 2.0.4 (see above). Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Tim Kettler wrote: Dennis Lundberg schrieb: [...] Well, the plugin that had documentation preceeding the currently released plugin was maven-dependency-plugin a way back. I was trying to use the analysis goal, which the documentation showed but the plugin didn't have. And also there were some exclude* parameters in copy-dependencies that were in the online docs, but not in the released plugin. This has been a source of confusion and frustration for users before. And I think it still is. What we have done to improve the situation is to add support for @since annotations for mojo classes and parameters. If these annotations are added in the source code for a plugin, and they should be, the generated documentation for goals and parameters shows this. With this I think, you just try to medicate a symptom instead of healing the root cause (to speak in medical terms). Agreed. This was a soothing pill to ease the pain somewhat. It hasn't cured the patient completely though. This pill has been used in other places like the Ant documentation as well, which has been brought up as something to look up to. The root cause is imho that the current plugin documentation is not what the useres expect it to be. When a user sees in the plugin index the entry for the dependency plugin with the version stated as 2.0-alpha-4 and then clicks on the link to the plugins documentaion she expects to read the documentation for *exactly* that version and not for some unreleased features. As Wendy said, there has been some work done on this, but it's not finished yet. The dependency-plugin has a good example of this, where the class (goal) is available since 2.0-alpha-3 and a couple of parameters since 2.0-alpha-5: http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html This is hopefully outdated information, and has been fixed a long time back. However I avoid doing mvn -U, since I'm still on 2.0.4 (see above). Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/28/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Lee Meador wrote: That sounds as easy as herding cats. Trying to get all the people on the user list to NOT do anything is unlikely. The fact is, as I see it, its easier to just give a quick answers to questions that strike my fancy than it is to hunt it down in the docs and point them to it. That allows me to limit the time I have available to invest in Maven. If I give the the URL directly, they don't know how to find it in the future. What could be easier to find than a URL? Just add a bookmark/favorite. If I want to tell them which links to click to get there, its a pain for me. Its also likely to change in the future (as it has in the past when the docs were rearranged). FInally, typing in a list of things to click is error prone and easy to get wrong. Maybe someone (or ones) would volunteer to collect the questions from the newsgroup and transfer them to the site if someone else would reply to the interesting questions with some magic words that could be searched on. So, for example, I see what seems to me to be a FAQ with a useful answer in some thread on this list. I reply with the magic word FAQCANDIDATE in the reply. I picked one word because Google searches for two words differently than one word. Then the collectors could search for that word and come up with a short list of user list threads to mine for good FAQ entries. This is exactly what the user wiki can be used for. If people on this list would go the extra bit and add these FAQ candidates (plus answers of course) to the user FAQ we'd have won a lot. Sure, people are actually happy to do it, but it's gotta be straightforward to do so. The wiki 'answered questions' faq has all the good answers in it, and it's not the FAQ list on the side of the maven.apache.org page. It's not even the Wiki page you hit when you go to the wiki and hit the FAQ. Instead we get the unanswered questions, which is not helpful. Earlier today I finished adding the questions answers from the FAQ on maven.apache.org to the Wiki's 'answered questions' faq. So now it can serve as a complete replacement for the maven.apache.org page. Can we get that one linked to on the left-hand sidebar now? -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Lally Singh wrote: On 9/28/07, Dennis Lundberg [EMAIL PROTECTED] wrote: Lee Meador wrote: That sounds as easy as herding cats. Trying to get all the people on the user list to NOT do anything is unlikely. The fact is, as I see it, its easier to just give a quick answers to questions that strike my fancy than it is to hunt it down in the docs and point them to it. That allows me to limit the time I have available to invest in Maven. If I give the the URL directly, they don't know how to find it in the future. What could be easier to find than a URL? Just add a bookmark/favorite. If I want to tell them which links to click to get there, its a pain for me. Its also likely to change in the future (as it has in the past when the docs were rearranged). FInally, typing in a list of things to click is error prone and easy to get wrong. Maybe someone (or ones) would volunteer to collect the questions from the newsgroup and transfer them to the site if someone else would reply to the interesting questions with some magic words that could be searched on. So, for example, I see what seems to me to be a FAQ with a useful answer in some thread on this list. I reply with the magic word FAQCANDIDATE in the reply. I picked one word because Google searches for two words differently than one word. Then the collectors could search for that word and come up with a short list of user list threads to mine for good FAQ entries. This is exactly what the user wiki can be used for. If people on this list would go the extra bit and add these FAQ candidates (plus answers of course) to the user FAQ we'd have won a lot. Sure, people are actually happy to do it, but it's gotta be straightforward to do so. The wiki 'answered questions' faq has all the good answers in it, and it's not the FAQ list on the side of the maven.apache.org page. It's not even the Wiki page you hit when you go to the wiki and hit the FAQ. Instead we get the unanswered questions, which is not helpful. Earlier today I finished adding the questions answers from the FAQ on maven.apache.org to the Wiki's 'answered questions' faq. So now it can serve as a complete replacement for the maven.apache.org page. Can we get that one linked to on the left-hand sidebar now? I have added a link to the (answered) FAQ wiki page on the left-hand side menu. It'll be right next to the (official) FAQ entry. Note that the site has not been deployed yet. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
The standard for how we document the plugins within the Maven project can be found here: http://maven.apache.org/guides/development/guide-plugin-documentation.html It has been a long way and a lot of work to get this in place for all our plugins. The purpose of the standard was to document plugins in a similar way. That should make it easier for users to find their way around any plugin site, if they have learned it once. We don't accept new plugins unless they follow the plugin documentation standard. We have even written a plugin that helps us check this: http://maven.apache.org/plugins/maven-docck-plugin/ Final note: I take it that you are being payed money where you work. This is an open source project. EJ Ciramella wrote: I have to agree with the comments in this thread. Asking someone to contribute documentation for a plugin they didn't write is pretty lame. How about not letting someone submit a plugin until not only has the code been tested/proven, but the associated documentation is up to snuff? I don't know how it works where ever you guys are working but when code is committed to our SCM system here, a code review has to pass. Part of that review is to go over the associated documentation. Also, I've spent hours upon hours chasing my tail on things like the bug where profiles weren't ordered in the order specified on the commandline (it seemed partially random and then partially due to ordering in settings.xml/profiles.xml). After many days of silence on both mailing lists, we pulled down the source and realized that it was a bug, fixed it, and then saw a new release of maven 2 come out that did the same thing. We've also noticed that classpaths aren't as controlled as we would have liked. A scenario is - three modules at the same level, two branched away as to be built in isolation. All of a sudden the third module can't find any classes that the first two put into the compile classpath - and this is the case if/if not there are dependencies on these modules to/from each other. I'd also like to echo the sentiment, maven is great if you're doing standard stuff and maven is HORRIBLE when you're trying to do anything out of the norm. I feel like it's easier to just write my own plugin than it is to scour the maven site in hopes of finding something suitable to my needs. Additionally, twice now we've started using a plugin just to find that it has been abandoned for a less buggy plugin. Where's the repository management documentation (how to set one up at your company, how to keep it up-to-date, etc.)? I work at a relatively large company and I can't believe for a second other companies similarly sized or bigger would want developer groups going across the internet the way maven tries to do (for plugins and dependencies). This also makes overseas development challenging. Look, I think many people are wanting a build tool better than shell scripting and make, possibly easier than ant - but something with less of a learning curve of maven 1 or 2. I think ant is REALLY smooth and easy to code/understand. To say that ant is challenging in any way/shape/form is to deny the truth. Maven 2 build/release engineering does get easier with time, but we all don't have limitless time to learn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Lally Singh wrote: On 9/26/07, Wendy Smoak [EMAIL PROTECTED] wrote: (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) YES. Right now the docs tend to look 100% autogenerated and be 0% useful. Well, that's because a lot of it *is* generated. That in combination with a site disposition that we agreed upon makes the plugin sites look similar. But that should be a good thing! It's tough to find the useful material in all the autogenerated and unnecessary fluff. Just a description of all the options (e.g. reference documentation) and an example is all I'm asking for. Every plugin has (auto-generated) reference documentation of the available options. Click the Goals link in the menu to go there. Then click on the goal that you are interested in. All plugins at the Maven project work this way. That being said, many options lack good descriptions. This is where I see that you, the user community, can help us improve this. We need to find a good way to find out which specific options that need better descriptions. Some boilerplate in there in how to set up plugins (in general) would also be nice. On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: Make the Better Builds book available directly through the Maven site WITHOUT registration. That'd be nice. Even before hearing back from the respective authors, HOW ABOUT LINKING TO THEM I don't mind registering. I mind finding out about the book randomly from the mailing list or google. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Lee Meador wrote: That sounds as easy as herding cats. Trying to get all the people on the user list to NOT do anything is unlikely. The fact is, as I see it, its easier to just give a quick answers to questions that strike my fancy than it is to hunt it down in the docs and point them to it. That allows me to limit the time I have available to invest in Maven. If I give the the URL directly, they don't know how to find it in the future. What could be easier to find than a URL? Just add a bookmark/favorite. If I want to tell them which links to click to get there, its a pain for me. Its also likely to change in the future (as it has in the past when the docs were rearranged). FInally, typing in a list of things to click is error prone and easy to get wrong. Maybe someone (or ones) would volunteer to collect the questions from the newsgroup and transfer them to the site if someone else would reply to the interesting questions with some magic words that could be searched on. So, for example, I see what seems to me to be a FAQ with a useful answer in some thread on this list. I reply with the magic word FAQCANDIDATE in the reply. I picked one word because Google searches for two words differently than one word. Then the collectors could search for that word and come up with a short list of user list threads to mine for good FAQ entries. This is exactly what the user wiki can be used for. If people on this list would go the extra bit and add these FAQ candidates (plus answers of course) to the user FAQ we'd have won a lot. The only way I see that I would fail, besides nobody doing it, is if idiots invade the list and overuse the magic word. -- Lee Meador On 9/27/07, Wim Deblauwe [EMAIL PROTECTED] wrote: What about not answering any questions on the mailinglist anymore, but only point to existing documentation. If there is no suitable docs for the question, put in a JIRA issue. That should improve the docs fast! regards, Wim 2007/9/27, Wayne Fay [EMAIL PROTECTED]: On 9/26/07, Tomasz Pik [EMAIL PROTECTED] wrote: Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org OK, I'll bite... starting at http://maven.apache.org on the left, click on Wiki scroll down to Children, click on FAQs, see its not there click on previously answered questions (or click back and click on FAQs-1) oh look, there it is -- Testing How do I skip unit tests when building a project? Admittedly, I'm not sure why we have 2 FAQ pages in the Wiki, plus another FAQ on the main Maven site. But I also don't think this is all that horrible. Obviously you can't expect to find every answer this easily but common questions should be. So the next step seems (to me at least) to be determining what are those common questions, as I mentioned in Brian's thread on improving site docs. This is something that users like yourself must participate in if we hope to have any chance of success in this effort. (Also if you Google for maven skip unit test there's a number of hits right away. I personally feel that answers found via Google are no less valid than others, especially if you add the site:maven.apache.org directive. To say nothing of all the hits in the mail list archive if you search for this.) Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Vigilog - an open source log file viewer: http://vigilog.sourceforge.net Blog: http://www.jroller.com/page/Fester -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Steinar Bang wrote: Denis Bessmertniy [EMAIL PROTECTED]: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. Here are the problems I have had: - unclear where maven ends and plugins take over - unclear what versions of the plugins are in use - unclear where the plugins come from, and who are responsible - sparse documentation, where the docs on the web may be for a different version of the plugin than the one you're using (I've seen a case where the documentation on the web was for a version of the plugin that hadn't been relased yet) - bugs in the plugins that require workarounds (and different people deploying maven at different points in time, may end up with different versions of the plugins which require different workarounds) - a bug in maven proper that has stuck us on version 2.0.4 These are from the top of my head. Thanks for your input Steinar. But this isn't at all helpful. Because is to vague. In order for us (the Maven devs) to fix things we need you (the Maven users) to let us know *exactly* what is wrong. Please give us concrete examples, then we can fix them. Of course this does not really apply when documentation is totally missing. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
What about not answering any questions on the mailinglist anymore, but only point to existing documentation. If there is no suitable docs for the question, put in a JIRA issue. That should improve the docs fast! regards, Wim 2007/9/27, Wayne Fay [EMAIL PROTECTED]: On 9/26/07, Tomasz Pik [EMAIL PROTECTED] wrote: Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org OK, I'll bite... starting at http://maven.apache.org on the left, click on Wiki scroll down to Children, click on FAQs, see its not there click on previously answered questions (or click back and click on FAQs-1) oh look, there it is -- Testing How do I skip unit tests when building a project? Admittedly, I'm not sure why we have 2 FAQ pages in the Wiki, plus another FAQ on the main Maven site. But I also don't think this is all that horrible. Obviously you can't expect to find every answer this easily but common questions should be. So the next step seems (to me at least) to be determining what are those common questions, as I mentioned in Brian's thread on improving site docs. This is something that users like yourself must participate in if we hope to have any chance of success in this effort. (Also if you Google for maven skip unit test there's a number of hits right away. I personally feel that answers found via Google are no less valid than others, especially if you add the site:maven.apache.org directive. To say nothing of all the hits in the mail list archive if you search for this.) Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Vigilog - an open source log file viewer: http://vigilog.sourceforge.net Blog: http://www.jroller.com/page/Fester
Re: Why Maven is Hard?
Denis Bessmertniy wrote: Now I recall words from one of our team member: I my last project we started to use maven and then we refused to use it because it was hard. Then we started to use Ant, and that is ok. The problem with ant is that it lets you do anything, and that is its key weakness. Many developers in my experience don't care in the slightest about builds, or repeatability or release management. Of course these same developers refuse to acknowledge the problem when there is a bug in a production system, and it turns out nobody can reproduce the bug because the code wasn't built from a clean tag but rather from the working copy of somebody's PC. Maven applies discipline to the project to prevent this mess, but in doing so it necessary needs to stop the developer from moving away from best practise. Developers by and large don't discipline themselves, so they need a carrot to attract them to using maven - and that carrot is ease of use. If maven doesn't become easy to use again, people will move away from it, and an important tool will be lost. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Why Maven is Hard?
On 9/27/07, Wayne Fay [EMAIL PROTECTED] wrote: On 9/26/07, Tomasz Pik [EMAIL PROTECTED] wrote: Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org OK, I'll bite... starting at http://maven.apache.org on the left, click on Wiki scroll down to Children, click on FAQs, see its not there click on previously answered questions (or click back and click on FAQs-1) oh look, there it is -- Testing How do I skip unit tests when building a project? The fact that people can't find it, and are obviously dedicated enough to the project to join the mailing list, proves that the navigation is insufficient. Admittedly, I'm not sure why we have 2 FAQ pages in the Wiki, plus another FAQ on the main Maven site. But I also don't think this is all that horrible. Obviously you can't expect to find every answer this easily but common questions should be. So the next step seems (to me at least) to be determining what are those common questions, as I mentioned in Brian's thread on improving site docs. This is something that users like yourself must participate in if we hope to have any chance of success in this effort. Why not merge them? (Also if you Google for maven skip unit test there's a number of hits right away. I personally feel that answers found via Google are no less valid than others, especially if you add the site:maven.apache.org directive. To say nothing of all the hits in the mail list archive if you search for this.) If you have to use google to search a website, the navigation is broken. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
2007/9/27, Lally Singh [EMAIL PROTECTED]: If you have to use google to search a website, the navigation is broken. Partially true: information should be easily available both through search engines and navigation links (it's Jakob Nielsen opinion, and mine obviously :-) ) Antonio
Re: Why Maven is Hard?
On 9/27/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/9/27, Lally Singh [EMAIL PROTECTED]: If you have to use google to search a website, the navigation is broken. Partially true: information should be easily available both through search engines and navigation links (it's Jakob Nielsen opinion, and mine obviously :-) ) Antonio I agree with Neilsen. Of course, the 'easily available .. navigation links' part fails here. Hence the '/have/ to use google'. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
rant How about you pay me and i'll do it... I don't get people who bitch and complain about stuff that really works if you can be arsed to actually try to figure it out. People have done all this work mostly for free... the least you could do is write a little bit of documentation where you have something of your own to share! /rant On Thursday 27 September 2007 01:36, EJ Ciramella wrote: I have to agree with the comments in this thread. Asking someone to contribute documentation for a plugin they didn't write is pretty lame. How about not letting someone submit a plugin until not only has the code been tested/proven, but the associated documentation is up to snuff? I don't know how it works where ever you guys are working but when code is committed to our SCM system here, a code review has to pass. Part of that review is to go over the associated documentation. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Ok, enough complaining out of me. If I could change all the files directly, I would. But, here are what I think would really help ASAP. 1. The front-page link to the 'Users Center' should instead point to the Maven Documentation Index http://maven.apache.org/guides/index.html. It's really the starting point for documentation, so put it there. 2. The big FAQ is the 'Answered Questions' in the Wiki. Link to that instead of the existing one (http://maven.apache.org/general.html). -- I just got an account with the wiki. Today I'll copy any FAQs in that page back to the Wiki page, so we don't lose anything. 3. Some general Re-org of that 'Documentation' tab on the left-side navigation. Some of those pages are just links to others, and can be collapsed. Others seem like articles. Ok, screw it, I'm in all the way. How can I contribute new content? I'll start doing a basic manual for Maven. Not that I know much about it, but I'll start squeezing that out of the source, existing docs, mailing list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On Thu, September 27, 2007 12:29 pm, Michael McCallum wrote: rant How about you pay me and i'll do it... I don't get people who bitch and complain about stuff that really works if you can be arsed to actually try to figure it out. People have done all this work mostly for free... the least you could do is write a little bit of documentation where you have something of your own to share! /rant The idea that it's free, what do you expect? quality? undermines confidence in both maven and open source in general, and this doesn't do the maven project any favours at all. Open source software is no way immune to criticism just because it is free. Criticism is useful, as it highlights areas where the code is not up to scratch, and shows where developers should be focusing their attention. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
2007/9/27, Graham Leggett [EMAIL PROTECTED]: The idea that it's free, what do you expect? quality? undermines confidence in both maven and open source in general, and this doesn't do the maven project any favours at all. Well in fact I think open source software has a higher level of quality when compared to proprietary software. Probably we all have seen proprietary code that is badly documented, written, engineered, etc. For example, I remember the story of Interbase DBMS (I can't find the link, sorry) when it was released as open source: the Firebird team had to fix 25000 compilation warnings! But think bigger: if you try to get docs from Oracle website, you will find almost nothing. If you want docs, you have to go to AskTom or some .edu websites :-( Antonio
Re: Why Maven is Hard?
If everyone that posted an email on this thread actually wrote a Wiki article with a single paragraph, Maven would already be easier. Regards, Rodrigo On 9/27/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/9/27, Graham Leggett [EMAIL PROTECTED]: The idea that it's free, what do you expect? quality? undermines confidence in both maven and open source in general, and this doesn't do the maven project any favours at all. Well in fact I think open source software has a higher level of quality when compared to proprietary software. Probably we all have seen proprietary code that is badly documented, written, engineered, etc. For example, I remember the story of Interbase DBMS (I can't find the link, sorry) when it was released as open source: the Firebird team had to fix 25000 compilation warnings! But think bigger: if you try to get docs from Oracle website, you will find almost nothing. If you want docs, you have to go to AskTom or some .edu websites :-( Antonio
Re: Why Maven is Hard?
On Thu, September 27, 2007 12:59 pm, Rodrigo Madera wrote: If everyone that posted an email on this thread actually wrote a Wiki article with a single paragraph, Maven would already be easier. No no no no. The problem is not the _quantity_ of the documentation, but the _quality_ of the documentation. This thread has highlighted the fact that the documentation doesn't help new users of maven, or users of maven who have no desire to become experts. Just dumping yet more documentation on this group of people isn't going to answer their questions. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Lally Singh [EMAIL PROTECTED] writes: On 9/27/07, Wayne Fay [EMAIL PROTECTED] wrote: On 9/26/07, Tomasz Pik [EMAIL PROTECTED] wrote: Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org ot Answer is: you never ever skip executing tests ;-) /ot -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/27/07, Insitu [EMAIL PROTECTED] wrote: Lally Singh [EMAIL PROTECTED] writes: On 9/27/07, Wayne Fay [EMAIL PROTECTED] wrote: On 9/26/07, Tomasz Pik [EMAIL PROTECTED] wrote: Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org ot Answer is: you never ever skip executing tests ;-) /ot Hehe, this was just an example, I can start finding out more examples but this is probably won't contribute anything good to this thread. Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/27/07, Antonio Petrelli [EMAIL PROTECTED] wrote: 2007/9/27, Graham Leggett [EMAIL PROTECTED]: The idea that it's free, what do you expect? quality? undermines confidence in both maven and open source in general, and this doesn't do the maven project any favours at all. Well in fact I think open source software has a higher level of quality when compared to proprietary software. Probably we all have seen proprietary code that is badly documented, written, engineered, etc. For example, I remember the story of Interbase DBMS (I can't find the link, sorry) when it was released as open source: the Firebird team had to fix 25000 compilation warnings! But think bigger: if you try to get docs from Oracle website, you will find almost nothing. If you want docs, you have to go to AskTom or some .edu websites :-( I'd argue that software quality's independent of it's open-ness. For open source, you have the argument that anybody can go in and fix it. Of course, any nontrivial software requires quite an investment to go in fix. For commercial software, you have someone that's got their paycheck depending on people's satisfaction with the software. Of course, you have monopolies where the customer has no choice. It really comes down to how the individual project is managed. Make quality a priority, and the software has high quality. Make it a low priority (e.g. it's free, I'm doing it in my spare time, if you don't like it, don't use it), and you won't have high quality. So, just b/c a project's open doesn't let people off the hook about quality. The open-source fairy won't come in one night and fix all your bugs or write your docs for you. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wiki was: Why Maven is Hard?
I would like to suggest better cross linking between the maven documents and the wiki. It is very hard for most users to modify the official maven documentation. If each plugin and main maven document had a reference to a sister wiki page then it would be easier for users to add their own two cents. The original document's authors could harvest the wiki for ideas when updating their documents. Example. Suppose I find some problem with the site plugin. I follow the wiki link on the site plugin's web page and go to it's sister wiki page. There I can look if anyone else has seen the problem, or I can add my own comments or workaround. It would also be nice if the Wiki's FAQ was not split into answered and unanswered sections. Thanks, C. Helck ** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the Information) is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates (ICAP) or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/27/07, Graham Leggett [EMAIL PROTECTED] wrote: This thread has highlighted the fact that the documentation doesn't help new users of maven, or users of maven who have no desire to become experts. Just dumping yet more documentation on this group of people isn't going to answer their questions. There are some questions that come up repeatedly on this ml. If you've subscribed for more than a few weeks and read most emails, you've already seen what I'm talking about. My personal pet peeve is the compiler target/source issue. In many of these common cases, the issue has been documented. Usually in the FAQ and in the Wiki and in the plugin docs too. Also it is documented well in Google and in the ml archive. And yet people still ask this question every 5-10 days and sometimes more often. How can you help people who ask this question (and others like it)? I agree that _more_ documentation is not necessarily the magic bullet that many believe it is. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
This thread has highlighted the fact that the documentation doesn't help new users of maven, or users of maven who have no desire to become experts. Just dumping yet more documentation on this group of people isn't going to answer their questions. There are some questions that come up repeatedly on this ml. If you've subscribed for more than a few weeks and read most emails, you've already seen what I'm talking about. My personal pet peeve is the compiler target/source issue. In many of these common cases, the issue has been documented. Usually in the FAQ and in the Wiki and in the plugin docs too. Also it is documented well in Google and in the ml archive. And yet people still ask this question every 5-10 days and sometimes more often. How can you help people who ask this question (and others like it)? I agree that _more_ documentation is not necessarily the magic bullet that many believe it is. The argument that some people don't read documentation so there is no point in writing any more is a non-sequitor. Please don't fall into that trap. My *personal* opinion about why *I* find maven so hard is the complete mental disconnect between the lifecycle phase (task) and the configuration, coupled with the voodoo of 'convention'. In ant, tasks seem to me to be the top-level view. In maven, goals and executions are embedded wy down the configuration and are necessary/unnecessary depending on what bindings were configured by annotations in the code that the developer thought were sensible (If I understand the documentation that I've read correctly :o} ). In maven, I tend to reach where I want to get in a similar fashion to a friend who got given a C++ project some time ago. He said to me that he finally got it all to compile and run by throwing various combinations of asterisks at it at random until I got something that worked. My pom file editing often feels like that. Later, Andy - Yada, yada, yada... Roslin Institute is a company limited by guarantee, registered in Scotland (registered number SC157100) and a Scottish Charity (registered number SC023592). Our registered office is at Roslin, Midlothian, EH25 9PS. VAT registration number 847380013. The information contained in this e-mail (including any attachments) is confidential and is intended for the use of the addressee only. The opinions expressed within this e-mail (including any attachments) are the opinions of the sender and do not necessarily constitute those of Roslin Institute (Edinburgh) (the Institute) unless specifically stated by a sender who is duly authorised to do so on behalf of the Institute. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
That sounds as easy as herding cats. Trying to get all the people on the user list to NOT do anything is unlikely. The fact is, as I see it, its easier to just give a quick answers to questions that strike my fancy than it is to hunt it down in the docs and point them to it. That allows me to limit the time I have available to invest in Maven. If I give the the URL directly, they don't know how to find it in the future. If I want to tell them which links to click to get there, its a pain for me. Its also likely to change in the future (as it has in the past when the docs were rearranged). FInally, typing in a list of things to click is error prone and easy to get wrong. Maybe someone (or ones) would volunteer to collect the questions from the newsgroup and transfer them to the site if someone else would reply to the interesting questions with some magic words that could be searched on. So, for example, I see what seems to me to be a FAQ with a useful answer in some thread on this list. I reply with the magic word FAQCANDIDATE in the reply. I picked one word because Google searches for two words differently than one word. Then the collectors could search for that word and come up with a short list of user list threads to mine for good FAQ entries. The only way I see that I would fail, besides nobody doing it, is if idiots invade the list and overuse the magic word. -- Lee Meador On 9/27/07, Wim Deblauwe [EMAIL PROTECTED] wrote: What about not answering any questions on the mailinglist anymore, but only point to existing documentation. If there is no suitable docs for the question, put in a JIRA issue. That should improve the docs fast! regards, Wim 2007/9/27, Wayne Fay [EMAIL PROTECTED]: On 9/26/07, Tomasz Pik [EMAIL PROTECTED] wrote: Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org OK, I'll bite... starting at http://maven.apache.org on the left, click on Wiki scroll down to Children, click on FAQs, see its not there click on previously answered questions (or click back and click on FAQs-1) oh look, there it is -- Testing How do I skip unit tests when building a project? Admittedly, I'm not sure why we have 2 FAQ pages in the Wiki, plus another FAQ on the main Maven site. But I also don't think this is all that horrible. Obviously you can't expect to find every answer this easily but common questions should be. So the next step seems (to me at least) to be determining what are those common questions, as I mentioned in Brian's thread on improving site docs. This is something that users like yourself must participate in if we hope to have any chance of success in this effort. (Also if you Google for maven skip unit test there's a number of hits right away. I personally feel that answers found via Google are no less valid than others, especially if you add the site:maven.apache.org directive. To say nothing of all the hits in the mail list archive if you search for this.) Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Vigilog - an open source log file viewer: http://vigilog.sourceforge.net Blog: http://www.jroller.com/page/Fester -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
Re: Why Maven is Hard?
How can you help people who ask this question (and others like it)? I agree that _more_ documentation is not necessarily the magic bullet that many believe it is. The argument that some people don't read documentation so there is no point in writing any more is a non-sequitor. Please don't fall into that trap. I simply want to make sure that we remember all the various documentation problems while discussing this topic... One possible way to fix the problem I've mentioned (annotations are not supported in -source 1.3) would be to add code in compiler plugin that watches for that specific problem, and instead of simply printing that generic error message, it prints a better error message that tells the person how to configure things to make it go away, or provides a link to the Wiki with a complete discussion and the configuration. I don't think that is a reasonable way to fix all the problems people run into, but for the most common cases, it might make some sense. What other common cases might be handled with this approach? Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Andy,
You said, My *personal* opinion about why *I* find maven so hard is the
complete
mental disconnect between the lifecycle phase (task) and the
configuration, coupled with the voodoo of 'convention'.
I think thats an amazingly concise description of what is hard about Maven.
I do think the solution is to document things like recipes.
I don't know why adding some sugar to spaghetti sauce makes it better (for
my family) but its in the recipe and I don't have to know.
I don't have to know why that magic bit of XML works but if I want to use
Ant to generate some source code (because my code generator has an Ant task)
then I put in this and, maybe, change the Ant target and the 'generated
sources' folder.
build
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
idgensrc/id
phasegenerate-sources/phase
configuration
tasks
ant antfile=build.xml dir=. target=generate
inheritRefs=true /
/tasks
sourceRoot${project.build.directory
}/generated-sources/java/sourceRoot
/configuration
goals
goalrun/goal
/goals
/execution
/executions
/plugin
plugins
build
I have enough pom.xml files to be able to go steal bits of them when I need
to do something like that. I have begun to understand how that all fits into
the lifecycle and why it works. I suspect there is an example somewhere on
the web site or in this user list where I got it originally, before I had a
clue why it worked.
I think, that is the reason, this thread has seen so much emphasis on
collecting FAQ entries. These little examples make it easy to make your
build work and you don't have to know why.
Perhaps a POM editor that had a bunch of XML snippets would be useful. Then
the Maven user would need even less information on the internals. (That idea
is not patented. Feel free to implement it if you want.) Of course, some
problems would require close attention to how Maven works and after all the
easy build problems were solved and all the non-standard stuff was converted
to Maven standards the user would have an investment in Maven that would
make it worth figuring out the hard things.
(That does ignore the fact that sometimes you decide to go against Maven
conventions because you decide to follow the conventions for some other
tool. Some that come to my mind are Eclipse, RAD and its derivatives,
MyEclipse and pretty much any Application Server.)
Thanks.
-- Lee
On 9/27/07, andy law (RI) [EMAIL PROTECTED] wrote:
This thread has highlighted the fact that the documentation doesn't
help new users of maven, or users of maven who have no desire to
become experts. Just dumping yet more documentation on this
group of
people isn't going to answer their questions.
There are some questions that come up repeatedly on this ml.
If you've subscribed for more than a few weeks and read most
emails, you've already seen what I'm talking about. My
personal pet peeve is the compiler target/source issue.
In many of these common cases, the issue has been documented.
Usually in the FAQ and in the Wiki and in the plugin docs
too. Also it is documented well in Google and in the ml
archive. And yet people still ask this question every 5-10
days and sometimes more often.
How can you help people who ask this question (and others
like it)? I agree that _more_ documentation is not
necessarily the magic bullet that many believe it is.
The argument that some people don't read documentation so there is no
point in writing any more is a non-sequitor. Please don't fall into
that trap.
My *personal* opinion about why *I* find maven so hard is the complete
mental disconnect between the lifecycle phase (task) and the
configuration, coupled with the voodoo of 'convention'. In ant, tasks
seem to me to be the top-level view. In maven, goals and executions are
embedded wy down the configuration and are necessary/unnecessary
depending on what bindings were configured by annotations in the code
that the developer thought were sensible (If I understand the
documentation that I've read correctly :o} ). In maven, I tend to reach
where I want to get in a similar fashion to a friend who got given a C++
project some time ago. He said to me that he finally got it all to
compile and run by throwing various combinations of asterisks at it at
random until I got something that worked. My pom file editing often
feels like that.
Later,
Andy
-
Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in
Scotland (registered number SC157100) and a Scottish Charity (registered
number SC023592). Our registered office is at Roslin, Midlothian, EH25
9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is
confidential and is intended for the use of the addressee only. The
opinions
RE: Why Maven is Hard?
This book rocks especially the chapter 15 on j2ee. After spending weeks trying to build similar simple project in maven, it's great to find this, thanks. Now, I'll try to convert this from Geronimo to WebLogic, in case of success I'll share. -- Gael -Original Message- From: Brian E. Fox [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 11:51 PM To: Maven Users List Subject: RE: Why Maven is Hard? There is a newer book available at http://sonatype.com/book (no registration required and it's html so you can just hop in and out as needed) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
Most of the site is generated and is in svn. You can check out the site from here: http://svn.apache.org/repos/asf/maven/site/trunk and run mvn site to generate it in target/site. Then you can create patches and put them in jira. You may need to add the snapshot repo to your settings if the site is using any snapshots. -Original Message- From: Lally Singh [mailto:[EMAIL PROTECTED] Sent: Thursday, September 27, 2007 6:34 AM To: Maven Users List Subject: Re: Why Maven is Hard? Ok, enough complaining out of me. If I could change all the files directly, I would. But, here are what I think would really help ASAP. 1. The front-page link to the 'Users Center' should instead point to the Maven Documentation Index http://maven.apache.org/guides/index.html. It's really the starting point for documentation, so put it there. 2. The big FAQ is the 'Answered Questions' in the Wiki. Link to that instead of the existing one (http://maven.apache.org/general.html). -- I just got an account with the wiki. Today I'll copy any FAQs in that page back to the Wiki page, so we don't lose anything. 3. Some general Re-org of that 'Documentation' tab on the left-side navigation. Some of those pages are just links to others, and can be collapsed. Others seem like articles. Ok, screw it, I'm in all the way. How can I contribute new content? I'll start doing a basic manual for Maven. Not that I know much about it, but I'll start squeezing that out of the source, existing docs, mailing list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Here are some random thoughts. What would happen if mvn help printed out . mvn faq plugin - faq for the plugin mvn myfaq - your personal faq (creates a personal site/maven-faq.xml ) mvn faqreport - reports something that you think should be an faq mvn faqreport would generate a xml formated file with the person's faq (with answer if they have it) so that common faq could be managed and disseminated. Random question .. ***How come mvn has all these facilities for uploading/downloading files and it is not being applied to spread documentation? ** ** how come mvn doesn't have any mvn specific way to contribute patches to either documentation, maven core or a plugin? Shouldn't I be able to run mvn sendpatch in a plugin's directory and have it do a diff with svn and send the patch to jira ? On 9/27/07, Wayne Fay [EMAIL PROTECTED] wrote: How can you help people who ask this question (and others like it)? I agree that _more_ documentation is not necessarily the magic bullet that many believe it is. The argument that some people don't read documentation so there is no point in writing any more is a non-sequitor. Please don't fall into that trap. I simply want to make sure that we remember all the various documentation problems while discussing this topic... One possible way to fix the problem I've mentioned (annotations are not supported in -source 1.3) would be to add code in compiler plugin that watches for that specific problem, and instead of simply printing that generic error message, it prints a better error message that tells the person how to configure things to make it go away, or provides a link to the Wiki with a complete discussion and the configuration. I don't think that is a reasonable way to fix all the problems people run into, but for the most common cases, it might make some sense. What other common cases might be handled with this approach? Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Hi Elizabeth, Please use the http://docs.codehaus.org/display/MAVENUSER/ wiki pages. Raphaël 2007/9/26, Sommers, Elizabeth [EMAIL PROTECTED]: -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] What I want is an active mailing list for plugin developers. I have written too many plugins with less than stellar testing harnesses and tools. The developers' mailing list is not the right place to discuss plugins. I think that maven itself has got pretty stable. The problem is that the plugins are NOT stable and vary in quality. I have now written more ant and maven than I care to think about (I am a build/release engineer). I know there are things I have found that other people might be interested in. I know that other people have solved other problems. I would like to be discussing these solutions in a forum where I am not boring either new users or the developers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
I have exactly the same experience and feelings. Maven's philosophy is what motivates you to use it and then as soon as you start working on non trivial enterprise projects you find yourself spending most of your time on implementing workarounds for plugins that are poorly documented, not really working or addressing only simple use cases. You provide patches to plugin author and then you must maintain your version until he has integrated and released your changes. I can see a lot of plugins that seem to be no longer actively developed. So, when you're considering migrating to Maven, you list your requirements and see OK there's a plugin for doing this and this, etc... And when you really try to make them work, it's never as easy as it was supposed to be. So, when you recommend migrating to Maven you got to be prepared to invest a lot of energy in it and to get criticism from your project team. One thing about the users mailing list, due to Maven's stiff learning curve, beginners have difficulties expressing their questions, it's also due to the difficulty to diagnose maven issues. So you get questions that nobody understands and can answer. Searching the archives, I often someone with the same problem I have but rarely the solution, and sometimes I think it's because the problem was not clearly explained. Ant is easier to diagnose, if you got a problem you can post your snippet to the list and people will understand your problem even if you did not express it well. Making Maven easier to diagnose is probably a worthwhile effort. -- Gael -Original Message- From: Kevin Jackson [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 7:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? In my opinion, those that have succeeded with mvn have been 1 of 2 types: 1 - using mvn for simple tasks 2 - mvn developers I currently have a project I'm working on which has a multi-stage build and requires several 3rd-party mvn plugins. Getting this to work correctly has been a nightmare - there's no other way of describing the frustration with the lack of documentation of the core of mvn. Now we also had some specialised requirements (as is often the case), so I've had to write and maintain 4 custom plugins for our build. So from last November (mvn newbie) to now I've done a considerable amount of mvn hacking, including supplying patches for plugins and writing new plugins. mvn internally has appalling docs, there's practically no javadoc in the project - this makes writing patches to mvn itself tedious and frustrating - and *I want to get involved*. For someone who isn't interested in getting involved, but they need to fix a bug in mvn (and yes mvn has bugs), they open the sources and see undocumented code - that's a massive turn off. Perhaps I'm in the minority, but the mvn mailing lists (users/dev) are not the source of answers I thought they would be - I've asked a few questions on how to configure a plugin/build to achieve the output I wanted - and no there wasn't a reply with an answer. Here is an example: The mvn-war-plugin (which combined with the jspc-plugin should allow me to only create a war with .class files (no jsps included)). By default, this plugin includes everything, so setting warSourceExcludes to exclude the jsp files is the solution - except it isn't. If you set warSourceExcludes to exclude the unnecessary jsp files, it still includes the empty dirs that the jsps were in - this makes my war larger than it should be. If I manually specify exactly what to include I get a massive warSourceIncludes section (which must be repeated in each profile as mvn plexus don't support xml entity fragments eg warSources;) I'd like to modify the mvn-war-plugin source to exclude empty dirs, but again the code isn't well documented and I'd have to maintain a custom version of this plugin instead of using the normal one available on ibiblio/maven2 (I already maintain a custom jspc plugin as it's being re-written in groovy at the moment and is dependent on a broken version of ant which has a URI bug) It's a big short sighted to even assume that someone would say, Go pour through the source and write documentation. That's also quite a bit overly dramatic. If I had to pour through source in order to learn how to use Maven, I would have sucked it up and moved on. Welcome to my world - to get anything done (writing mvn plugins, fixing bugs in plugins we use etc), this is exactly what I have to do - and no it isn't overly dramatic, I have to read the src for various plugins and mvn just to work out what is happening as there are no API docs. Often the plugin svn repo has changed location and the site hasn't been updated, so then you have to hunt down the correct svn location using trial and error - again this is a doc issue (jspc plugin had exactly this problem) Once again I reiterate, if you
RE: Why Maven is Hard?
Another thing that is hard in Maven is solving classpath issues. Classpath issues can be hard to solve in java but in Maven it is even harder because your plugin inherits from a classpath built by maven from your dependencies and others as well. So when something fails, you must understand who did add this jar to your classpath and why was it added in this particular order. -- Gael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
mvn -X what more can you ask for? mvn dependency:resolve mvn help:effective-pom On Thursday 27 September 2007 00:28, Marziou, Gael wrote: Another thing that is hard in Maven is solving classpath issues. Classpath issues can be hard to solve in java but in Maven it is even harder because your plugin inherits from a classpath built by maven from your dependencies and others as well. So when something fails, you must understand who did add this jar to your classpath and why was it added in this particular order. -- Gael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
I have to agree with the comments in this thread. Asking someone to contribute documentation for a plugin they didn't write is pretty lame. How about not letting someone submit a plugin until not only has the code been tested/proven, but the associated documentation is up to snuff? I don't know how it works where ever you guys are working but when code is committed to our SCM system here, a code review has to pass. Part of that review is to go over the associated documentation. Also, I've spent hours upon hours chasing my tail on things like the bug where profiles weren't ordered in the order specified on the commandline (it seemed partially random and then partially due to ordering in settings.xml/profiles.xml). After many days of silence on both mailing lists, we pulled down the source and realized that it was a bug, fixed it, and then saw a new release of maven 2 come out that did the same thing. We've also noticed that classpaths aren't as controlled as we would have liked. A scenario is - three modules at the same level, two branched away as to be built in isolation. All of a sudden the third module can't find any classes that the first two put into the compile classpath - and this is the case if/if not there are dependencies on these modules to/from each other. I'd also like to echo the sentiment, maven is great if you're doing standard stuff and maven is HORRIBLE when you're trying to do anything out of the norm. I feel like it's easier to just write my own plugin than it is to scour the maven site in hopes of finding something suitable to my needs. Additionally, twice now we've started using a plugin just to find that it has been abandoned for a less buggy plugin. Where's the repository management documentation (how to set one up at your company, how to keep it up-to-date, etc.)? I work at a relatively large company and I can't believe for a second other companies similarly sized or bigger would want developer groups going across the internet the way maven tries to do (for plugins and dependencies). This also makes overseas development challenging. Look, I think many people are wanting a build tool better than shell scripting and make, possibly easier than ant - but something with less of a learning curve of maven 1 or 2. I think ant is REALLY smooth and easy to code/understand. To say that ant is challenging in any way/shape/form is to deny the truth. Maven 2 build/release engineering does get easier with time, but we all don't have limitless time to learn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
And this is where in/on the site? What about an option to maven that gives a list of goals like ant did with targets? One outstanding thing that ant did was self documentation. I miss that... -Original Message- From: Michael McCallum [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 9:20 AM To: Maven Users List Subject: Re: Why Maven is Hard? mvn -X what more can you ask for? mvn dependency:resolve mvn help:effective-pom On Thursday 27 September 2007 00:28, Marziou, Gael wrote: Another thing that is hard in Maven is solving classpath issues. Classpath issues can be hard to solve in java but in Maven it is even harder because your plugin inherits from a classpath built by maven from your dependencies and others as well. So when something fails, you must understand who did add this jar to your classpath and why was it added in this particular order. -- Gael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
-Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] What I want is an active mailing list for plugin developers. I have written too many plugins with less than stellar testing harnesses and tools. The developers' mailing list is not the right place to discuss plugins. I think that maven itself has got pretty stable. The problem is that the plugins are NOT stable and vary in quality. I have now written more ant and maven than I care to think about (I am a build/release engineer). I know there are things I have found that other people might be interested in. I know that other people have solved other problems. I would like to be discussing these solutions in a forum where I am not boring either new users or the developers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
I think you expressed things very well. Maven is great for fairly trivial projects, but once you have a complicated build or deployment requirement, it is very hard to find out whether or how you can meet your requirements. And many of the existing plugins are indeed poorly documented. Our most complex application build involves a horribly complex Ant script - but as yet I'd be reluctant to recommend moving it to Maven, although if possible that would be fantastic. Maybe we'll do it piecemeal. Perhaps more effort needs to be expended in finding out why builds get so complicated - this seems to be against the Maven ethos. I don't think the complexities we have are unusual though. John 8 The problem is that people use mvn to begin with, with a simple project and think 'wow it's so easy', then when used in more complex circumstances, the documentation falls flat and the non-dedicated, willing-to-peruse-src-code user will be put off. I'm looking forward to see what other people think, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. Eurobase Systems Limited is the main trading company in the Eurobase International Group; registered in England and Wales as company number 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE, UK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I highly recommend: Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
As I recommended earlier, I think we should copy and paste the Better Builds with Maven book into the official Maven documentation. Why not? Of course, permission would need to be asked to the author first, but I'm sure he wouldn't mind. Regards, Rodrigo On 9/26/07, Brian Flaherty [EMAIL PROTECTED] wrote: I highly recommend: Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: As I recommended earlier, I think we should copy and paste the Better Builds with Maven book into the official Maven documentation. Why not? The book is already free. (Yes, you have to register.) There's another very good book at http://www.sonatype.com/book/ . Copying and pasting that content would not solve the problem that the Maven site is considered difficult to navigate. And that despite all the improvements in plugin docs, people still find then inadequate. (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Thinking about it, it seems like the mojo-dev list would be the right place for Maven plugin development discussion. Its just not very high traffic at this point. Probably if you joined and started posting questions etc, we could turn it into the mailing list we want/need with active participation. I'm sure other plugin devs like myself would appreciate this kind of forum. Wayne On 9/26/07, Sommers, Elizabeth [EMAIL PROTECTED] wrote: What I want is an active mailing list for plugin developers. I have written too many plugins with less than stellar testing harnesses and tools. The developers' mailing list is not the right place to discuss plugins. I think that maven itself has got pretty stable. The problem is that the plugins are NOT stable and vary in quality. I have now written more ant and maven than I care to think about (I am a build/release engineer). I know there are things I have found that other people might be interested in. I know that other people have solved other problems. I would like to be discussing these solutions in a forum where I am not boring either new users or the developers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
There might be enough discrete Maven subject areas to justify something more like a BB, eg like JavaRanch? I get a lot of mails from here that are for topics I know nothing about and are unlikely to dabble with. John -Original Message- From: Wayne Fay [mailto:[EMAIL PROTECTED] Sent: 26 September 2007 16:38 To: Maven Users List Subject: Re: Why Maven is Hard? Thinking about it, it seems like the mojo-dev list would be the right place for Maven plugin development discussion. Its just not very high traffic at this point. Probably if you joined and started posting questions etc, we could turn it into the mailing list we want/need with active participation. I'm sure other plugin devs like myself would appreciate this kind of forum. Wayne On 9/26/07, Sommers, Elizabeth [EMAIL PROTECTED] wrote: What I want is an active mailing list for plugin developers. I have written too many plugins with less than stellar testing harnesses and tools. The developers' mailing list is not the right place to discuss plugins. I think that maven itself has got pretty stable. The problem is that the plugins are NOT stable and vary in quality. I have now written more ant and maven than I care to think about (I am a build/release engineer). I know there are things I have found that other people might be interested in. I know that other people have solved other problems. I would like to be discussing these solutions in a forum where I am not boring either new users or the developers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. Eurobase Systems Limited is the main trading company in the Eurobase International Group; registered in England and Wales as company number 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE, UK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
Everyone is bashing the plugin docs. Can you be more specific about which ones and what's not good? Are we talking about plugins on Apache or ones at Codehaus or somewhere else? -Original Message- From: EJ Ciramella [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 9:37 AM To: Maven Users List Subject: RE: Why Maven is Hard? I have to agree with the comments in this thread. Asking someone to contribute documentation for a plugin they didn't write is pretty lame. How about not letting someone submit a plugin until not only has the code been tested/proven, but the associated documentation is up to snuff? I don't know how it works where ever you guys are working but when code is committed to our SCM system here, a code review has to pass. Part of that review is to go over the associated documentation. Also, I've spent hours upon hours chasing my tail on things like the bug where profiles weren't ordered in the order specified on the commandline (it seemed partially random and then partially due to ordering in settings.xml/profiles.xml). After many days of silence on both mailing lists, we pulled down the source and realized that it was a bug, fixed it, and then saw a new release of maven 2 come out that did the same thing. We've also noticed that classpaths aren't as controlled as we would have liked. A scenario is - three modules at the same level, two branched away as to be built in isolation. All of a sudden the third module can't find any classes that the first two put into the compile classpath - and this is the case if/if not there are dependencies on these modules to/from each other. I'd also like to echo the sentiment, maven is great if you're doing standard stuff and maven is HORRIBLE when you're trying to do anything out of the norm. I feel like it's easier to just write my own plugin than it is to scour the maven site in hopes of finding something suitable to my needs. Additionally, twice now we've started using a plugin just to find that it has been abandoned for a less buggy plugin. Where's the repository management documentation (how to set one up at your company, how to keep it up-to-date, etc.)? I work at a relatively large company and I can't believe for a second other companies similarly sized or bigger would want developer groups going across the internet the way maven tries to do (for plugins and dependencies). This also makes overseas development challenging. Look, I think many people are wanting a build tool better than shell scripting and make, possibly easier than ant - but something with less of a learning curve of maven 1 or 2. I think ant is REALLY smooth and easy to code/understand. To say that ant is challenging in any way/shape/form is to deny the truth. Maven 2 build/release engineering does get easier with time, but we all don't have limitless time to learn. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
It seems very odd to me that the Maven book *isn't* on the maven site: the place I would go to look for documentation. Why put another hurdle of going elsewhere and registering? I registered had to wait a few hours to get the email, it seemed a bit ridiculous. I agree that it isn't going to make everything better but surely it will help new people like me! Richard -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: 26 September 2007 16:05 To: Maven Users List Subject: Re: Why Maven is Hard? On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: As I recommended earlier, I think we should copy and paste the Better Builds with Maven book into the official Maven documentation. Why not? The book is already free. (Yes, you have to register.) There's another very good book at http://www.sonatype.com/book/ . Copying and pasting that content would not solve the problem that the Maven site is considered difficult to navigate. And that despite all the improvements in plugin docs, people still find then inadequate. (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I totally agree with you. Make the Better Builds book available directly through the Maven site WITHOUT registration. That would make a big difference. Yours, Rodrigo On 9/26/07, Richard Chamberlain [EMAIL PROTECTED] wrote: It seems very odd to me that the Maven book *isn't* on the maven site: the place I would go to look for documentation. Why put another hurdle of going elsewhere and registering? I registered had to wait a few hours to get the email, it seemed a bit ridiculous. I agree that it isn't going to make everything better but surely it will help new people like me! Richard -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: 26 September 2007 16:05 To: Maven Users List Subject: Re: Why Maven is Hard? On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: As I recommended earlier, I think we should copy and paste the Better Builds with Maven book into the official Maven documentation. Why not? The book is already free. (Yes, you have to register.) There's another very good book at http://www.sonatype.com/book/ . Copying and pasting that content would not solve the problem that the Maven site is considered difficult to navigate. And that despite all the improvements in plugin docs, people still find then inadequate. (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
You would need to talk to Devzuz and/or Sonatype about that. Those companies created the books and therefore control access to them. Collecting people's information through registration is one of the ways they find new potential customers. I don't think the registration requirement is all that onerous. If you feel so strongly about this, feel free to spend literally months creating a similar product and license it such that it can be made available free on the Maven website. Wayne On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: I totally agree with you. Make the Better Builds book available directly through the Maven site WITHOUT registration. That would make a big difference. Yours, Rodrigo On 9/26/07, Richard Chamberlain [EMAIL PROTECTED] wrote: It seems very odd to me that the Maven book *isn't* on the maven site: the place I would go to look for documentation. Why put another hurdle of going elsewhere and registering? I registered had to wait a few hours to get the email, it seemed a bit ridiculous. I agree that it isn't going to make everything better but surely it will help new people like me! Richard -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: 26 September 2007 16:05 To: Maven Users List Subject: Re: Why Maven is Hard? On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: As I recommended earlier, I think we should copy and paste the Better Builds with Maven book into the official Maven documentation. Why not? The book is already free. (Yes, you have to register.) There's another very good book at http://www.sonatype.com/book/ . Copying and pasting that content would not solve the problem that the Maven site is considered difficult to navigate. And that despite all the improvements in plugin docs, people still find then inadequate. (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/26/07, Wendy Smoak [EMAIL PROTECTED] wrote: (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) YES. Right now the docs tend to look 100% autogenerated and be 0% useful. It's tough to find the useful material in all the autogenerated and unnecessary fluff. Just a description of all the options (e.g. reference documentation) and an example is all I'm asking for. Some boilerplate in there in how to set up plugins (in general) would also be nice. On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: Make the Better Builds book available directly through the Maven site WITHOUT registration. That'd be nice. Even before hearing back from the respective authors, HOW ABOUT LINKING TO THEM I don't mind registering. I mind finding out about the book randomly from the mailing list or google. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Denis Bessmertniy [EMAIL PROTECTED]: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. Here are the problems I have had: - unclear where maven ends and plugins take over - unclear what versions of the plugins are in use - unclear where the plugins come from, and who are responsible - sparse documentation, where the docs on the web may be for a different version of the plugin than the one you're using (I've seen a case where the documentation on the web was for a version of the plugin that hadn't been relased yet) - bugs in the plugins that require workarounds (and different people deploying maven at different points in time, may end up with different versions of the plugins which require different workarounds) - a bug in maven proper that has stuck us on version 2.0.4 These are from the top of my head. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Lally Singh schrieb: [...] That'd be nice. Even before hearing back from the respective authors, HOW ABOUT LINKING TO THEM I don't mind registering. I mind finding out about the book randomly from the mailing list or google. Just open the maven website and click on Documentation-External Resources. Is that too hard to find? Where would you place the links? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
The user center. Sorry, didn't mean to be so harsh about it. But when I see 5 tiny links on the user center, I see that there isn't much documentation on the site. I stop looking on the site for anything else -- I hit google. On 9/26/07, Tim Kettler [EMAIL PROTECTED] wrote: Lally Singh schrieb: [...] That'd be nice. Even before hearing back from the respective authors, HOW ABOUT LINKING TO THEM I don't mind registering. I mind finding out about the book randomly from the mailing list or google. Just open the maven website and click on Documentation-External Resources. Is that too hard to find? Where would you place the links? -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
There is a newer book available at http://sonatype.com/book (no registration required and it's html so you can just hop in and out as needed) -Original Message- From: Richard Chamberlain [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 1:36 PM To: Maven Users List Subject: RE: Why Maven is Hard? It seems very odd to me that the Maven book *isn't* on the maven site: the place I would go to look for documentation. Why put another hurdle of going elsewhere and registering? I registered had to wait a few hours to get the email, it seemed a bit ridiculous. I agree that it isn't going to make everything better but surely it will help new people like me! Richard -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: 26 September 2007 16:05 To: Maven Users List Subject: Re: Why Maven is Hard? On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: As I recommended earlier, I think we should copy and paste the Better Builds with Maven book into the official Maven documentation. Why not? The book is already free. (Yes, you have to register.) There's another very good book at http://www.sonatype.com/book/ . Copying and pasting that content would not solve the problem that the Maven site is considered difficult to navigate. And that despite all the improvements in plugin docs, people still find then inadequate. (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/26/07, Wendy Smoak [EMAIL PROTECTED] wrote: On 9/26/07, Rodrigo Madera [EMAIL PROTECTED] wrote: As I recommended earlier, I think we should copy and paste the Better Builds with Maven book into the official Maven documentation. Why not? The book is already free. (Yes, you have to register.) There's another very good book at http://www.sonatype.com/book/ . Copying and pasting that content would not solve the problem that the Maven site is considered difficult to navigate. And that despite all the improvements in plugin docs, people still find then inadequate. (There *is* a doc standard that they have to pass prior to being promoted from the sandbox and released. Does it need to be changed?) I think - yes. See spring and hibernate docs - all thing in one long document (which may be browsed chapter by chapter but also downloaded and printed as PDF). I'm sure many users will say 'those examples are bad because of...' but I think this would be better for maven to have one document describing things from pom structure and standard directory layout to use cases of (for example) ear plugin Maybe some very magic scrips merging together guides from current main maven site and plugin documentations? I know that ability to make good things with plugins (== some kind of modularity of maven architecture) is a GOOD thing but without a good understanding it's hard to where to find out an info about some basic thing. Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org Regards, Tomek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/26/07, Tomasz Pik [EMAIL PROTECTED] wrote: Example - please, try to find out how to skip executing of tests during build starting from http://maven.apache.org OK, I'll bite... starting at http://maven.apache.org on the left, click on Wiki scroll down to Children, click on FAQs, see its not there click on previously answered questions (or click back and click on FAQs-1) oh look, there it is -- Testing How do I skip unit tests when building a project? Admittedly, I'm not sure why we have 2 FAQ pages in the Wiki, plus another FAQ on the main Maven site. But I also don't think this is all that horrible. Obviously you can't expect to find every answer this easily but common questions should be. So the next step seems (to me at least) to be determining what are those common questions, as I mentioned in Brian's thread on improving site docs. This is something that users like yourself must participate in if we hope to have any chance of success in this effort. (Also if you Google for maven skip unit test there's a number of hits right away. I personally feel that answers found via Google are no less valid than others, especially if you add the site:maven.apache.org directive. To say nothing of all the hits in the mail list archive if you search for this.) Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Dennis Lundberg wrote: Don't let the fact that you're not a native English speaker stop you from contributing to the documentation. I'm not a native English speaker myself and started out here at the Maven project by improving the documentation. Reading your mails on this list, I can say that your English skills are good enough for writing Maven documentation in English ;-) If you really think so ... I did not dare ... O.k., I'll try it. I assume the current online docs are for the version 2.0.7 of Maven and I should create patches using that branch. Is that right? I hope the committers are proofreading my stuff carefully. BTW (in case anyone got a different impression): I consider Maven an outstanding build tool indeed. It's standardization of the build process, it's dependency management and the numerous reports are of great value for enterprise development. -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Gisbert Amm wrote: O.k., I'll try it. I assume the current online docs are for the version 2.0.7 of Maven and I should create patches using that branch. Just immediately after that posting I found out that the maintainance branch obviously is maven-2.0.x Never mind. -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Documentation is 100% the largest weakpoint of maven. On 9/24/07, Steve Mactaggart [EMAIL PROTECTED] wrote: Case in point http://maven.apache.org/guides/mini/guide-multi-module.html Something that is really useful, but still non existant. Another datapoint: I've read both books, been using it daily since January, and still don't feel like I have a handle of how it all works. Whatever tutorial information out there has to explain, at some level, of the steps data maven uses to do what it does. In ant, it's simple: the tags describe the procedures used. In maven, so much of it is implicit (but un/under documented) that it's tough to see what's going on. A description of maven's internal procedures is needed -- to turn that black box white. There's no fundamental reason why maven can't be well documented. _Just tell us how the thing works_. From that, you can describe how other things hook onto maven, and thusly how it and the plugins work. It's also a great way to entice developers to contribute, if they already have a working idea of how the system works internally. Also, some basic listing functionality of what maven takes in would be nice. Even if it's web based. I've found mvnrepository.org to be great, but that's something I found via googling. But how about something for archetypes? I've found something now and then through extensive googling, but this really should be on the 1st page of documentation for maven. As should a search box for mvnrepository. That's probably the best first test to use for the quality of maven's docs: how much can you figure out and use without having to hit google? Just using maven.apache.org, how functional is a new developer? Mailing lists are another thing I'd blacklist from this test. If someone has to ask about something on the mailing list, the documentation has failed. And while plugins having entire sites is nice, it'd be great if we could generate a reference manual (even if it's another HTML website) that covers every plugin that we're using in a project. If it's there, I haven't found it. This isn't to discourage the existing documentation efforts -- but prioritize documentation to be #1. I think for most users, maven's good enough by far, and a lot better than the competition. The advantages it gives are well worth it, _if_ they could figure out how to use it. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
Now I'm making build procedure with maven for a large j2ee project. We use WebSphere 6. And I cannot find maven plugin fo it. Only for 5 is available. I spend more than a week for this build procedure and I see that it will be hard to use it for our team. Maven docs are time consuming. Now I recall words from one of our team member: I my last project we started to use maven and then we refused to use it because it was hard. Then we started to use Ant, and that is ok. -Original Message- From: Lally Singh [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 3:21 PM To: Maven Users List Subject: Re: Why Maven is Hard? Documentation is 100% the largest weakpoint of maven. On 9/24/07, Steve Mactaggart [EMAIL PROTECTED] wrote: Case in point http://maven.apache.org/guides/mini/guide-multi-module.html Something that is really useful, but still non existant. Another datapoint: I've read both books, been using it daily since January, and still don't feel like I have a handle of how it all works. Whatever tutorial information out there has to explain, at some level, of the steps data maven uses to do what it does. In ant, it's simple: the tags describe the procedures used. In maven, so much of it is implicit (but un/under documented) that it's tough to see what's going on. A description of maven's internal procedures is needed -- to turn that black box white. There's no fundamental reason why maven can't be well documented. _Just tell us how the thing works_. From that, you can describe how other things hook onto maven, and thusly how it and the plugins work. It's also a great way to entice developers to contribute, if they already have a working idea of how the system works internally. Also, some basic listing functionality of what maven takes in would be nice. Even if it's web based. I've found mvnrepository.org to be great, but that's something I found via googling. But how about something for archetypes? I've found something now and then through extensive googling, but this really should be on the 1st page of documentation for maven. As should a search box for mvnrepository. That's probably the best first test to use for the quality of maven's docs: how much can you figure out and use without having to hit google? Just using maven.apache.org, how functional is a new developer? Mailing lists are another thing I'd blacklist from this test. If someone has to ask about something on the mailing list, the documentation has failed. And while plugins having entire sites is nice, it'd be great if we could generate a reference manual (even if it's another HTML website) that covers every plugin that we're using in a project. If it's there, I haven't found it. This isn't to discourage the existing documentation efforts -- but prioritize documentation to be #1. I think for most users, maven's good enough by far, and a lot better than the competition. The advantages it gives are well worth it, _if_ they could figure out how to use it. -- H. Lally Singh Ph.D. Candidate, Computer Science Virginia Tech - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I always find this [1] a good starting point for the internal lifecycle and packaging workings of Maven. Hth, Nick Stolwijk [1] http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html In maven, so much of it is implicit (but un/under documented) that it's tough to see what's going on. A description of maven's internal procedures is needed -- to turn that black box white. There's no fundamental reason why maven can't be well documented. _Just tell us how the thing works_. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
No it's not a catch 22. I will clarify what I was saying in my other statement. People have exactly 2 choices when faced with a problem such as documentation. The first one is to say, Boy this product is too hard for me to learn and there isn't enough documentation, so I'll go find something else. The second option is to say, Boy this product is hard, but I really think it could help me on my product so I will learn how to use it and ask questions on the list. Then, because I had so much trouble starting, I will recontribute back what I learned to the project. No one is forcing anyone to do anything. That's the beauty and bane of free software. In order for it to be free, someone has to invest THEIR time to provide you the free software. If you don't like it, you can move on without losing a monetary investment. The bane is that because the contributers/developers aren't usually getting paid, they have to have other jobs where they make their living. To demand that they make sure you get the documentation that you want rather than keep up with regular features for others that don't need the documentation isn't fair either. Others like me have been fine without the documentation, so the question is more why have some succeeded and others failed? It's a big short sighted to even assume that someone would say, Go pour through the source and write documentation. That's also quite a bit overly dramatic. If I had to pour through source in order to learn how to use Maven, I would have sucked it up and moved on. Once again I reiterate, if you take it step by step then you will be fine. Ant is NOT any easier to create a build system with. For non multiproject builds, there is no reason that someone shouldn't be able to read the getting started and have a webapp up in a few minutes. I had a webapp archetype built and up with minutes, and that's enough for just a regular website. All you do then, is add your pages and content. If you need more, then add a bit at a time. Then if they don't understand how it worked, go ask questions. Simply complaining solves nothing and makes the people doing the hard work feel unappreciated because the product they are giving out free just doesn't seem to be enough to make people happy. If they had the time to really beef up the documentation, then I'm sure they would but there is only so much you can accomplish with limited time. No problem Larry, constructive criticism is great feedback for a project and no one should ever be afraid to give it, but I see all way too much people complaining about something that people put hard work into without giving any sort of solution on how the problem could be rectified. How can you expect someone to fix something if you cannot come up with a solution to the problem yourself? This is also besides the fact that not everyone seems to have a problem getting started. I've seen people get tripped up on instructions that were written so a baby could understand them. There is no guarantee that if they invested the time writing all this documentation, that people wouldn't still have questions. People would then start complaining that the documentation isn't kept up to date or it sucks because it's not enough for them. People are rarely ever satisfied no matter how much you give them. On 9/24/07, Larry Meadors [EMAIL PROTECTED] wrote: Isn't this sort of a catch-22? People are saying I don't get maven, it's too complex. Now it's time for them to give something back and document it? How do you propose they do that? Start at the source and pore through it to explain it? Saying that is sort of a cop-out, IMO. I think that the problem is that we have maven in 5 minutes and then the rest of the docs assume that people are experts with it - the 2 books mentioned earlier are useful, but I think people want something more approachable and contextual. One other thing is the navigation - I find it very difficult to get around the maven site in any meaningful way. There are many inter-dependent concepts and components, and each area's documentation assumes that the reader understands the other areas. For a beginner, that is rarely if ever the case. I'm not trying to add the rants, just provide some constructive criticism. Larry On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Thanks for the recommendation of this page, I think before reading that I even don't understand what I was asking to maven to let it work. :P In the build lifecycle introduction on maven site, there's a table which lists the phase - goal mapping for jar packaging, but that table doesn't have header, so when first read that, I just didn't understand the mapping in that table. hmm. On 9/25/07, Nick Stolwijk [EMAIL PROTECTED] wrote: I always find this [1] a good starting point for the internal lifecycle and packaging workings of Maven. Hth, Nick Stolwijk [1] http://cvs.peopleware.be/training/maven/maven2/buildLifecyclePhases.html In maven, so much of it is implicit (but un/under documented) that it's tough to see what's going on. A description of maven's internal procedures is needed -- to turn that black box white. There's no fundamental reason why maven can't be well documented. _Just tell us how the thing works_. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
Maven docs are time consuming. Now I recall words from one of our team member: I my last project we started to use maven and then we refused to use it because it was hard. Then we started to use Ant, and that is ok. Maven has a steep learning curve, no doubt. However, once you've gotten past that and set up the build, it is easy to understand and maintain. Not to mention all the 'magic' that Maven has. Sure, it's easier to get Ant to do what you want in the first place, but it's likely to be much harder to maintain and has to be re-written for each project. Despite all the trouble I've had with Maven, I still wouldn't trade it for Ant. -- Daniel Siegmann FJA-US, Inc. 512 7th Ave. 15th Flr. New York, NY 10018 (212) 840-2618 x139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Exactly, I'll never turn back. I'll also mention again, I don't know who uses netbeans, but I really find this Maven2 netbeans plugin to be invaluable: http://mevenide.codehaus.org/m2-site/ It has a lot of context sensitive input for the pom.xml, for dependencies and treats a maven2 project as if it's a native netbeans project. It has a few shortcomings, but it helps you to see what dependencies Maven2 is pulling in and where they are coming from, as well as single clicks to build, exclude dependencies that you don't need, and other stuff. I've found it extremely useful. There are similar ones for other IDEs, but this one has been the most helpful thusfar. On 9/25/07, Siegmann Daniel, NY [EMAIL PROTECTED] wrote: Maven docs are time consuming. Now I recall words from one of our team member: I my last project we started to use maven and then we refused to use it because it was hard. Then we started to use Ant, and that is ok. Maven has a steep learning curve, no doubt. However, once you've gotten past that and set up the build, it is easy to understand and maintain. Not to mention all the 'magic' that Maven has. Sure, it's easier to get Ant to do what you want in the first place, but it's likely to be much harder to maintain and has to be re-written for each project. Despite all the trouble I've had with Maven, I still wouldn't trade it for Ant. -- Daniel Siegmann FJA-US, Inc. 512 7th Ave. 15th Flr. New York, NY 10018 (212) 840-2618 x139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
One problem is that you only want to document some of the internal workings of Maven. If you document it in too much detail, you lose the ability to innovate and make it better. It's difficult, though, to find the correct amount of detail to document. -- Lee On 9/25/07, Ryan Moquin [EMAIL PROTECTED] wrote: Exactly, I'll never turn back. I'll also mention again, I don't know who uses netbeans, but I really find this Maven2 netbeans plugin to be invaluable: http://mevenide.codehaus.org/m2-site/ It has a lot of context sensitive input for the pom.xml, for dependencies and treats a maven2 project as if it's a native netbeans project. It has a few shortcomings, but it helps you to see what dependencies Maven2 is pulling in and where they are coming from, as well as single clicks to build, exclude dependencies that you don't need, and other stuff. I've found it extremely useful. There are similar ones for other IDEs, but this one has been the most helpful thusfar. On 9/25/07, Siegmann Daniel, NY [EMAIL PROTECTED] wrote: Maven docs are time consuming. Now I recall words from one of our team member: I my last project we started to use maven and then we refused to use it because it was hard. Then we started to use Ant, and that is ok. Maven has a steep learning curve, no doubt. However, once you've gotten past that and set up the build, it is easy to understand and maintain. Not to mention all the 'magic' that Maven has. Sure, it's easier to get Ant to do what you want in the first place, but it's likely to be much harder to maintain and has to be re-written for each project. Despite all the trouble I've had with Maven, I still wouldn't trade it for Ant. -- Daniel Siegmann FJA-US, Inc. 512 7th Ave. 15th Flr. New York, NY 10018 (212) 840-2618 x139 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -- Lee Meador Sent from gmail. My real email address is lee AT leemeador.com
RE: Why Maven is Hard?
I also think that Maven is hard because it has not been endorsed by large vendors like BEA. BEA WebLogic comes with a set of ant tasks and conventions like the split directory project structure. There is a WebLogic plugin on codehaus that encapsulates these ant tasks but using it is difficult because: - the split directory convention is far from Maven's conventions - the ant tasks (and so the Maven plugin) combine several phases of Maven's build lifecyle: generate-sources, compile, package So, when you try to mavenify a project that has been using these vendor tools and conventions for years, you're going to have a hard time especially because there's very few documentation available from people who went through this path before or only failure stories. I'd say that Maven is probably easier for projects based on open source tools and platforms. -- Gael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
It's not an immediate help, but go back to your vendors and tell them you want maven integration. I know many of them are working on it but just like any product, customer demand can help drive it. I doubt the big guys were first in line with Ant either. --Brian -Original Message- From: Marziou, Gael [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 25, 2007 1:23 PM To: Maven Users List Subject: RE: Why Maven is Hard? I also think that Maven is hard because it has not been endorsed by large vendors like BEA. BEA WebLogic comes with a set of ant tasks and conventions like the split directory project structure. There is a WebLogic plugin on codehaus that encapsulates these ant tasks but using it is difficult because: - the split directory convention is far from Maven's conventions - the ant tasks (and so the Maven plugin) combine several phases of Maven's build lifecyle: generate-sources, compile, package So, when you try to mavenify a project that has been using these vendor tools and conventions for years, you're going to have a hard time especially because there's very few documentation available from people who went through this path before or only failure stories. I'd say that Maven is probably easier for projects based on open source tools and platforms. -- Gael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
On 9/25/07, Brian E. Fox [EMAIL PROTECTED] wrote: It's not an immediate help, but go back to your vendors and tell them you want maven integration. I know many of them are working on it but just like any product, customer demand can help drive it. I doubt the big guys were first in line with Ant either. Yep. If you're a big enough client, or if enough people ask, they'll listen. :) I'm working with a client who is pushing two vendors to write Maven plugins for their products. I don't know whether the plugins will be open source, (the products are not,) but they will at least be available to *other* users of those products. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Hi, I've been reading this thread with interest. No it's not a catch 22. I will clarify what I was saying in my other statement. People have exactly 2 choices when faced with a problem such as documentation. The first one is to say, Boy this product is too hard for me to learn and there isn't enough documentation, so I'll go find something else. The second option is to say, Boy this product is hard, but I really think it could help me on my product so I will learn how to use it and ask questions on the list. Then, because I had so much trouble starting, I will recontribute back what I learned to the project. No one is forcing anyone to do anything. That's the beauty and bane of free software. In order for it to be free, someone has to invest THEIR time to provide you the free software. If you don't like it, you can move on without losing a monetary investment. The bane is that because the contributers/developers aren't usually getting paid, they have to have other jobs where they make their living. To demand that they make sure you get the documentation that you want rather than keep up with regular features for others that don't need the documentation isn't fair either. Others like me have been fine without the documentation, so the question is more why have some succeeded and others failed? In my opinion, those that have succeeded with mvn have been 1 of 2 types: 1 - using mvn for simple tasks 2 - mvn developers I currently have a project I'm working on which has a multi-stage build and requires several 3rd-party mvn plugins. Getting this to work correctly has been a nightmare - there's no other way of describing the frustration with the lack of documentation of the core of mvn. Now we also had some specialised requirements (as is often the case), so I've had to write and maintain 4 custom plugins for our build. So from last November (mvn newbie) to now I've done a considerable amount of mvn hacking, including supplying patches for plugins and writing new plugins. mvn internally has appalling docs, there's practically no javadoc in the project - this makes writing patches to mvn itself tedious and frustrating - and *I want to get involved*. For someone who isn't interested in getting involved, but they need to fix a bug in mvn (and yes mvn has bugs), they open the sources and see undocumented code - that's a massive turn off. Perhaps I'm in the minority, but the mvn mailing lists (users/dev) are not the source of answers I thought they would be - I've asked a few questions on how to configure a plugin/build to achieve the output I wanted - and no there wasn't a reply with an answer. Here is an example: The mvn-war-plugin (which combined with the jspc-plugin should allow me to only create a war with .class files (no jsps included)). By default, this plugin includes everything, so setting warSourceExcludes to exclude the jsp files is the solution - except it isn't. If you set warSourceExcludes to exclude the unnecessary jsp files, it still includes the empty dirs that the jsps were in - this makes my war larger than it should be. If I manually specify exactly what to include I get a massive warSourceIncludes section (which must be repeated in each profile as mvn plexus don't support xml entity fragments eg warSources;) I'd like to modify the mvn-war-plugin source to exclude empty dirs, but again the code isn't well documented and I'd have to maintain a custom version of this plugin instead of using the normal one available on ibiblio/maven2 (I already maintain a custom jspc plugin as it's being re-written in groovy at the moment and is dependent on a broken version of ant which has a URI bug) It's a big short sighted to even assume that someone would say, Go pour through the source and write documentation. That's also quite a bit overly dramatic. If I had to pour through source in order to learn how to use Maven, I would have sucked it up and moved on. Welcome to my world - to get anything done (writing mvn plugins, fixing bugs in plugins we use etc), this is exactly what I have to do - and no it isn't overly dramatic, I have to read the src for various plugins and mvn just to work out what is happening as there are no API docs. Often the plugin svn repo has changed location and the site hasn't been updated, so then you have to hunt down the correct svn location using trial and error - again this is a doc issue (jspc plugin had exactly this problem) Once again I reiterate, if you take it step by step then you will be fine. Ant is NOT any easier to create a build system with. In my experience Ant is much more easy to make a build system, but to each his own For non multiproject builds, there is no reason that someone shouldn't be able to read the getting started and have a webapp up in a few minutes. The problem is that people use mvn to begin with, with a simple project and think 'wow it's so easy', then when used in more complex
Why Maven is Hard?
It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I haven't read (1), but I definitely recommend (2). Very good indeed. Yours, Rodrigo On 9/24/07, Nick Stolwijk [EMAIL PROTECTED] wrote: What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
Hi Denis, Denis Bessmertniy wrote on Monday, September 24, 2007 10:07 AM: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. Regading the EJBs there are quite a lot examples available. See, the strength of Maven is that it *enforces* some kind of project layout and best practices. When you start to do things in other ways, it will not help you (although you *can* do differently if you really really want). With Ant every project establishes its own layout and best practices and new team members will always have to take a very close look. And this is different with Maven, it works always the same way over the complete lifecycle (well, most of the time). - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. I am in the process of doing a handover of a fully mavenised build (all the way through to using the release plugin for releases) to someone who has only ever used ant before, and this process has highlighted that maven IS hard for a beginner to understand. Maven's first problem is that it is not described anywhere neatly in one single paragraph. To a maven beginner, project comprehension tool is entirely meaningless: Why do I need a tool to help me comprehend my project? It makes no sense to a beginner. I have tried to explain maven by calling it an extensible Swiss Army Knife: Rather than telling ant how to do every step of your build, maven already knows how to do every step of your build. You just add the missing bits of information like your project name and version number, and maven does the rest automatically. Another thing a beginner gets confused about is the bewildering volume of plugins. To cut through this confusion I grouped plugins into the basic core group of plugins, and all the other plugins after people ran with the idea and went bananas. Getting across to the user that they don't have to learn to use every plugin, but only the ones they need, is very reassuring for a new user. Something else new users get worried about is what happens if maven cannot do what I want maven to do, and here pointing out if all else fails strategies like using the antrun plugin to get ant to do stuff for you is very reassuring to the new user. The new user doesn't need to know how the antrun plugin works, they only need to know that it is there. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I think one of Ant's main strengths was not that it was a great build tool (that XML format was quite painful to use when I'm honest about it) but the documentation was brilliant that it was thus very easy to get things working. The maven documentation is not really complete on the website and there a tonne of undocumented features and odd behaviours. I would agree the documetation needs some work and in my opinion three things need attention: 1) A general reorganisation for the reference docs so that they are as accessible as the basic tutorials and get that access from the maven front page so its one click away just like Ant's was. 2) The reference material needs more detail. Specific things like what all the options for a value do. 3) More advanced tutorials for complex project structures, probably in the reference documents. For example a lot more detail on multimodule projects would be nice, things like how to have a dependency on a multi-module project and pulling in all the code. How to publish a multi-module project to a repository etc. Its not just multimodule, its also how to build anything other than a library. I'll think about it a bit more and propose a structure and tutorials that I think we need to write. Paul Keeble - Original Message From: Denis Bessmertniy [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Monday, 24 September, 2007 9:56:01 AM Subject: RE: Why Maven is Hard? I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Yes, Maven is hard. I should agree, there is why: New and buggy: Maven is hard, because it is new and like all new stuffs, it's buggy. Working around those little bugs or waiting for one good soul to provide a patch is a pain... Expertise on Maven is also harder to find. Black Box: Maven is hard, because for most people , it is a black box. Like with all black boxes, it's wonderful when it does what you want, and it is the worst nightmare when it doesn't. Ant scripts are indeed much more easy to accommodate. The true question is: why is Maven not doing what I want ? And the true answer to this is: Because what I want to do is probably not correct... -Toni Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Why-Maven-is-Hard--tf4507688s177.html#a12856941 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes On Monday 24 September 2007 20:56, Denis Bessmertniy wrote: I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
Easy to you but not for clietns. Client is always right ;-) -Original Message- From: Michael McCallum [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 1:04 PM To: Maven Users List Subject: Re: Why Maven is Hard? with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes On Monday 24 September 2007 20:56, Denis Bessmertniy wrote: I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modul es modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. -- -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That depends just how much of maven you are using. You might choose to use maven to build you a jar. Or you might have many jars, and arrange tham as dependencies of one another. Then you might go one step further and create many jars released at once in a multi-module configuration. Then you might choose to start using the maven release process to handle releases, and you might choose to run your own maven repository infrastructure. I can tell you from experience that getting the above working took a significant amount of time and effort, and in some cases, it involved stepping through maven modules in a debugger to figure out what the modules were doing. Many things about maven can be found in the documentation in 5 minutes, but to say that every question can be answered by the maven docs in under 5 minutes does both maven and maven users a disservice. Maven is an extremely valuable tool, but it is by no means trivial. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: Why Maven is Hard?
There are questions that I have that I simply can't find answers for at all! Not only are the details not in the documentation but they aren't even blogged about. Just compare the level of documentation in Ant verses Maven and its a night and day difference. Don't get me wrong there is a lot of documentation for Maven I just don't think its as accessible or as detailed. If you have 5 options for a parameter then the details of what each does is essential and that is just missing (for instance what does a dependency being of type pom mean?! I had to write an example app to see what it meant). Ant has no such corner cases, it documents every single value and parameter. Maven still has better documentation than many other open source projects but its not a 5 minute lookup, its several hours of searching and prototyping on google. I'd never consider looking for ant documentation anywhere except their site, for maven I prefer to look else where as the site is not detailed enough. Paul K - Original Message From: Michael McCallum [EMAIL PROTECTED] To: Maven Users List users@maven.apache.org Sent: Monday, 24 September, 2007 11:04:10 AM Subject: Re: Why Maven is Hard? with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes On Monday 24 September 2007 20:56, Denis Bessmertniy wrote: I said that it is hard because with maven I step on rake from time to time. By the way I have read the Better build with maven book. And my idea will be more correct: not maven hard, but maven is bad documented on its web site. -Original Message- From: Rodrigo Madera [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:50 AM To: Maven Users List Subject: Re: Why Maven is Hard? Denis, Will all due respect, do you really wish to just read a page and get running and fully understanding Maven? Do you really say Maven is hard because you didn't understand your very first plugin encounter, which happens to be nothing less than the EAR plugin? Maven is a complex system that simplifies projects, but it does so with concepts that need to be viewed. You need to read the book. You need to read it so you will understand. If you're a fast reader you'll be doing Hello World in less than two hours knowing what you are doing. Sincerely, Rodrigo On 9/24/07, Denis Bessmertniy [EMAIL PROTECTED] wrote: That is. I haven't need to read fat books when I studied Ant, for example. That is. Look to http://maven.apache.org/plugins/maven-ear-plugin/ear-mojo.html#modules modules The ear modules configuration. * Type: org.apache.maven.plugin.ear.EarModule[] * Required: No What is org.apache.maven.plugin.ear.EarModule[] here? How I may understand what I need to pass? Standard Maven plugins really bad documented. -Original Message- From: Nick Stolwijk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 11:17 AM To: Maven Users List Subject: Re: Why Maven is Hard? What documentation did you read? There are two very good books about maven 2 (and they are free to download) 1. Maven the Definitive Guide (http://www.sonatype.com/book/) 2. Better Builds with Maven (http://www.devzuz.com/web/guest/products/resources#BBWM) Sometimes, the documentation for some of the plugins is hard to understand. But mostly, this are third party plugins, so the Maven team can't do anything about it. You will have to mail the team of the plugin. Hth, Nick Stolwijk Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html
Re: Why Maven is Hard?
Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That might be the case for the questions you came across. The mere traffic on this list proves that there are indeed loads of questions the documentation doesn't answer. Also this kind of thread about how improvable the documentation is occurs frequently on this list. The last big attempt to make the docs better has AFAIK been this one: http://www.nabble.com/Maven-2.x-documentation-tf382504s177.html#a1055690 Possibly that sort of campaign should be done on a regular base or, even better, Maven should have a technical writer who cares about documentation issues. I'm aware of the fact that Maven is a open source project, however, there are businesses built around it (among other tools) that might have an interest in better docs and less rant on the mailing list. Just my 2 cents (I'm no native English speaker and therefore unfortunately can't really help with this kind of task). -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Denis, I get what you mean now and I agree... I have spent hours with Maven debugging and I know what you feel. It's been less than five hours since I had to download the source code of a plugin to see what was going on inside of it... and got no results. Fortunately, knowledgeable people writing on these lists helped me out and made me continue my journey. In the corporate world, these hold backs are a serious risk to profitability. I just hope that Maven plugins get better documentation. I have nothing to complain on Maven's own, but plugin writers forget that other people haven't seen the source code of their plugin (not to say that everyone would make much sense of it). Maybe one day... Regards, Rodrigo On 9/24/07, Gisbert Amm [EMAIL PROTECTED] wrote: Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That might be the case for the questions you came across. The mere traffic on this list proves that there are indeed loads of questions the documentation doesn't answer. Also this kind of thread about how improvable the documentation is occurs frequently on this list. The last big attempt to make the docs better has AFAIK been this one: http://www.nabble.com/Maven-2.x-documentation-tf382504s177.html#a1055690 Possibly that sort of campaign should be done on a regular base or, even better, Maven should have a technical writer who cares about documentation issues. I'm aware of the fact that Maven is a open source project, however, there are businesses built around it (among other tools) that might have an interest in better docs and less rant on the mailing list. Just my 2 cents (I'm no native English speaker and therefore unfortunately can't really help with this kind of task). -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
just to repeat i have been able to answer every question I have been asked thats not to say every question but to say every question that in my experience new users have asked... often they proceeded to go and do something else anyway but thats beside the point... modules are way overused IMO and do cause lots of problems usually because people confuse parent poms and modules projects when really they are not the same thing... On Monday 24 September 2007 22:32, Graham Leggett wrote: Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7 every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That depends just how much of maven you are using. You might choose to use maven to build you a jar. Or you might have many jars, and arrange tham as dependencies of one another. Then you might go one step further and create many jars released at once in a multi-module configuration. Then you might choose to start using the maven release process to handle releases, and you might choose to run your own maven repository infrastructure. I can tell you from experience that getting the above working took a significant amount of time and effort, and in some cases, it involved stepping through maven modules in a debugger to figure out what the modules were doing. Many things about maven can be found in the documentation in 5 minutes, but to say that every question can be answered by the maven docs in under 5 minutes does both maven and maven users a disservice. Maven is an extremely valuable tool, but it is by no means trivial. Regards, Graham -- -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I should also add that that does not include supporting 3rd party plugins... and often getting the source for them can be useful... i have my own versions of mojo hibernate, xslt among a few others while waiting for bug fixes... thats like saying that micrsoft is responsible for the documentation of the drivers for my one-touch maxtor usb drive... just because i can't get the one touch button going on the maxtor does not make windows hard... On Monday 24 September 2007 23:23, Rodrigo Madera wrote: Denis, I get what you mean now and I agree... I have spent hours with Maven debugging and I know what you feel. It's been less than five hours since I had to download the source code of a plugin to see what was going on inside of it... and got no results. Fortunately, knowledgeable people writing on these lists helped me out and made me continue my journey. In the corporate world, these hold backs are a serious risk to profitability. I just hope that Maven plugins get better documentation. I have nothing to complain on Maven's own, but plugin writers forget that other people haven't seen the source code of their plugin (not to say that everyone would make much sense of it). Maybe one day... Regards, Rodrigo On 9/24/07, Gisbert Amm [EMAIL PROTECTED] wrote: Michael McCallum wrote: with a few subtle exceptions related to bugs that are fixed in 2.0.7every question i've been asked in regard to using maven2 has been found in the documentation in under 5 minutes That might be the case for the questions you came across. The mere traffic on this list proves that there are indeed loads of questions the documentation doesn't answer. Also this kind of thread about how improvable the documentation is occurs frequently on this list. The last big attempt to make the docs better has AFAIK been this one: http://www.nabble.com/Maven-2.x-documentation-tf382504s177.html#a1055690 Possibly that sort of campaign should be done on a regular base or, even better, Maven should have a technical writer who cares about documentation issues. I'm aware of the fact that Maven is a open source project, however, there are businesses built around it (among other tools) that might have an interest in better docs and less rant on the mailing list. Just my 2 cents (I'm no native English speaker and therefore unfortunately can't really help with this kind of task). -Gisbert -- Gisbert Amm Softwareentwickler Infrastruktur Telefon: (0721) 91374 - 4224 Telefax: (0721) 91374 - 2740 E-Mail: [EMAIL PROTECTED] Internet: www.1und1.de 11 Internet AG Elgendorfer Strasse 57 56410 Montabaur Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger (Vorsitzender), Matthias Greve, Henning Ahlert, Norbert Lang, Achim Weiss, Robert Hoffmann, Aufsichtsratsvorsitzender: Michael Scheeren - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
So you are saying that Maven IS hard because someone doesn't understand a huge project that they've never used before? You are saying that if it was done in ant it would be easier to understand? I find that extremely hard to believe. I've read plenty of articles written that I thought explained nicely what Maven 2 is. If there is no good paragraph on the Maven website about what it is, then why would someone have started using it if they didn't know? If people are going nuts installing every plugin on the planet and then wondering why they can't understand Maven, then I have no pity for them. You don't start off programming by trying to do something complicated. Anyone that does that is asking for trouble, and can't blame that on the tool. Tools are tools, they can be misused and abused. With anything, someone has to have realistic expectations and expect to learn rather than just be productive instantly. I got started with Maven by simply building a jar, then a webapp (all documented on their site) and then added stuff to it as I needed. I've never had a problem and never felt lost to the point of frustration. On 9/24/07, Graham Leggett [EMAIL PROTECTED] wrote: Denis Bessmertniy wrote: It is interesting why maven is so hard to understand? Why it is not well documented? (It is all my own opinions) I haven't so much probmlems with Ant, for example. I am in the process of doing a handover of a fully mavenised build (all the way through to using the release plugin for releases) to someone who has only ever used ant before, and this process has highlighted that maven IS hard for a beginner to understand. Maven's first problem is that it is not described anywhere neatly in one single paragraph. To a maven beginner, project comprehension tool is entirely meaningless: Why do I need a tool to help me comprehend my project? It makes no sense to a beginner. I have tried to explain maven by calling it an extensible Swiss Army Knife: Rather than telling ant how to do every step of your build, maven already knows how to do every step of your build. You just add the missing bits of information like your project name and version number, and maven does the rest automatically. Another thing a beginner gets confused about is the bewildering volume of plugins. To cut through this confusion I grouped plugins into the basic core group of plugins, and all the other plugins after people ran with the idea and went bananas. Getting across to the user that they don't have to learn to use every plugin, but only the ones they need, is very reassuring for a new user. Something else new users get worried about is what happens if maven cannot do what I want maven to do, and here pointing out if all else fails strategies like using the antrun plugin to get ant to do stuff for you is very reassuring to the new user. The new user doesn't need to know how the antrun plugin works, they only need to know that it is there. Regards, Graham -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
I'm really floored that this discussion is even happening. Here is why: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? If you are that upset about it, then you obviously like it. Therefore, give back to the community and do something productive with your time rather than complaining. Complaining won't give the project contributors more time in their day to write documentation, it will just simply make them feel unappreciated. I was always told that you can't complain about something unless you have a better idea. If you think there should be better documentation, help them out rather than hassle them. I'm managing a full enterprise application with Maven 2, with MANY subprojects (right about 20 or so), all of them have dependencies on each other. I'm also managing our repository, handling releases and deployments from Maven 2. I have portlet maven 2 projects in my build, core libraries (DAO), third party integration libraries, servicemix services and external web applications (that get loaded externally into the portlet because they can't be portlets themselves. And with all that I have to say that I have not had one time where Maven 2 hasn't provided me a way to get done what I needed to in a complicated build system and quickly. If you like ant, then the antrun plugin is your best friend. Just tell it when to run and then that's it. If I had to do all this in ant, it would have taken me way longer to create and manage. Even with managing all of this by myself, I find PLENTY of time to code and make improvements to the software. I think ant builds are way over complicated. I've seen ant builds that are just a complete mess because there is no structure to it. Every Maven project that I've come across (open source projects I've downloaded) have been very easy for me to get up and running with. The ant based ones I downloaded make me cringe and I don't even want to touch them. They are very hard to follow and I can't stand build.xml files that import other build.xml files. Yes some of the documentation is lacking, but you have to realize this is a really good project for free and I rarely have ever come across any problems with due to bugs. I can stand up a new project in our build in a couple minutes and instantly have a new component and ready to go. I think it takes more planning to how you are going to organize your code and projects so that dependencies are correct than they are that Maven 2 is just too difficult. I think maybe people could be feeling lost due to not being sure of the best practices, but no one is able to do everything perfectly the first time. I've never had problems finding information on what I've needed in places other than the Maven 2 site, and there is no shame in people having to look elsewhere. I'd rather a stable product with less documentation than an unstable product with documentation (why do I want to learn how to use something that doesn't work?). I've found plugins that I thought were hard to use, so I just use the ant version of them which is cake to plugin. I applaud the Maven team and am thankful for the time they've put into a product that has saved me so much time. Also, Maven is way easier to follow with a good tool. Just like code that you are trying to understand is very hard to follow without a tool. The Maven 2 netbeans plugin makes this all so easy to use. On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: I should also add that that does not include supporting 3rd party plugins... and often getting the source for them can be useful... i have my own versions of mojo hibernate, xslt among a few others while waiting for bug fixes... thats like saying that micrsoft is responsible for the documentation of the drivers for my one-touch maxtor usb drive... just because i can't get the one touch button going on the maxtor does not make windows hard... On Monday 24 September 2007 23:23, Rodrigo Madera wrote: Denis, I get what you mean now and I agree... I have spent hours with Maven debugging and I know what you feel. It's been less than five hours since I had to download the source code of a plugin to see what was going on inside of it... and got no results. Fortunately, knowledgeable people writing on these lists helped me out and made me continue my journey. In the corporate world, these hold backs are a serious risk to profitability. I just hope that Maven plugins get better documentation. I have nothing to complain on Maven's own, but plugin writers forget that other people haven't seen the source code of their plugin (not to say that everyone would make much sense of it). Maybe one day... Regards, Rodrigo On 9/24/07, Gisbert Amm [EMAIL PROTECTED] wrote: Michael McCallum
Re: Why Maven is Hard?
On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
And having read the rest of your statement I do exactly the same with with 90+ artifacts culminating in 9 different aggregations == war, ear, compound jar On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: I'm managing a full enterprise application with Maven 2, with MANY subprojects (right about 20 or so), all of them have dependencies on each other. I'm also managing our repository, handling releases and deployments from Maven 2. -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Isn't this sort of a catch-22? People are saying I don't get maven, it's too complex. Now it's time for them to give something back and document it? How do you propose they do that? Start at the source and pore through it to explain it? Saying that is sort of a cop-out, IMO. I think that the problem is that we have maven in 5 minutes and then the rest of the docs assume that people are experts with it - the 2 books mentioned earlier are useful, but I think people want something more approachable and contextual. One other thing is the navigation - I find it very difficult to get around the maven site in any meaningful way. There are many inter-dependent concepts and components, and each area's documentation assumes that the reader understands the other areas. For a beginner, that is rarely if ever the case. I'm not trying to add the rants, just provide some constructive criticism. Larry On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
The Maven User wiki is a great place for users to begin contributing in a meaningful way: http://docs.codehaus.org/display/MAVENUSER/Home Also, the wiki is a great place to look for help, documentation, examples etc. If you're having trouble with finding things on the Maven site, check out the Wiki. Wayne On 9/24/07, Michael McCallum [EMAIL PROTECTED] wrote: On Tuesday 25 September 2007 01:10, Ryan Moquin wrote: If people are build their core infrastructure around Maven to the point where they feel like they should give the project developers a hard time due to something as simple as documentation, don't you think then that it's time to contribute? I concur wholeheartedly... -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why Maven is Hard?
One of Maven's values is that it does the heavy lifting for you. (as it's literature describes.) But that is also exactly the problem - because it is sometimes hard to tell what is going on. You need to keep the Maven cycle in mind at all times - and that does add another level of indirection. As a build engineer I am often getting complicated Maven poms from developers and then I gotta decipher what is happening. With Ant - it's a lot more transparent. I am not criticizing maven (then we'd be talking about the painful bugs), but I do think that it is fair to say that it is harder to understand what is happening... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why Maven is Hard?
Ryan Moquin wrote: So you are saying that Maven IS hard because someone doesn't understand a huge project that they've never used before? Yes. You are saying that if it was done in ant it would be easier to understand? Absolutely not. What on earth gave you that idea? Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
RE: Why Maven is Hard?
I agree with previous observations that some of the plugins have very poor documentation regarding their parameters. Regarding complex projects, any POM that is non-trivial should be well commented to describe the operations that are novel. Every effort should be made to keep builds plain and simple. In Ant, of course, you can just read the script as it describes the procedure down to the last detail. But in Mavens nippy declarative language, heavy commenting is essential because of the black-box effect. Novel plugins should be well documented and can make use of the info log to tell the builder what is happening. Regards, John -Original Message- From: Bob Aiello [mailto:[EMAIL PROTECTED] Sent: 24 September 2007 16:24 To: Maven Users List Subject: RE: Why Maven is Hard? One of Maven's values is that it does the heavy lifting for you. (as it's literature describes.) But that is also exactly the problem - because it is sometimes hard to tell what is going on. You need to keep the Maven cycle in mind at all times - and that does add another level of indirection. As a build engineer I am often getting complicated Maven poms from developers and then I gotta decipher what is happening. With Ant - it's a lot more transparent. I am not criticizing maven (then we'd be talking about the painful bugs), but I do think that it is fair to say that it is harder to understand what is happening... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Eurobase International Limited and its subsidiaries (Eurobase) are unable to exercise control over the content of information in E-Mails. Any views and opinions expressed may be personal to the sender and are not necessarily those of Eurobase. Eurobase will not enter into any contractual obligations in respect of any part of its business in any E-mail. Privileged / confidential information may be contained in this message and /or any attachments. This E-mail is intended for the use of the addressee(s) only and may contain confidential information. If you are not the / an intended recipient, you are hereby notified that any use or dissemination of this communication is strictly prohibited. If you receive this transmission in error, please notify us immediately, and then delete this E-mail. Neither the sender nor Eurobase accepts any liability whatsoever for any defects of any kind either in or arising from this E-mail transmission. E-Mail transmission cannot be guaranteed to be secure or error-free, as messages can be intercepted, lost, corrupted, destroyed, contain viruses, or arrive late or incomplete. Eurobase does not accept any responsibility for viruses and it is your responsibility to scan any attachments. Eurobase Systems Limited is the main trading company in the Eurobase International Group; registered in England and Wales as company number 02251162; registered address: Essex House, 2 County Place, Chelmsford, Essex CM2 0RE, UK. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
