|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
|
|
What can possibly go wrong with MavenHi,
I'm trying to collect everything that can go wrong inside Maven so that it can be clearly pointed out to a user. We currently have a mechanism that analyzes stack traces, isn't localized, and is not very friendly for embedding as everything is couched in the form of console output. Here's the list that I came up with so far and I want to make to make a mechanism that says exactly what's wrong. Anyone have anything else? I'm not trying to consider everything that happens in plugins. I've identified almost all the places where those errors occur and I would like them to surface at the top in a form that is useful to embedding. As a by product it's easy to produce console output for the CLI. I don't care if the try/catch is a mile long it's going to tell users exactly what happened when something goes wrong. I've pushed all console logging out of DefaultMaven and into the CLI. Moved the monitor into the core, but we still have console-centric logging in a bunch of the major components which I should be able to purge by the release of 2.1-alpha-1. Here's the list: - bad command line parameter - malformed settings - malformed POM - local repository not writable - remote repositories not available - artifact metadata missing - extension metadata missing - extension artifact missing - artifact metadata retrieval problem - version range violation - circular dependency - artifact missing - artifact retrieval exception - plugin metadata missing - plugin metadata retrieval problem - plugin artifact missing - plugin artifact retrieval problem - plugin dependency metadata missing - plugin dependency metadata retrieval problem - plugin configuration problem - plugin execution failure due to something that is know to possibly go wrong (like compilation failure) - plugin execution error due to something that is not expected to go wrong (the compiler executable missing) Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with Maven- invalid lifecycle phase (maybe same as bad CLI param, though you
were talking about embedder too) - <module> specified is not found - POM doesn't exist for a goal that requires one - goal not found in a plugin (probably could list the ones that are) - parent POM missing (in both the repository + relative path) I can't think of anything else right now - might be best to crack open intelliJ and do find usages on Exception and it's child classes within the project files :) On 04/09/2007, at 9:57 AM, Jason van Zyl wrote: > Hi, > > I'm trying to collect everything that can go wrong inside Maven so > that it can be clearly pointed out to a user. We currently have a > mechanism that analyzes stack traces, isn't localized, and is not > very friendly for embedding as everything is couched in the form of > console output. Here's the list that I came up with so far and I > want to make to make a mechanism that says exactly what's wrong. > > Anyone have anything else? I'm not trying to consider everything > that happens in plugins. I've identified almost all the places > where those errors occur and I would like them to surface at the > top in a form that is useful to embedding. As a by product it's > easy to produce console output for the CLI. I don't care if the try/ > catch is a mile long it's going to tell users exactly what happened > when something goes wrong. I've pushed all console logging out of > DefaultMaven and into the CLI. Moved the monitor into the core, but > we still have console-centric logging in a bunch of the major > components which I should be able to purge by the release of 2.1- > alpha-1. > > Here's the list: > > - bad command line parameter > - malformed settings > - malformed POM > - local repository not writable > - remote repositories not available > - artifact metadata missing > - extension metadata missing > - extension artifact missing > - artifact metadata retrieval problem > - version range violation > - circular dependency > - artifact missing > - artifact retrieval exception > - plugin metadata missing > - plugin metadata retrieval problem > - plugin artifact missing > - plugin artifact retrieval problem > - plugin dependency metadata missing > - plugin dependency metadata retrieval problem > - plugin configuration problem > - plugin execution failure due to something that is know to > possibly go wrong (like compilation failure) > - plugin execution error due to something that is not expected to > go wrong (the compiler executable missing) > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... -- Brett Porter - brett@... Blog: http://www.devzuz.org/blogs/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
RE: What can possibly go wrong with Maven- calling a goal that does not need a POM in the current dir in a multi-project root Examples: mvn install:install-file <args> mvn archetype:create <args> Maven walks down the complete project hierarchy ... Brett Porter wrote on Tuesday, September 04, 2007 10:15 AM: > - invalid lifecycle phase (maybe same as bad CLI param, though you > were talking about embedder too) > - <module> specified is not found > - POM doesn't exist for a goal that requires one > - goal not found in a plugin (probably could list the ones that are) > - parent POM missing (in both the repository + relative path) > > I can't think of anything else right now - might be best to crack > open intelliJ and do find usages on Exception and it's child classes > within the project files :) > > On 04/09/2007, at 9:57 AM, Jason van Zyl wrote: > >> Hi, >> >> I'm trying to collect everything that can go wrong inside Maven so >> that it can be clearly pointed out to a user. We currently have a >> mechanism that analyzes stack traces, isn't localized, and is not >> very friendly for embedding as everything is couched in the form of >> console output. Here's the list that I came up with so far and I >> want to make to make a mechanism that says exactly what's wrong. >> >> Anyone have anything else? I'm not trying to consider everything >> that happens in plugins. I've identified almost all the places >> where those errors occur and I would like them to surface at the >> top in a form that is useful to embedding. As a by product it's >> easy to produce console output for the CLI. I don't care if the try/ >> catch is a mile long it's going to tell users exactly what happened >> when something goes wrong. I've pushed all console logging out of >> DefaultMaven and into the CLI. Moved the monitor into the core, but >> we still have console-centric logging in a bunch of the major >> components which I should be able to purge by the release of 2.1- >> alpha-1. >> >> Here's the list: >> >> - bad command line parameter >> - malformed settings >> - malformed POM >> - local repository not writable >> - remote repositories not available >> - artifact metadata missing >> - extension metadata missing >> - extension artifact missing >> - artifact metadata retrieval problem >> - version range violation >> - circular dependency >> - artifact missing >> - artifact retrieval exception >> - plugin metadata missing >> - plugin metadata retrieval problem >> - plugin artifact missing >> - plugin artifact retrieval problem >> - plugin dependency metadata missing >> - plugin dependency metadata retrieval problem >> - plugin configuration problem >> - plugin execution failure due to something that is know to >> possibly go wrong (like compilation failure) >> - plugin execution error due to something that is not expected to >> go wrong (the compiler executable missing) >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder and PMC Chair, Apache Maven >> jason at sonatype dot com >> ---------------------------------------------------------- >> >> >> >> >> > --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with MavenOn 4 Sep 07, at 1:15 AM 4 Sep 07, Brett Porter wrote: > - invalid lifecycle phase (maybe same as bad CLI param, though you > were talking about embedder too) Yup, this is caught with some validation code I added the other day but it needs to filter up nicely. It doesn't currently. > - <module> specified is not found > - POM doesn't exist for a goal that requires one > - goal not found in a plugin (probably could list the ones that are) > - parent POM missing (in both the repository + relative path) > I will add these to the list. I'm certain 99/100 we can tell users exactly what's wrong and no reason we can't do it in plain language. > I can't think of anything else right now - might be best to crack > open intelliJ and do find usages on Exception and it's child > classes within the project files :) > > On 04/09/2007, at 9:57 AM, Jason van Zyl wrote: > >> Hi, >> >> I'm trying to collect everything that can go wrong inside Maven so >> that it can be clearly pointed out to a user. We currently have a >> mechanism that analyzes stack traces, isn't localized, and is not >> very friendly for embedding as everything is couched in the form >> of console output. Here's the list that I came up with so far and >> I want to make to make a mechanism that says exactly what's wrong. >> >> Anyone have anything else? I'm not trying to consider everything >> that happens in plugins. I've identified almost all the places >> where those errors occur and I would like them to surface at the >> top in a form that is useful to embedding. As a by product it's >> easy to produce console output for the CLI. I don't care if the >> try/catch is a mile long it's going to tell users exactly what >> happened when something goes wrong. I've pushed all console >> logging out of DefaultMaven and into the CLI. Moved the monitor >> into the core, but we still have console-centric logging in a >> bunch of the major components which I should be able to purge by >> the release of 2.1-alpha-1. >> >> Here's the list: >> >> - bad command line parameter >> - malformed settings >> - malformed POM >> - local repository not writable >> - remote repositories not available >> - artifact metadata missing >> - extension metadata missing >> - extension artifact missing >> - artifact metadata retrieval problem >> - version range violation >> - circular dependency >> - artifact missing >> - artifact retrieval exception >> - plugin metadata missing >> - plugin metadata retrieval problem >> - plugin artifact missing >> - plugin artifact retrieval problem >> - plugin dependency metadata missing >> - plugin dependency metadata retrieval problem >> - plugin configuration problem >> - plugin execution failure due to something that is know to >> possibly go wrong (like compilation failure) >> - plugin execution error due to something that is not expected to >> go wrong (the compiler executable missing) >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder and PMC Chair, Apache Maven >> jason at sonatype dot com >> ---------------------------------------------------------- >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@... >> For additional commands, e-mail: dev-help@... > > -- > Brett Porter - brett@... > Blog: http://www.devzuz.org/blogs/bporter/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with MavenOn 04/09/2007, at 6:24 PM, Jörg Schaible wrote: > > - calling a goal that does not need a POM in the current dir in a > multi-project root > Examples: > mvn install:install-file <args> > mvn archetype:create <args> > Maven walks down the complete project hierarchy ... But Maven can't tell the difference between "doesn't need a POM" (archetype, which can use it and add a <module> if it exists) and "shouldn't use a POM" (install-file), so this isn't an error condition. It's something the plugin developers need to take into account. - Brett -- Brett Porter - brett@... Blog: http://www.devzuz.org/blogs/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
RE: What can possibly go wrong with MavenBrett Porter wrote on Tuesday, September 04, 2007 10:31 AM:
> On 04/09/2007, at 6:24 PM, Jörg Schaible wrote: > >> >> - calling a goal that does not need a POM in the current dir in a >> multi-project root Examples: >> mvn install:install-file <args> >> mvn archetype:create <args> >> Maven walks down the complete project hierarchy ... > > But Maven can't tell the difference between "doesn't need a > POM" (archetype, which can use it and add a <module> if it exists) > and "shouldn't use a POM" (install-file), so this isn't an error > condition. It's something the plugin developers need to take into > account. Yes, but has the Mojo any chance of telling this to Maven? I am not too familiar with the internals, but I assume that the evaluation of the POMs takes place before the goal is called. If the Mojo has already the possibility to supress the traversal of the modules, then I agree and it's a simple bug in the goal. - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with MavenOn 04/09/2007, at 7:40 PM, Jörg Schaible wrote: > Brett Porter wrote on Tuesday, September 04, 2007 10:31 AM: > >> On 04/09/2007, at 6:24 PM, Jörg Schaible wrote: >> >>> >>> - calling a goal that does not need a POM in the current dir in a >>> multi-project root Examples: >>> mvn install:install-file <args> >>> mvn archetype:create <args> >>> Maven walks down the complete project hierarchy ... >> >> But Maven can't tell the difference between "doesn't need a >> POM" (archetype, which can use it and add a <module> if it exists) >> and "shouldn't use a POM" (install-file), so this isn't an error >> condition. It's something the plugin developers need to take into >> account. > > Yes, but has the Mojo any chance of telling this to Maven? I am not > too familiar with the internals, but I assume that the evaluation > of the POMs takes place before the goal is called. If the Mojo has > already the possibility to supress the traversal of the modules, > then I agree and it's a simple bug in the goal. That's one of the things @aggregator is used for (though it has had problems as Brian showed). Anyway, I was just pointing out it wasn't related to the discussion at hand :) Cheers, Brett -- Brett Porter - brett@... Blog: http://www.devzuz.org/blogs/bporter/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with Maven- Classloader problems: often difficult to debug them when artifacts are coming from different
"transitive sources". Would be great to have a better way to display a trace of the dependency tree, without being swamped by all the non-dependency "noise". Maybe a new debug flag (different from -X and -e) would help here. Jason van Zyl wrote: > Hi, > > I'm trying to collect everything that can go wrong inside Maven so that > it can be clearly pointed out to a user. We currently have a mechanism > that analyzes stack traces, isn't localized, and is not very friendly > for embedding as everything is couched in the form of console output. > Here's the list that I came up with so far and I want to make to make a > mechanism that says exactly what's wrong. > > Anyone have anything else? I'm not trying to consider everything that > happens in plugins. I've identified almost all the places where those > errors occur and I would like them to surface at the top in a form that > is useful to embedding. As a by product it's easy to produce console > output for the CLI. I don't care if the try/catch is a mile long it's > going to tell users exactly what happened when something goes wrong. > I've pushed all console logging out of DefaultMaven and into the CLI. > Moved the monitor into the core, but we still have console-centric > logging in a bunch of the major components which I should be able to > purge by the release of 2.1-alpha-1. > > Here's the list: > > - bad command line parameter > - malformed settings > - malformed POM > - local repository not writable > - remote repositories not available > - artifact metadata missing > - extension metadata missing > - extension artifact missing > - artifact metadata retrieval problem > - version range violation > - circular dependency > - artifact missing > - artifact retrieval exception > - plugin metadata missing > - plugin metadata retrieval problem > - plugin artifact missing > - plugin artifact retrieval problem > - plugin dependency metadata missing > - plugin dependency metadata retrieval problem > - plugin configuration problem > - plugin execution failure due to something that is know to possibly go > wrong (like compilation failure) > - plugin execution error due to something that is not expected to go > wrong (the compiler executable missing) > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder and PMC Chair, Apache Maven > jason at sonatype dot com > ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
RE: What can possibly go wrong with MavenComponent not found
Missing goal in plugin (probably the wrong version) -----Original Message----- From: Jason van Zyl [mailto:jason@...] Sent: Monday, September 03, 2007 7:58 PM To: Maven Developers List Subject: What can possibly go wrong with Maven Hi, I'm trying to collect everything that can go wrong inside Maven so that it can be clearly pointed out to a user. We currently have a mechanism that analyzes stack traces, isn't localized, and is not very friendly for embedding as everything is couched in the form of console output. Here's the list that I came up with so far and I want to make to make a mechanism that says exactly what's wrong. Anyone have anything else? I'm not trying to consider everything that happens in plugins. I've identified almost all the places where those errors occur and I would like them to surface at the top in a form that is useful to embedding. As a by product it's easy to produce console output for the CLI. I don't care if the try/catch is a mile long it's going to tell users exactly what happened when something goes wrong. I've pushed all console logging out of DefaultMaven and into the CLI. Moved the monitor into the core, but we still have console-centric logging in a bunch of the major components which I should be able to purge by the release of 2.1-alpha-1. Here's the list: - bad command line parameter - malformed settings - malformed POM - local repository not writable - remote repositories not available - artifact metadata missing - extension metadata missing - extension artifact missing - artifact metadata retrieval problem - version range violation - circular dependency - artifact missing - artifact retrieval exception - plugin metadata missing - plugin metadata retrieval problem - plugin artifact missing - plugin artifact retrieval problem - plugin dependency metadata missing - plugin dependency metadata retrieval problem - plugin configuration problem - plugin execution failure due to something that is know to possibly go wrong (like compilation failure) - plugin execution error due to something that is not expected to go wrong (the compiler executable missing) Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with MavenMauro Talevi wrote:
> - Classloader problems: often difficult to debug them when artifacts are > coming from different > "transitive sources". Would be great to have a better way to display a > trace of the dependency > tree, without being swamped by all the non-dependency "noise". Maybe a > new debug flag (different from -X and -e) would help here. You mean something like this? joehni@paddy ~/src/Codehaus/pico/java-2.x/nano/container-bsh $ mvn info:deps-runtime [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'info'. WAGON_VERSION: 1.0-beta-2 [INFO] ---------------------------------------------------------------------------- [INFO] Building NanoContainer bsh [INFO] task-segment: [info:deps-runtime] [INFO] ---------------------------------------------------------------------------- [INFO] [info:deps-runtime] [INFO] org.nanocontainer:nanocontainer-bsh:jar:2.0-SNAPSHOT [INFO] org.nanocontainer:nanocontainer:jar:2.0-SNAPSHOT [INFO] : org.picocontainer:picocontainer:jar:2.0-SNAPSHOT [INFO] : com.thoughtworks.paranamer:paranamer-asm:jar:1.0.1 [INFO] : com.thoughtworks.paranamer:paranamer:jar:1.0.1 [INFO] : asm:asm:jar:3.0 [INFO] org.beanshell:bsh:jar:2.0b4 [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 5 seconds [INFO] Finished at: Wed Sep 05 13:03:28 CEST 2007 [INFO] Final Memory: 3M/6M [INFO] ------------------------------------------------------------------------ - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with MavenOn 05/09/2007, Jörg Schaible <joerg.schaible@...> wrote:
> You mean something like this? > > joehni@paddy ~/src/Codehaus/pico/java-2.x/nano/container-bsh $ mvn > info:deps-runtime > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'info'. > WAGON_VERSION: 1.0-beta-2 > [INFO] ---------------------------------------------------------------------------- > [INFO] Building NanoContainer bsh > [INFO] task-segment: [info:deps-runtime] > [INFO] ---------------------------------------------------------------------------- > [INFO] [info:deps-runtime] > [INFO] org.nanocontainer:nanocontainer-bsh:jar:2.0-SNAPSHOT > [INFO] org.nanocontainer:nanocontainer:jar:2.0-SNAPSHOT > [INFO] : org.picocontainer:picocontainer:jar:2.0-SNAPSHOT > [INFO] : com.thoughtworks.paranamer:paranamer-asm:jar:1.0.1 > [INFO] : com.thoughtworks.paranamer:paranamer:jar:1.0.1 > [INFO] : asm:asm:jar:3.0 > [INFO] org.beanshell:bsh:jar:2.0b4 > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD SUCCESSFUL > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 5 seconds > [INFO] Finished at: Wed Sep 05 13:03:28 CEST 2007 > [INFO] Final Memory: 3M/6M > [INFO] ------------------------------------------------------------------------ Also see dependency:tree under MDEP-100. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with MavenJason van Zyl wrote:
> > Anyone have anything else? I'm not trying to consider everything that Any chance that mvn could indicate the exact pom.xml locations of duplicated projects ? So instead of this: ------------------------------------------------------------------------ [INFO] Project 'testgroup:testartifactA' is duplicated in the reactor [INFO] ------------------------------------------------------------------------ something like: ------------------------------------------------------------------------ [INFO] Project 'testgroup:testartifactA' is duplicated in the reactor [INFO] This project is defined by following poms: [INFO] - /tmp/project/module1/pom.xml [INFO] - /tmp/project/module2/pom.xml ------------------------------------------------------------------------ Regards Jorg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: What can possibly go wrong with MavenOn 8 Sep 07, at 11:38 AM 8 Sep 07, Jorg Heymans wrote: > Jason van Zyl wrote: >> Anyone have anything else? I'm not trying to consider everything that > > Any chance that mvn could indicate the exact pom.xml locations of > duplicated projects ? > No reason why it couldn't, we know the source of everything at some point. Noted. > So instead of this: > ---------------------------------------------------------------------- > -- > [INFO] Project 'testgroup:testartifactA' is duplicated in the reactor > [INFO] > ---------------------------------------------------------------------- > -- > > something like: > > ---------------------------------------------------------------------- > -- > [INFO] Project 'testgroup:testartifactA' is duplicated in the reactor > [INFO] This project is defined by following poms: > [INFO] - /tmp/project/module1/pom.xml > [INFO] - /tmp/project/module2/pom.xml > ---------------------------------------------------------------------- > -- > > Regards > Jorg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@... > For additional commands, e-mail: dev-help@... > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
| Free embeddable forum powered by Nabble | Forum Help |