maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <>
Subject Re: Allowed characters in GAV and how/where to sanitize?
Date Wed, 10 Jan 2018 07:43:56 GMT
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.

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)

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 
On the future, perhaps we can do something:
- at Maven level, sure we can and we should improve controls as much as 
- 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
- on repo managers used by the publishers: same rules documentation 
prerequisite, but other tools target
- 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.



Le mardi 9 janvier 2018, 15:42:41 CET Andreas Sewe a écrit :
> Hi Stephen,
> > In an url path segment space is mapped to +
> not quite. This holds only for the query part of an URI which is
> typically encoding according to the application/x-www-form-urlencoded
> scheme. Elsewhere in a URI, e.g., the path component, a space is simply
> percent-encoded a %20.
> > The repo manager should be blocking those... likely not doing it’s job.
> I agree. IMHO the repo manager should block (if only as a last resort
> for people using something to deploy that doesn't do the check earlier).
> That being said, the situation on Maven Central is not that dire; there
> are very few versions in the wild that I consider broken:
> Additional quotes:
> - "1.0.0
> - '1.0'
> CLI trouble:
> - mvn+release:perform
> - version=
> Commas instead of dots as separator
> - 1,0
> Expressions or expression-like constructs:
> - ${env.VERSION}
> - ${parent.version}
> - @metro.version@
> - $%7Bcucumber-jvm.version%7D
> If you are interested, I have a more complete list (about 30 entries
> overall), together with a histogram of characters used in versions.
> Interestingly, no non-ASCII characters are used, not even in qualifiers.
> > We probably should also barf on : in a version. There is validation on
> > artifactId and groupId when last I checked
> Different validators barf on different things. The
> org.apache.maven.*project*.validation.DefaultModelValidator used by
> deploy:deploy-file is happy with *any* non-empty version, whereas
> org.apache.maven.*model*.validation.DefaultModelValidator does a bit
> more; in particular, it checks for certain filesystem-unsafe characters,
> including the colon: \ / : " < > | ? *
> I don't really know why deploy:deploy-file prefers one ModelValidator
> over the other, though. Is this a bug in the the maven-deploy-plugin?
> Best wishes,
> Andreas

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message