Hi Christian, Le jeudi 28 septembre 2017, 11:05:10 CEST Christian Balzer a écrit : > Hi Hervé, > > Thanks for your help. I'm not sure I like the answer, to be honest, looks you clearly understood the answer :)
> although I perfectly understand the reasoning. I think that we need to better spread the word about that > I'll get in touch with > the library maintainers of those libraries my project uses (hoping > they all still have maintainers). this is where changing maven-metadata.xml without the explicit permission of original authors is necessary: I suppose this will happen, and ideally a process for community decision would be found > > The list of inconsistencies looks rather daunting. It certainly does > mean that version ranges aren't as useful as they could be, if they > won't work properly in a lot of cases... I'm personally a version range sceptical for a long time, and looking for constructive debate to find precisely why and where version ranges may be useful and where definitely it is a bad idea. Your case leads me to an idea: when you're using version ranges on your internal artifacts, where you master everything of the artifact lifecycle and want rapid changes but don't care so much about reproducibility, perhaps version ranges may be useful. On public artifacts published on central, yes, version ranges may not be as useful since artifact providers did often not really manage this use case (but even if metadata are ok, change is not so fast) > > On a related matter, is there an element for the maven-metadata.xml > file that's similar to the pom's relocation element? (Not sure what > the automatic resolution would do when it finds out that version 3 of > foo:bar is now called baz:bat (warning or loading the artefact), but I > thought I'd ask anyway...) here is the descriptor documentation for maven-metadata.xml http://maven.apache.org/ref/3.5.0/maven-repository-metadata/repository-metadata.html As you can see, no relocation info. In fact, this metadata file is often managed automagically by tools without people knowing the content (and eventually that it's not consistent) Adding new features to this format would require: - discussion with the whole ecosystem consuming Maven repositories (central or other) to define the feature, check existing tools don't blow up, ... - teaching to users, and perhaps tooling, to modify manually modify and publish the content Feasible but not easy, given one feature of Maven repository format is its stability Regards, Hervé > > Kind regards, > Christian > > On Thu, Sep 28, 2017 at 4:27 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > Hi, > > > > Here is a list of inconsistencies (expected to be extensive) in central > > between maven-metadata.xml and what is in the repo [1] (updated daily): in > > this file, each "+" is about a version that is available in the repo but > > not referenced in maven-metadata.xml, and each "-" is about a version > > that is in maven-metadata.xml but not in the repo > > > > The maven-metadata.xml content is provided by artifact authors: we don't > > really know if they chose to not add some version to their metadata, > > exactly to avoid range resolution, or if they have a tooling issue. > > There are 2 options: > > 1. if they have a tooling issue, whatever we do today to their metadata, > > they will break consistency again next time they publish a new artifact > > version. 2. if it was a voluntary removal from metadata, we'll go against > > artifact owners' will > > > > IMHO, we can't safely "fix" metadata in central, since: > > - what we call a fix from some point of view can be a deliberate choice > > - this will surely be "broken" back later > > > > Artifact owners should check their metadata and fix them if they see that > > the content was not what they wanted (and they just never saw how maven- > > metadata.xml was useful to people using version ranges) > > > > Notice I'd personally not advise to use version ranges: but that remark > > won't help here (and I hope by saying so I won't open a new hot debate > > about version range lovers vs haters: please open another email thread if > > you want to open this debate) > > > > To be direct on the few artifacts you cited, I don't think it's really a > > good idea to change the metadata at our level: it's better to ask the > > original project to check its metadata and fix them if appropriate. > > > > Regards, > > > > Hervé > > > > [1] https://github.com/hboutemy/mcmm-logs/blob/master/metadata-fixes.log > > > > Le mercredi 27 septembre 2017, 11:03:11 CEST Christian Balzer a écrit : > >> Good morning all, > >> > >> Here are the versions I found yesterday that are not listed in their > >> respective maven-metadata.xml files: > >> > >> 1.9.13: > >> http://central.maven.org/maven2/org/codehaus/jackson/jackson-core-asl/mav > >> en > >> -metadata.xml 1.9.13: > >> https://mvnrepository.com/artifact/org.codehaus.jackson/jackson-mapper-as > >> l/ > >> maven-metadata.xml 1.2: > >> http://central.maven.org/maven2/javax/servlet/jstl/maven-metadata.xml > >> 3.2.1: > >> http://central.maven.org/maven2/org/openoffice/juh/maven-metadata.xml > >> 3.2.1: > >> http://central.maven.org/maven2/org/openoffice/jurt/maven-metadata.xml > >> 3.2.1: > >> http://central.maven.org/maven2/org/openoffice/ridl/maven-metadata.xml > >> 3.2.1: > >> http://central.maven.org/maven2/org/openoffice/unoil/maven-metadata.xml > >> 1.1: > >> http://central.maven.org/maven2/org/opensaml/opensaml/maven-metadata.xml > >> 2.1.4-1.2-2.4: > >> http://central.maven.org/maven2/strutstestcase/strutstestcase/maven-metad > >> at > >> a.xml > >> > >> Note that this is the finding of a spot check; there might be more > >> versions missing per artefact than just the ones listed above... > >> > >> Karl Heinz, if you could please add them to the ticket you created, > >> that would be much appreciated. > >> > >> Kind regards, > >> > >> Christian > >> > >> On Tue, Sep 26, 2017 at 10:16 PM, Christian Balzer > >> > >> <christian.at....@gmail.com> wrote: > >> > Hi Karl Heinz, > >> > > >> > Thanks for your help. > >> > > >> > On Tue, Sep 26, 2017 at 4:23 PM, Karl Heinz Marbaise > >> > <khmarba...@gmx.de> > > > > wrote: > >> >> Hi, > >> >> > >> >> based on the feedback I got here: > >> >> https://issues.sonatype.org/browse/MVNCENTRAL-2721 > >> > > >> > When I try to open that ticket (even when being logged in on > >> > > >> > Sonatype's Jira) I get an error message: > >> >> This issue can't be viewed > >> >> The issue you're trying to view can't be displayed. > >> >> It may have been deleted or you don't have permission to view it right > >> >> now. > >> > > >> > Can you please summarise what it said? If it is still accessible, I'll > >> > happily add the ids for the other artifacts I found with the same > >> > problems to it. > >> > > >> > Thanks, > >> > Christian > >> > > >> >> It could be only a little time to be fixed in Maven Central.. > >> >> > >> >> Kind regards > >> >> Karl Heinz Marbaise > >> >> > >> >> On 26/09/17 13:12, Karl Heinz Marbaise wrote: > >> >>> Hi, > >> >>> > >> >>> On 26/09/17 13:02, Christian Balzer wrote: > >> >>>> Hi all, > >> >>>> > >> >>>> I have a pom.xml file of a legacy program that declares a dependency > >> >>>> on an Apache Commons' xml-resolver:xml-resolver via dependency > >> >>>> management and a property. The pom file looks essentially like this: > >> >>>> > >> >>>> <properties> > >> >>>> > >> >>>> <xml-resolver.version>1.2</xml-resolver.version> > >> >>>> > >> >>>> </properties> > >> >>>> <dependencyManagement> > >> >>>> > >> >>>> <dependencies> > >> >>>> > >> >>>> <!-- .. --> > >> >>>> <dependency> > >> >>>> > >> >>>> <groupId>xml-resolver</groupId> > >> >>>> <artifactId>xml-resolver</artifactId> > >> >>>> <version>${xml-resolver.version}</version> > >> >>>> > >> >>>> </dependency> > >> >>>> > >> >>>> <dependencies> > >> >>>> > >> >>>> <dependencyManagement> > >> >>>> <dependencies> > >> >>>> > >> >>>> <!-- ... --> > >> >>>> <dependency> > >> >>>> > >> >>>> <groupId>xml-resolver</groupId> > >> >>>> <artifactId>xml-resolver</artifactId> > >> >>>> <version>${xml-resolver.version}</version> > >> >>>> > >> >>>> </dependency> > >> >>>> > >> >>>> <dependencies> > >> >>>> > >> >>>> This works; version 1.2 does exist: > >> >>>> http://central.maven.org/maven2/xml-resolver/xml-resolver/1.2/ > >> >>>> > >> >>>> We now wanted to move to dependency ranges, to automatically pull in > >> >>>> the latest minor and patch releases: > >> >>>> > >> >>>> https://maven.apache.org/pom.html#Dependency_Version_Requirement_Spe > >> >>>> cif > >> >>>> ication > >> >>>> > >> >>>> However, when I change the version range to [1.2,2.0) (i.e. all > >> >>>> release versions from 1.2 inclusive to 2.0 exclusive) I get the > >> >>>> > >> >>>> following error message: > >> >>>>>> [ERROR] Failed to execute goal on project bar: Could not resolve > >> >>>>>> dependencies for project com.example.foo:bar:pom:1.0-SNAPSHOT: > >> >>>>>> Failed > >> >>>>>> to > >> >>>>>> collect dependencies at xml-resolver:xml-resolver:jar:[1.2,2.0): > >> >>>>>> No > >> >>>>>> versions available for xml-resolver:xml-resolver:jar:[1.2,2.0) > >> >>>>>> within specified range -> [Help 1] > >> >>>> > >> >>>> I also tried version [1.2] (exact version range) with the same > >> >>>> result. > >> >>>> After some googeling, I had a look at maven central's manifest for > >> >>>> that artifact, located at > >> >>>> > >> >>>> http://central.maven.org/maven2/xml-resolver/xml-resolver/maven-meta > >> >>>> dat > >> >>>> a.xml > >> >>>> > >> >>>> It turns out that the metadata only specifies version 1.1: > >> >>>> <versions> > >> >>>> > >> >>>> <version>1.1</version> > >> >>>> > >> >>>> </versions> > >> >>>> > >> >>>> Is that the reason maven can't resolve the artifact with the > >> >>>> dependency range given? > >> >>>> Does that mean the metadata on maven central is corrupted? > >> >>> > >> >>> That looks like that. > >> >>> I have filed in a ticket for that problem. > >> >>> > >> >>> https://issues.sonatype.org/browse/MVNCENTRAL-2721 > >> >>> > >> >>> Kind regards > >> >>> Karl Heinz Marbaise > >> >>> > >> >>>> If so, where do I report the issue to get it fixed? > >> >>>> Is there another way to make this work (e.g. by asking our Nexus > >> >>>> mirror to do some magic)? > >> >>>> And last but not least: are there ever scenarios where previously > >> >>>> published versions are removed from the metadata file on central > >> >>>> (but > >> >>>> not the jar files themselves)? > >> >>> > >> >>> There are in extraordanary circumstances under which this can > >> >>> happen...but > >> >>> it is extremely rare...(Only based on special license issues...)... > >> >>> > >> >>>> I found 9 other artifacts so far that have the same issue... > >> >>> > >> >>> Which artifacts ? With the above problem releated to the metadata ? > >> >>> > >> >>>> NB: When I run java -jar maven-artifact-3.1.0.jar [versions...] as > >> >>>> described on https://maven.apache.org/pom.html#Version_Order_Testing > >> >>>> I > >> >>>> > >> >>>> get an error message: > >> >>>>>> no main manifest attribute, in maven-artifact-3.1.0.jar > >> >>> > >> >>> This works only from Maven 3.2.5+ not before... > >> >>> > >> >>> See release notes for detail... > >> >>> > >> >>> Kind regards > >> >>> Karl Heinz Marbaise > >> >>> > >> >>>> I'm running Apache Maven 3.3.9 and that's the latest jar in my local > >> >>>> repo. (The docs specify version 3.3.9 for the actual jar.) Do I need > >> >>>> to pull the latest one, or is something else broken there? > >> >>>> > >> >>>> Kind regards, > >> >>>> Christian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
