Thanks for the concrete example (use-case). Now I understand better at least as a list lurker. I had originally thought you and Michal were debating which way `round to get metadata to the web container, now I see.
So if me were you: I'd login to Jira: create an rfe request attach the patch(es* - w/ documentation as well) vote for the enhancement send the jira issue url to the list with some message like: "...here's the link to the rfe. If you want the option to jar the classes in a war... vote for this issue. I use this so that....logging [etc].." Users could then "vote" for it... committers can get a sense of who's looking for this feature. IMO no feature is without some cost. The new property will likely need to be documented if it's not already with your patch. Inevitably there will be mailing list questions about it (hopefully you'd monitor to answer them.) Any unforeseen issues or downstream affects have to be dealt with - code maintenance. Then in the bigger picture someone else will say why are there so many properties all over, why is maven hard to learn, why isn't there more documentation, why are property names not consistent, why does the war plugin generate more than one artifact. Not lazy..intelligent. -TR > [Brill Pappin wrote:] > Sent: Wednesday, June 30, 2004 10:45 AM > Ok, let me explain this one more time. > [...] > An example of where I specifically use this information: > I'm sure you've seen how you have have log4j output the file and line > number of a log message. Now using the versioning API you can also > output other information as well as the file and line number, such as > what version it is, the module or company it came from... you can even > tell things like what dependencies it has etc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
