Tamas, I cannot predict when, but once it will be done in a "machine way" or a mathematical/logical proof will be discovered that it is impossible. Agreed, it will not be easy.
2009/10/6 Tamás Cservenák <[email protected]>: > Not to mention that these below are "formal" requirements only. Their > _presence_ is required, but nothing is said about their _content_.I can > publish a POM that will _have_ dependencies section, but how do we know that > the dependencies section is _correct_? > > Also: license in POM. What license "name" is allowed? Are they keyed by by > license URL? Etc... > > Many of these are pretty hard to determine in "machine way".... > > ~t~ > > On Tue, Oct 6, 2009 at 2:26 AM, Brian Fox <[email protected]> wrote: > >> On Mon, Oct 5, 2009 at 3:16 PM, Albert Kurucz <[email protected]> >> wrote: >> > Brian, >> > >> >> Ok then, I assert they are all fine. Now you can provide a list and >> >> refute me ;-). >> > In this case (if they were all fine) here is your list: >> > http://repo2.maven.org/maven2/.index/ >> > (But unfortunately they are not all fine.) >> > >> >> Seriously, the definition of "broken" depends on the observer. >> > True. This is why maybe there should be different "Good lists" and >> > users should be allowed to choose, depending on their taste. >> > >> >> Before we can >> >> "fix" anything "broken" we need to start by defining what you think is >> >> broken and why. >> > >> > One of the possible Definitions of "Good list", which I would like >> > call "Maven Central Compliance" is defined here: >> > http://maven.apache.org/guides/mini/guide-central-repository-upload.html >> > If artifacts are on Central which are not on this list (which list >> > should really be realized soon), I don't mind, as long as I could >> > search or filter by this list. >> > You cannot objectively define what is "broken" only if you specify >> > which Lists you are talking about. Do you mean, the "Maven Central >> > Compliance" list? >> >> I assume you mean this list of requirements? >> There are some requirements for the minimal information in the POMs >> that are in the central repository. At least these must be present: >> >> modelVersion >> groupId >> artifactId >> packaging >> name >> version >> description >> url >> licenses >> scm url >> dependencies >> >> I don't think that I would consider things broken simply because the >> name, description, url, scm url where missing. I would be annoyed but >> not surprised if the license wasn't populated correctly. So if you're >> saying you want to exclude everything from your build simply because >> one of those are missing, then I think we fundamentally disagree. Yes >> it would be nice if those were filled in properly but none of those >> reduce the usefulness of users to a point where they simply should be >> treated like they don't exist. >> >> I consider things broken if the pom doesn't parse, the dependencies >> are wrong (again subject to perspective in some cases), the gav isn't >> correct, the checksums or signatures are broken. Otherwise from a >> repository perspective they are not broken. >> >> If you attempt to enumerate all the things in central that match all >> of those values above and build a repo of only those, it will be a >> nearly useless repo. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
