Davanum Srinivas wrote:
So can we figure out another way to make the end user make a conscious decision? I doubt we will get much help from the maven team to support this use case. They would rather get the central repo and get it done! What bugs me is that in this whole discussion, no one even mentions how easy it is to add another repo in the poms or the settings.
No - that doesn't help the user make any decision whatsoever. If you plug your fedora distribution into the livna repository for a single package that you -know- might be patent encumbered, you probably won't realize when you yum install 20 more encumbered packages. It's the top-level package that maven cares about. That package's choice to pick up an incubating dependency is the package issue. Nobody is going to even know what Apache Incubating Foo project was about, all they will know is that the Bar project broke if Foo disappears. If people think more in terms of a filesystem repository, which is what Maven provides, rather than a website presentation dependency graph, this really does become a dead issue. Do we demand that your local checkout of incubator respositories is to /tmp/... ? Maven provides many third party objects that are of top quality, and those of subpar quality. It's simply a mirroring system. We just got finished determining that /dist/incubator/ must be on the mirrored main tree. Why are people so upset that we would follow the *exact same pattern* for maven? Look, Maven serves packages. Websites describe projects. Yes, every project dependent on an incubating artifact should provide *website* disclaimers that a piece of their project could fall off the earth. They probably won't. But what's handy is that crawling Maven, you might actually learn what projects consume incubating artifacts already, and possibly grow some incubating communities due to such dependencies. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
