-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In my opinion, this thread is not particularly useful. As far as I know, we have not called for a vote on the final release of Maven 2.0. (we haven't even released -beta-1 yet, for crying out loud!)
This is my last reply on this thread; it is fast growing into another bitch session and waste of my time. See my comments inline. Maczka Michal wrote: | | a) build won't be reproductable If you're declaring your API dependencies correctly for your project, this absolutely should not have an impact on you. Any POM cleanup efforts should be directed at eliminating test-scope dependencies, or in some [extremely rare] cases, optional dependencies. The latter case should be covered by your project, since if it uses these optional parts, it should make some use of these same dependencies. | b) the scenario which you are proposing - everybody maintaining its own | maven repository with competing metadata even for open source projects | will become the reality. And this is something which in my opinion won't be | any good for maven nor for improving the quality of the maven central | repository. I already know some people which are creating their own m2 | repositories and the work which there are doing is not at all serving maven | community. I am all for centralising that effort. I know of people who won't use Maven or its repository because the artifacts aren't signed. Sure, there are going to be people who demand a higher level of quality than we are prepared to offer for the meantime; that is unavoidable. However, most users should be fine with the level of quality we can provide, particularly for the dependency use case. Project URLs and such are not as critical for this use case. | | Note then when I am saying that no POMs should not be changed - this means | that no dependency should be added, removed or moved to different position | witin the pom. The algorithm which resolves transitive dependencies is very | fragile: it is even (accordingly to my knowledge) sensitive to the position | of the dependency in the pom. If I understand correctly, you're alluding to the use of the nearest dependency-version taking precedence in a collision scenario. This is the default policy for m2, but doesn't have to be the only one. Before we release m2 final, we will allow (if we don't already) pluggable dependency-version conflict resolution policies. I don't agree that the transitive dep algorithm is so fragile, particularly when you change the version conflict policy...can you be more specific, or will this remain an unsubstantiated claim? | | I also have no better alternative to what's happening now with m2 | repository. But I share Vincent's opinion: | "There needs to be a big effort to clean the m2 repo of bad POMs" and I am | just adding that this in my opinion should happen and ___finish_ | before maven 2.0 will be proclaimed as "final" or even "beta". Otherwise the | situation which happen with m1: some people tried unstable beta versions and | never come back to maven will be repeated one more time. But this time it | won't happen due to the code quality (which is really excellent in case of | m2) but due to the repository related problems. Michal, for me, here's the real bottom line: You're perfectly willing to contribute page after page of email complaining about maven 2.x and its repository. Yet your name doesn't appear on a single MEV JIRA issue (used as a TODO list to help improve the quality of the repository), and you haven't submitted a single issue to the MNG (maven 2.x) JIRA project. You seem to reiterate that we need to do all of this work to get Maven and its repo in shape, but are completely unwilling to do anything but talk about it. If you're concerned about Maven, then you need to know this: no matter what timeline we adopt for Maven's 2.0 release (and deadlines are critical for progress), we will never be ready according to the above criteria if our *very* small development team has to comb through the entire repository and assess the quality/correctness of each individual POM. Additionally, it is simply unreasonable to expect m2 to be relevant to the community in any way if we cannot provide a repository comparable to the m1 repository from day one. My advice: If you're unhappy with the state of the m2 repository, then by all means show us where the problem areas are. Submit a MEV issue or two, if you will. But cracking a whip over our heads without contributing anything the least bit constructive doesn't in any way help this development process. Regards, - -john -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFC0CyGK3h2CZwO/4URArOJAJ90P+evqoN5jVTgdR+nanDP3m1jKgCdF0X9 Adm2p+8xUj1sQqdLUAWw5gw= =0ki0 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
