Re: What can possibly go wrong with Maven

2007-09-08 Thread Jorg Heymans

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

2007-09-08 Thread Jason van Zyl


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

2007-09-07 Thread Mark Hobson
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

2007-09-05 Thread Jörg Schaible
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

2007-09-04 Thread Brett Porter
- 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

2007-09-04 Thread Jörg Schaible

- 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

2007-09-04 Thread Jason van Zyl


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

2007-09-04 Thread Brett Porter


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

2007-09-04 Thread Jörg Schaible
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

2007-09-04 Thread Brett Porter


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

2007-09-04 Thread Mauro Talevi
- 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

2007-09-04 Thread Brian E. Fox
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]



What can possibly go wrong with Maven

2007-09-03 Thread Jason van Zyl

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]