Let projects have parents with no artifacts.

[jkinkead]

This fixes #61 , but at the expense of being sloppy with artifact validation.

Feel free to close if you think this is unacceptable.

[bazel-io]

Can one of the admins verify this patch?

[petroseskinder]

I am not a fan of this.

if (isInvalidRangeResult(versions)) {
   if (isVersionRange(versionSpec)) { ... } // throw error
   return versionSpec;
}

If you get an invalidrangeresult, it means we couldn't find any valid versions for the versions you specified. For example, if you pass a:b:3.0 and your maven mirror only contains versions 1.0, 2.0, 2.2, then this would be an invalid range result.

If your package resolves using the versionSpec, then it should return a nonempty set of valid versions. At the least, it should return the versionSpec.

Your issue is that the POM file does not have any artifacts, no? In your #61, you state:

This works for the case above, but also lets you create dependencies on jars that don't exist (you can generate a workspace with --artifact=org.sonatype.oss:oss-parent:9). This is almost certainly fine for this tool, since it should assume a valid maven build already.

It seems org.sonatype.oss:oss-parent is specified as version 9 within the POM file. What POM file is empty?

[petroseskinder]

Taking a step back, let me expand on why this function was designed as it is. The basic structure is to

• take a version specification
• request all valid versions
• use some heuristic to select the version within selectVersion

Example Say we passed "4.0", the valid versions are those >= 4.0, and selectVersion would select 4.0, if it exists, and the oldest version if it doesn't. With a version range like [4.0, 5.2), it would obtain all versions valid within that range. Then selectVersion would select the newest version.

Justification Without doing this, it would be infeasible to handle version specs like (3.0, 5.2), or even [4.0, 5.2) for that matter. Maven's heuristic is to select the highest version. Unless the upper bound is inclusive, you will need to obtain all valid versions.

[jkinkead]

The problem is that an empty result means that you couldn't find any valid artifacts - and since this method is used to validate POM files, it ends up throwing an error when your parent POM doesn't have any associated artifacts (bug #61).

The correct fix for #61 is to validate POM files without using the resolveVersion function, but I wasn't quite ready to delve that deeply.

[petroseskinder]

Thanks for the clarification. Looking at the pom file from #61, it does not have any dependencies.

<project xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <parent>
    <groupId>org.sonatype.oss</groupId>
    <artifactId>oss-parent</artifactId>
    <version>9</version>
  </parent>

  <groupId>com.example</groupId>
  <artifactId>example</artifactId>
  <version>0.1.0-SNAPSHOT</version>
  <packaging>pom</packaging>
</project>

What do you mean by parent POM not have any associated artifacts? As in, it does not have any dependencies. From what I can see, the parent POM exists. Although, it does not have any dependencies.

The correct fix for #61 is to validate POM files without using the resolveVersion function, but I wasn't quite ready to delve that deeply.

It is more appropriate to validate POM files without resolveVersion, then to introduce this hack.

Assuming reproducing your issue simply involves copying the POM file, and calling generate_workspace on the POM file, let me play around with this.

[jkinkead]

By "parent POM" I mean the POM file for the <parent> project. You'll notice that it doesn't have any artifacts.

The problem with using validating POM files in this way is that you're requesting the jar artifact from Aether, which isn't required to exist for a valid POM file.

[jkinkead]

Also: I'm 100% fine with this hack not merging. I implemented it solely to get unblocked. :)

[petroseskinder]

The problem with using validating POM files in this way is that you're requesting the jar artifact from Aether, which isn't required to exist for a valid POM file.

I see. By using ArtifactBuilder, any POM files without artifacts will be unduly marked as invalid.

Also: I'm 100% fine with this hack not merging. I implemented it solely to get unblocked. :)

As I don't have an immediate solution to the fundamental problem, let's leave the PR open as a reminder of the issue.

[ghost]

Any plans to implement this? Still having this issue as of Jan 2019