ok, I suppose this is a reminiscence of Maven 2: yes, in Maven 2, there was this limitation that caused multiple issues linked in MNG-3010 https://issues.apache.org/jira/browse/MNG-3010
As Robert Scholte noticed, perhaps there are still a few glitches with some plugins here and there, that require precise description to be fixed It's good to have memory: now, I hope the fix for MNG-3010 is part of our common memory :) Regards, Hervé Le mercredi 10 janvier 2018, 23:47:13 CET Fred Cooke a écrit : > Looks like I'm just plain wrong (and happy about it). I'm not sure where > that memory came from. Perhaps maven 2 some time ago, though it felt fresh > in my mind. Apologies for the noise! :-( > > On 11 January 2018 at 11:22, Hervé BOUTEMY <[email protected]> wrote: > > Le mercredi 10 janvier 2018, 10:21:35 CET Andreas Sewe a écrit : > > > 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. > > > > +1 > > > > > > 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 > > > > I was not talking about a version with 4 parts: Maven 3 supports an > > arbitrary > > count of parts. > > I was talking about an artifact that is released 4 times per day, because > > it's > > continuous delivery (I suppose): a vast majority of releases are IMHO > > never > > used > > > > > (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 > > > > +1 > > > > > 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]. > > > > +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. > > > > +1 > > > > > 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. > > > > +1 again > > > > > > 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). > > > > probably ".." should be forbidden also > > > > > > - 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]). > > > > +1 > > there is an edit button near the title to find the source and propose a PR > > > > :) > > > > Regards, > > > > Hervé > > > > > 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> > > > > --------------------------------------------------------------------- > > 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]
