Hervé BOUTEMY wrote: > notice that Central contains artifacts produced by Maven but also by other > tools: I did some analysis myself and found strange things also that are > clearly not produced by Maven. Scala for example produces some artifacts that > I doubt could be referenced by Maven.
Yes, Maven is not the only tool that can deploy artifacts to Central -- and that's a good thing. > Then: what do we call "broken"? > Something that seems "clearly" related to a typo? > Something that can't be consumed by Maven? > Something that people who produced the release (with any tooling) won't > consume for syntactic reasons on the result? Something that they won't > consume > for other reasons? (like for example because it's continuous deployment and > it's the 4th version of the day) I wouldn't go so far to treat version=1.6.2.1 as an illegal version (after all, I can image someone using legitimately using a qualifier scheme like 1.2.3-os=linux), but there are IMHO two cases which I always consider broken: - Spaces in any of the components of a GAV - A colon in any of the components of a GAV Spaces are just likely to cause trouble for some tool further down the line. And for colons we know that they will cause trouble, being the default separator for GAVs when written as a single string. Aside from those characters, I would probably just ban a few characters (non-printable control characters). A bit similar to what XML did with a its NCName (non-colon name) production [1]. However, for groudId and artifactId we already have much stricter rules (A-Z, a-z, 0-9, ., -, _), so the argument can be made that versions/classifiers/extensions should also be made up of a more limited character set as well. In particular, care should to be taken that the path component can still be parsed unambiguously, so allowing '.' in a classifier is probably asking for trouble. > And what can we do? > On the past artifacts, removing anything is not really an option: IMHO, the > issue does not deserve the effort and to break our base rule about > inalterability. > On the future, perhaps we can do something: > - at Maven level, sure we can and we should improve controls as much as > possible Yes, if only that at this level we can provide the best error messages, as the error is recognized closest to the user. > - on other build tools: perhaps we should try not only to implement checks in > Maven but also document rules for other tools to implement same rules The Maven Resolver is a great place to enforce some rules in DefaultArtifact (or whatever replaces it). Granted, not everyone deploys using the Maven Resolver, but its *the* place that knows about all the intricacies of the repository layout already. > - on repo managers used by the publishers: same rules documentation > prerequisite, but other tools target Well, Nexus already has some checks in place, to avoid versions like "1/../../other-artifact/2". However, groupIds like "org...example" are still accepted (deployed under org/example). > - on sync to central: this is the only location where some rules can be > checked for absolutely any new artifact then really interesting at a first > glance. But making rules evolve at this level is really hard since there is > no > real feedback process I know of when base Central publication rules are not > met. Base Central publication rules were defined from the beginning > (signature, > ...), then are implemented by publishers' repo managers. I suppose failed > controls done by sync to central (then sync blocked) are rare: I'm not sure > there is a strong process/tooling. And adding it would cost some management: > not easy. IMHO, we should start by first detecting if there are really issues > on new artifacts these days before trying to take actions at this level. That being said, I think the first step is to document the syntax for GAVs somewhere (e.g., at [2] or [3]). Best wishes, Andreas [1] <https://www.w3.org/TR/REC-xml-names/#NT-NCName> [2] <http://maven.apache.org/pom.html#Maven_Coordinates> [3] <http://maven.apache.org/ref/3.5.2/maven-model/maven.html>
signature.asc
Description: OpenPGP digital signature
