Re: What can possibly go wrong with Maven
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 ? 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
On 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
On 05/09/2007, Jörg Schaible [EMAIL PROTECTED] wrote: You mean something like this? [EMAIL PROTECTED] ~/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
Mauro 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? [EMAIL PROTECTED] ~/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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
On 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
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. - Brett -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What can possibly go wrong with Maven
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. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What can possibly go wrong with Maven
On 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 - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What can possibly go wrong with Maven
Component not found Missing goal in plugin (probably the wrong version) -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]