On Jun 19, 2007, at 7:29 PM, Karan Malhi wrote:
David, We should version our plugins explicitly. This way we dont have to worry about a latest plugin messing up the build process. I myself went through days of working with maven just to get a some filtering to work. Maven users group was also of little help as everybody was facing the same issue. I also agree on externalizing the messages. Maybe some day I could add some messages in Gurmukhi language :)
Cool! If only my tech vocabulary in Spanish wasn't so terrible I could help there :)
The first thing I can think of is to look at our pom.xml files and find any plugin which has not been versioned or tested (I myself did not version the maven resources-plugin which I used in my latest patch, couldnt do it at that time. Will fix that along with some cleanup required for the final build). It would be a real waste of time and energy if this logging issue was fixed and some plugin again came in and messed it up. Changing versions manually, will atleast give an idea as to which plugin caused the problem.
Right, I definitely think nailing down the plugin versions will help stabilize our build.
But as far as logging goes we still need to find a way to yank control from maven as we still have everyone else's build to worry about who will use OpenEJB to embedded test their ejbs. We need an absolute guarantee that when we say "this didn't work" they get that message.
When you say to configure log levels via test cases, do you mean a test case should be able to control its own log level?
Pretty much. Each test gets it's own "OpenEJB" already, should be fine to throw in some info as to what they want the log levels to be in addition to the other options they can already set via properties passed into the LocalInitialContextFactory.
-David
On 6/19/07, David Blevins <[EMAIL PROTECTED]> wrote:So I'm in the process of trying to get our build working again -- new interceptor tests don't pass -- and it seems in the latest version of maven or one of it's plugins the log levels have changed *again* and *all* of our log statements are going right into the bit bucket (i.e. nowhere). Now I'm stuck adding print statements trying to figure out which apps are picking up in the classpath, which beans are being deployed, what their deployment ids are, and what their jndi names are. Users will never be able to stomach that. Meanwhile we already have logging statements for all of these and more, but we just can't get maven to output anything at build time. At one point, we were getting zero log info like we have now and I fought with maven for days trying to get it to spit out anything at all and days more to get it to print out just the right balance of messages. And then of course it all stops working again on some random plugin update at a moments notice. If there's someone out there who wants to take a crack at saving us and our embedded testing users from maven's logging control that would be most excellent. I have some ideas but little patients to spare ... and truth be told (i seem to like that phrase lately) there is a lot of work in the logging area and it would be fantastic for someone(s) to step and wrestle this beast to the ground. Certainly a very excellent area for contribution. So some of the ideas: - Maybe use the vm's util logging instead of log4j. 1. Maven controls log4j via commons logging and we might be able to take control back if we used something else. 2. Log4j is one extra library we might be able to shave out of our distro size. - We should be able to set log levels *in a test case*. If I'm trying to debug why a test is failing first thing I'll want to do is turn the log levels up. We can already configure just about anything via the properties passed into the InitialContextFactory, we should be able to configure that too. - We have absolutely no docs on how to tweak the logging and what info is available for people for people. We don't need a complete reference, but the very minimum we should have a doc with some basic advice on how to get more out of the logging statements. - As always, we have a ton of non-externalized messages which need to be put into property files. Manu mentioned this one the other day and I totally agree. - The relationship between where the i18n messages properties file lives and where the code lives has drifted apart over the years and now pretty much has no discernible relationship at all. We should have a properties file for each package, but we don't. There's likely more that I can't think of just now. What do others think and who has any energy they could put into this? And don't forget several forms of contribution are possible (creativity is the only real limit) and you don't need to be a committer to join the fun. -David-- Karan Malhi
