You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Joerg Hohwiller <jo...@j-hohwiller.de> on 2008/01/26 00:52:51 UTC
source of missing dependency unclear
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
typically if maven fails with something like "required artifact is missing"
you can have a look at the module where the error occurred and scan
the dependencies.
As additional support maven typically prompts an error report including
something like this:
~ Path to dependency:
~ 1) net.sf.mmm:mmm-uit-impl-swt:jar:0.9.0-SNAPSHOT
~ 2) org.eclipse.swt:swt:pom:3.3.0
~ 3) org.eclipse.swt:swt-linux-gtk:jar:3.3.0
Excellent.
However there are still many situations where somewhere deep inside maven
an artifact is required that is missing but the user does NOT get a tiny clue
what is going on.
In most cases you do not know which plugin requested the artifact and caused the
problem or anything like that.
Even worse sometimes the required artifact is obviously located in the local
repository but for some reason maven says it is missing.
I still remember several times where a buggy plugin was released and my maven
got an update and further builds all ended with something like
"maven-resources-plugin not found".
I really love maven! It is great, it is cool, it rescues the world.
But sorry to say this: the logging and error handling in maven is (partially)
shitty.
You know these kind of
"This project has been banned from further executions due to previous failures"
but however there are no previous failures even if you start with "-X".
In these moments a user comes to the point that maven is just a magic wizzard
and if he is in a bad mood you can not do anything against it.
Or what about eclipse:eclipse and the reactor summary that says
all is successfully but if you really read the entire log you will see
that many errors occurred?
IMHO there is a design problem in the way a MOJO can report an error.
If it throws a MojoExecutionException or -Failure the complete build stops
(except for -fn and maybe -fae).
If it does NOT, the maven-core can not know the problem and the reactor
summary says SUCCESS.
So please do not get me wrong. I want to say thanks for maven which is an
excellent product but please consider improving exception handling, error
tracking and logging in 2.1 and above as well as all mojo developers (including
myself) should do.
Best wishes
~ Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHmnZTmPuec2Dcv/8RAg90AJ9GS+5og9hs1Iw371GfFNH/0dNjrQCgkuGw
sQRXaoKucjsMvDjXYcHtpxM=
=DCZ/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: source of missing dependency unclear
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| Hi Joerg,
Hi John,
(top-posting this time)
thanks for your detailed response. I am very happy to hear that you
care and take this serious. Further I will be one of the early adopters
if 2.1-alpha is out. Maybe I will find the time to test an 2.1 integration build
before...
Thanks
~ Jörg
|
| I'm sorry to hear you're having such difficulty with maven and its
| error-reporting. All I can offer by way of consolation right now is that
| I've revamped error reporting pretty substantially over the past few
| weeks. I started by analyzing all errors that hit the
| MavenExecutionResponse (and are subsequently reported at the end of the
| build by the CLI class in Maven), then tracing these back to their root
| causes, or as nearly as I can do within the confines of maven itself
| (not the plugin code, since this could come from anywhere). In each
| case, I've tried to give the user an error message with the details that
| will help him solve the issue. I'm sure it's not perfect, but it's got a
| much stronger test suite behind it, which goes to great lengths to
| reproduce each error condition in a live test-project build. The new
| error-message formatter also has a stubbed class that will allow us to
| provide links to various documentation sites for hints on solving that
| particular problem...these need to be fleshed out, but some of the basic
| problems have links to documentation out on maven.apache.org currently.
|
| All of this is in Maven's trunk in Subversion, which is the branch where
| we're pushing toward a 2.1-alpha-1 release sometime this quarter
| hopefully (unless something comes up to derail the remaining work slated
| for that release, of course).
|
| As for warnings and other things that happen in mojos but aren't thrown
| as exceptions, it's an interesting idea to provide a recording Log
| instance to the mojo, that would allow maven's core reporting
| infrastructure to reproduce those warnings (in addition to errors and
| other non-exception output above the INFO log-level) in the build
| results at the end. I'd be a little concerned about making that output
| noisy and obscuring the error-formatting work described above, but I'm
| sure we can find a way to strike a balance there in most cases.
|
| I'm filing this idea under MNG-3381
| (http://jira.codehaus.org/browse/MNG-3381) and will put it on my agenda
| to revisit it next time I come back to error reporting.
|
| Thanks,
|
| -john
|
| On Jan 25, 2008, at 6:52 PM, Joerg Hohwiller wrote:
|
| Hi there,
|
| typically if maven fails with something like "required artifact is
| missing"
| you can have a look at the module where the error occurred and scan
| the dependencies.
| As additional support maven typically prompts an error report including
| something like this:
|
| ~ Path to dependency:
| ~ 1) net.sf.mmm:mmm-uit-impl-swt:jar:0.9.0-SNAPSHOT
| ~ 2) org.eclipse.swt:swt:pom:3.3.0
| ~ 3) org.eclipse.swt:swt-linux-gtk:jar:3.3.0
|
| Excellent.
|
| However there are still many situations where somewhere deep inside maven
| an artifact is required that is missing but the user does NOT get a
| tiny clue
| what is going on.
| In most cases you do not know which plugin requested the artifact and
| caused the
| problem or anything like that.
| Even worse sometimes the required artifact is obviously located in the
| local
| repository but for some reason maven says it is missing.
| I still remember several times where a buggy plugin was released and
| my maven
| got an update and further builds all ended with something like
| "maven-resources-plugin not found".
|
| I really love maven! It is great, it is cool, it rescues the world.
| But sorry to say this: the logging and error handling in maven is
| (partially)
| shitty.
| You know these kind of
| "This project has been banned from further executions due to previous
| failures"
| but however there are no previous failures even if you start with "-X".
| In these moments a user comes to the point that maven is just a magic
| wizzard
| and if he is in a bad mood you can not do anything against it.
|
| Or what about eclipse:eclipse and the reactor summary that says
| all is successfully but if you really read the entire log you will see
| that many errors occurred?
| IMHO there is a design problem in the way a MOJO can report an error.
| If it throws a MojoExecutionException or -Failure the complete build
| stops
| (except for -fn and maybe -fae).
| If it does NOT, the maven-core can not know the problem and the reactor
| summary says SUCCESS.
|
| So please do not get me wrong. I want to say thanks for maven which is an
| excellent product but please consider improving exception handling, error
| tracking and logging in 2.1 and above as well as all mojo developers
| (including
| myself) should do.
|
| Best wishes
| ~ Jörg
|>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
|>
| ---
| John Casey
| Committer and PMC Member, Apache Maven
| mail: jdcasey at commonjava dot org
| blog: http://www.ejlife.net/blogs/john
| rss: http://feeds.feedburner.com/ejlife/john
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHn65MmPuec2Dcv/8RAgyRAKCMy2FkR1PwwHhKKWLzRjvmgyg+kwCgmeYp
ZC3oeGCna9jpkkl44Rum/Wg=
=mbtP
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: source of missing dependency unclear
Posted by John Casey <jd...@commonjava.org>.
Hi Joerg,
I'm sorry to hear you're having such difficulty with maven and its
error-reporting. All I can offer by way of consolation right now is
that I've revamped error reporting pretty substantially over the past
few weeks. I started by analyzing all errors that hit the
MavenExecutionResponse (and are subsequently reported at the end of
the build by the CLI class in Maven), then tracing these back to
their root causes, or as nearly as I can do within the confines of
maven itself (not the plugin code, since this could come from
anywhere). In each case, I've tried to give the user an error message
with the details that will help him solve the issue. I'm sure it's
not perfect, but it's got a much stronger test suite behind it, which
goes to great lengths to reproduce each error condition in a live
test-project build. The new error-message formatter also has a
stubbed class that will allow us to provide links to various
documentation sites for hints on solving that particular
problem...these need to be fleshed out, but some of the basic
problems have links to documentation out on maven.apache.org currently.
All of this is in Maven's trunk in Subversion, which is the branch
where we're pushing toward a 2.1-alpha-1 release sometime this
quarter hopefully (unless something comes up to derail the remaining
work slated for that release, of course).
As for warnings and other things that happen in mojos but aren't
thrown as exceptions, it's an interesting idea to provide a recording
Log instance to the mojo, that would allow maven's core reporting
infrastructure to reproduce those warnings (in addition to errors and
other non-exception output above the INFO log-level) in the build
results at the end. I'd be a little concerned about making that
output noisy and obscuring the error-formatting work described above,
but I'm sure we can find a way to strike a balance there in most cases.
I'm filing this idea under MNG-3381 (http://jira.codehaus.org/browse/
MNG-3381) and will put it on my agenda to revisit it next time I come
back to error reporting.
Thanks,
-john
On Jan 25, 2008, at 6:52 PM, Joerg Hohwiller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi there,
>
> typically if maven fails with something like "required artifact is
> missing"
> you can have a look at the module where the error occurred and scan
> the dependencies.
> As additional support maven typically prompts an error report
> including
> something like this:
>
> ~ Path to dependency:
> ~ 1) net.sf.mmm:mmm-uit-impl-swt:jar:0.9.0-SNAPSHOT
> ~ 2) org.eclipse.swt:swt:pom:3.3.0
> ~ 3) org.eclipse.swt:swt-linux-gtk:jar:3.3.0
>
> Excellent.
>
> However there are still many situations where somewhere deep inside
> maven
> an artifact is required that is missing but the user does NOT get a
> tiny clue
> what is going on.
> In most cases you do not know which plugin requested the artifact
> and caused the
> problem or anything like that.
> Even worse sometimes the required artifact is obviously located in
> the local
> repository but for some reason maven says it is missing.
> I still remember several times where a buggy plugin was released
> and my maven
> got an update and further builds all ended with something like
> "maven-resources-plugin not found".
>
> I really love maven! It is great, it is cool, it rescues the world.
> But sorry to say this: the logging and error handling in maven is
> (partially)
> shitty.
> You know these kind of
> "This project has been banned from further executions due to
> previous failures"
> but however there are no previous failures even if you start with "-
> X".
> In these moments a user comes to the point that maven is just a
> magic wizzard
> and if he is in a bad mood you can not do anything against it.
>
> Or what about eclipse:eclipse and the reactor summary that says
> all is successfully but if you really read the entire log you will see
> that many errors occurred?
> IMHO there is a design problem in the way a MOJO can report an error.
> If it throws a MojoExecutionException or -Failure the complete
> build stops
> (except for -fn and maybe -fae).
> If it does NOT, the maven-core can not know the problem and the
> reactor
> summary says SUCCESS.
>
> So please do not get me wrong. I want to say thanks for maven which
> is an
> excellent product but please consider improving exception handling,
> error
> tracking and logging in 2.1 and above as well as all mojo
> developers (including
> myself) should do.
>
> Best wishes
> ~ Jörg
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFHmnZTmPuec2Dcv/8RAg90AJ9GS+5og9hs1Iw371GfFNH/0dNjrQCgkuGw
> sQRXaoKucjsMvDjXYcHtpxM=
> =DCZ/
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john