Scott Stirling wrote: >>I see this problem from a bit different perspective. Most, if not any >>single project - multiple jars concerns can be solved by structuring the >>codebase corectly.
First of all, please remember that I'm speaking for myself only, not for the Maven project as a whole. I'm not even a commiter at all. I'm just a person who uses the, and participates in the mailing lists. > "Correctly" -- a 30 person project with multiple teams, thousands of lines of > code and several 3rd party dependencies doesn't map to the simple "correctness" > of, e.g., jakarta-commons-lang. Ya gotta think bigger, more complicated, and > add a few professional managers to understand my situation. I'm sorry didn't mean to offend you. Be assured that maven works for things bigger that jakarta commons. Vincent says his company is running 300+ interconnected Maven projects, and the thing I'm working on is roughly 300k lines of code (cut 30% for javadocs). I know this ain't no kindergarten, but I couldn't resist saying that... >>It's not that maven is really lacking anything, it just encourages >>different approach to codebase management that is currently used by >>many projects. > I would say "enforces" rather than "encourages." Maven is lacking support for > multiple codebases and outputs per project. Believe me, I would love to > organize our whole project like Jakarta Commons, but things are a lot more > complicated in medium to large commercial software projects. But obviously a > tool designed to build tip revisions of Jakarta Commons out of CVS is going to > have to stretch to accomodate larger and more "sophisticated" (or 'incorrect') > project structures. We are trying to provide you with tools that will enable you do decrease that complication and make your work easier and more efficient. >>I'm aware that restructuring may be not a feasible option >>for many of them, so Maven provides support for 'incorrect' codebase >>sturcturing to some extent. > > You should reconsider your use of "correct" and "incorrect"; it sort of > discounts smart people who are more concerned about whether the tool is > reasonably flexible than whether they meet your notion of "correct" project > management. Again it was not my intention to offend you. By 'correnct' I meant structures that are modular thus easy to manipulate, clear and easy to understand. By 'incorrect' I meant structures that are unwieldy, hard to understand, and causing immense suffering whenever need arises to add or replace a part of those. The ambition of the Maven project is to provide guidelines for structuring the project that are good for the developers - easy to maintain and understand. The build/documentation tool that is being developed is just a part of the story. If you structure your project according to the guidelines, it is expected that you will be able to decomission Maven tool at some point and replace it with other tool and the transition process will be straightforward and easy (this depends much on the tool you are moving to, but Maven guidelines try to avoid any unnecessary complication on the maven side) >>Over time this support may be further >>improved, but this is not a high priority goal. > > It should be. I think things will get better -- if more people start to use > Maven and contribute back to it, everything should improve. I am willing to > help. That's excellent. Everyone around here is looking forward to your contributions. R. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
