ranges.add(new RangeValue(token.replace("]", ""), true));
            } else if (token.endsWith(")")) {
                ranges.add(new RangeValue(token.replace(")", ""), false));
            } else if (token.isEmpty()) {
                ranges.add(new RangeValue("", false));
            }
        }
        if (ranges.size() < 2) {
            ranges.add(new RangeValue("99999999", false));
        }

        // have a model that is suitable, yet more checks are done here and the one for the version is problematic
        // before because with parents as ranges it will never work in this scenario.
        //

        String groupId = getGroupId(candidateModel);
        String artifactId = candidateModel.getArtifactId();

        if (groupId == null

            For example, {@code 1.4} only activates on JDKs versioned 1.4,
            while {@code !1.4} matches any JDK that is not version 1.4. Ranges are supported too:
            {@code [1.5,)} activates when the JDK is 1.5 minimum.
          </description>
        </field>
        <field>
          <name>os</name>
          <version>4.0.0+</version>

     *     <li>"e(G:A:V)" - predicate filter (leaves out G:A:V from range, if hit, V can be range)</li>
     * </ul>
     * Example filter expression: {@code "h(5);s;e(org.foo:bar:1)} will cause: ranges are filtered for "top 5" (instead
     * full range), snapshots are banned if root project is not a snapshot, and if range for {@code org.foo:bar} is
     * being processed, version 1 is omitted.
     *
     * @since 4.0.0

    Version parseVersion(@Nonnull String version);

    /**
     * Parses the specified version range specification, for example "[1.0,2.0)".
     *
     * @param range the range specification to parse, must not be {@code null}
     * @return the parsed version range, never {@code null}
     * @throws VersionParserException if the range specification violates the syntax rules of this scheme
     */
    @Nonnull

        return new DefaultVersion(versionScheme, version);
    }

    @Override
    public VersionRange parseVersionRange(String range) {
        requireNonNull(range, "range");
        return new DefaultVersionRange(versionScheme, range);
    }

    @Override
    public boolean isSnapshot(String version) {
        return checkSnapshot(version);
    }

                "Expected 'UnresolvableModelException' not thrown.");
        assertEquals("No versions matched the requested parent version range '[2.0,2.1)'", e.getMessage());
    }

    @Test
    void testResolveParentThrowsUnresolvableModelExceptionWhenUsingRangesWithoutUpperBound() throws Exception {
        final Parent parent = new Parent();

    /**
     * Expands a version range to a list of matching versions, in ascending order.
     * For example, resolves "[3.8,4.0)" to "3.8", "3.8.1", "3.8.2".
     * The returned list of versions is only dependent on the configured repositories and their contents.
     * The supplied request may also refer to a single concrete version rather than a version range.

 * that it can be marshalled and unmarshalled without being tainted by runtime requirements.
 * </p>
 * <p>
 * With changes during 3.2.2 release MavenProject is closer to being immutable after construction with the removal of
 * all components from this class, and the upfront construction taken care of entirely by the {@link ProjectBuilder}.

        </field>
        <field>
          <name>requiredJavaVersion</name>
          <version>1.1.0+</version>
          <description>
            A version range which specifies the supported Java versions. A version range can either use the usual mathematical syntax "[2.0.10,2.1.0),[3.0,)" or use a single version "2.2.1". The latter is a short form for "[2.2.1,)", i.e. denotes the minimum version required.