Invalid version range in Maven doclint-java8-disable profile with gson 2.3

[GoogleCodeExporter]

According to Maven 3.0.4 (maybe other versions) there is an invalid version 
range in the 2.3 POM in the doclint-java8-disable profile.

      <activation>
        <jdk>[1.8,</jdk>
      </activation>

should possibly be 

      <activation>
        <jdk>[1.8,)</jdk>
      </activation>

What steps will reproduce the problem?
1. Create a maven project that depends on gson 2.3
2. Try and build

What is the expected output? What do you see instead?

It should build. Instead I get errors like "Invalid JDK version in profile 
'doclint-java8-disable': Unbounded range [1.8, for project 
com.google.code.gson:gson [etc]"

What version of the product are you using? On what operating system?

gson 2.3 with JDK 7 and Maven 3.0.4

Please provide any additional information below.
Seems to be a common error, I'd guess copy and pasted from Stack Overflow.
https://github.com/junit-team/junit/issues/965
https://github.com/atteo/parent/issues/1

http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html implies it 
must have the trailing parenthese.

Original issue reported on code.google.com by chad.lee...@gmail.com on 15 Aug 2014 at 9:32

[GoogleCodeExporter]

For now, I am switching back to Gson 2.2.4 until this defect is fixed. The POM 
for 2.2.4 doesn't have the problem.

Original comment by bibh...@gmail.com on 20 Aug 2014 at 8:40

[GoogleCodeExporter]

I've observed the same issue with version 2.3 and am also using version 2.2.4 
for the time being

Original comment by palmerw...@gmail.com on 8 Sep 2014 at 11:52

[GoogleCodeExporter]

I have the same issue with maven 2.x. Maven 3.0.5 seem to work fine.

Original comment by fschef...@felix-scheffer.de on 12 Sep 2014 at 8:11

[GoogleCodeExporter]

This issue was closed by revision r1300.

Original comment by limpbizkit on 16 Sep 2014 at 2:40

• Changed state: Fixed

[GoogleCodeExporter]

I noticed there isn't a timeline set for the next release in the Roadmap, so, 
in the meantime, is there a snapshot repository to pick up this change?  
Checking out the one listed here didn't help: 
https://code.google.com/p/google-gson/source/diff?spec=svn1300&r=1300&format=sid
e&path=/trunk/gson/pom.xml

Original comment by john.rod...@gmail.com on 16 Sep 2014 at 5:21

[GoogleCodeExporter]

I'm seeing this

[INFO] Error building POM (may not be this project's POM).

Project ID: com.google.code.gson:gson

Reason: Invalid JDK version in profile 'doclint-java8-disable': Unbounded 
range: [1.8, for project com.google.code.gson:gson

Using

$ mvn --version
Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.7.0_51
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x" version: "10.9.5" arch: "x86_64" Family: "mac"

Original comment by tomkessl...@gmail.com on 29 Oct 2014 at 12:08

[GoogleCodeExporter]

I updated maven version to 3.1.1 and it worked.

Original comment by dfrnasci...@gmail.com on 7 Nov 2014 at 9:20

[GoogleCodeExporter]

Maven 3.2.2 and 3.2.3 have the same issue and refuse to import the broken pom.

Would it be possible to make a release fixing this issue, as it's been already 
2 months since it was fixed?

Original comment by dumitru....@gmail.com on 10 Nov 2014 at 1:45

[GoogleCodeExporter]

Hey Folks.  I'm still seeing this issue as well.  I am unable to reopen this 
myself so will you please re-open it.  Here is what I see on my command line:

Unable to resolve artifact: Unable to get dependency information: Unable to 
read the metadata file for artifact 'com.google.code.gson:gson:jar': Invalid 
JDK version in profile 'doclint-java8-disable': Unbounded range: [1.8, for 
project com.google.code.gson:gson
  com.google.code.gson:gson:jar:2.3

And here is what is in the POM file I am receiving 
(.m2/repository/com/google/code/gson/gson/2.3/gson-2.3.pom):

    <profile>
      <id>doclint-java8-disable</id>
      <activation>
        <jdk>[1.8,</jdk>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <configuration>
              <additionalparam>-Xdoclint:none</additionalparam>
            </configuration>
          </plugin>
        </plugins>
      </build>
    </profile>

Tried nuking local repo and re-downloading twice to no avail.

Original comment by Andrew.S...@gmail.com on 12 Jan 2015 at 6:34

[GoogleCodeExporter]

Should also include my environment info:

$ mvn -v
Apache Maven 3.2.3 (33f8c3e1027c3ddde99d3cdebad2656a31e8fdf4; 
2014-08-11T15:58:10-05:00)
Maven home: /usr/local/Cellar/maven/3.2.3/libexec
Java version: 1.7.0_60, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.10.1", arch: "x86_64", family: "mac"

[artifact:dependencies] from the specified remote repositories:
[artifact:dependencies]   central (http://repo1.maven.org/maven2)

Original comment by Andrew.S...@gmail.com on 12 Jan 2015 at 6:37

[GoogleCodeExporter]

This bug report is against 2.3. It's only fixed in 2.3.1.

Original comment by chad.lee...@gmail.com on 13 Jan 2015 at 12:00

[GoogleCodeExporter]

Ahh... well that explains that.  Would you like me to file a new bug against 
2.3?

Original comment by Andrew.S...@gmail.com on 13 Jan 2015 at 1:37

[GoogleCodeExporter]

I'm just a fellow user/bug reporter/internet citizen, but this is fixed in 
2.3.1 which is available in Maven central so you should try that. Unfortunately 
google code is pretty crappy as an issue mgmt system so it's not obvious here 
which release it was fixed in.

Original comment by chad.lee...@gmail.com on 13 Jan 2015 at 2:02

[GoogleCodeExporter]

> but this is fixed in 2.3.1 which is available in Maven central so you should 
try that

I wish it were that easy (and maybe it is and I am totally missing something) 
but that won't work in my case.  The reason is gson 2.3 is a dependency of 
another artifact I am trying to use (google-maps-services).  Now even if I use 
gson locally in my project (which I do) and I bump up the version of my local 
artifact to 2.3.1 (which I did), mvn will still grab the 2.3 artifact, process 
its pom file and explode.  So I would need to unfairly ask the maintainers of 
the google-services-api to update their dependency (which I did in 
https://code.google.com/p/gmaps-api-issues/issues/detail?id=7525&thanks=7525&ts=
1421186415) even though the issue is not with them, its with the gson code.  
That is not cool since this bug is not their problem nor does the resolution of 
this bug in any way affect the functionality and feature set of Gson.  So IMHO 
the maintainers of the project need to re-release this version with a fixed POM 
file so the rest of us can move on.

But I am also young to maven and perhaps there are workaround that I am unaware 
of.  If you (or anyone else for that matter) happen to know of a better way PM 
me please.  I would love to know it or be shown where to look.  

Original comment by Andrew.S...@gmail.com on 13 Jan 2015 at 10:16

[GoogleCodeExporter]

> But I am also young to maven and perhaps there are workaround that I am 
unaware of.

Use <dependencyManagement> to set the version of gson pulled in as a transitive 
dependency  
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism
.html#Dependency_Management

Original comment by cheis...@squareup.com on 13 Jan 2015 at 10:20

[GoogleCodeExporter]

In any case, software versions are never re-released with the same version 
number. That would fundamentally break Maven version management (dependencies 
and POMs are cached locally and in proxied repos) as well as being extremely 
bad practice from a general software perspective. A POM is part of the artifact 
and coupled with the jar, its source etc. You'd essentially have two different 
artifacts of the same version number, which is supposed to be an artifact's 
unique identifier.

Anyway, in addition to dependencyManagement, Maven dependencies should always 
pull in a higher level version off the dependency tree in preference to a 
transitive dependency at a deeper depth so normally this should work by default 
unless you have a complex structure or are using a very outdated Maven version 
with bugs/weaknesses. The link in #15 notes this. Another alternative is to 
exclude the GSON dependency from google-services-api dependency with the 
<exclusions> section.

This bug may not be gmaps-api's fault, but the reality is that a library is 
responsible for all its dependencies. If they add a dependency on another 
library that has a bug affecting their users; they need to move that forward so 
you're right to raise it with them; even though there are several workarounds 
you can apply at your end.

Original comment by chad.lee...@gmail.com on 14 Jan 2015 at 12:57