Re versions, I know the background on it, but it annoys me that maven can't handle 4 part versions, 1.2.3.4 as sometimes it's handy to do a patch level that deep. Lots of messed up software in the world :-)
Format should be N[.N as many times as needed][optional hyphen and qualifier of some sort] or something like that. Not hard limited to 1 2 or 3 parts. On 10 January 2018 at 22:21, Andreas Sewe < [email protected]> wrote: > 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> > > >
