[sonar-dev] Problem with conflicting Guava versions

classic Classic list List threaded Threaded
17 messages Options
fge
Reply | Threaded
Open this post in threaded view
|

[sonar-dev] Problem with conflicting Guava versions

fge
I use grappa (https://github.com/fge/grappa) as my sole channel to
parse a language since existing channels just can't do what grappa is
able to do, but I have a problem...

This package requires version 18.0 of Guava; Sonar uses 10.0.1. If, in
my build.gradle file, I exclude the Guava dependency then I get the
complaint that Closeables.closeQuietly() is undefined (it was removed
in 14.0); and if I exclude the dependency from grappa, I then have the
complaint that CacheBuilder's .recordStatistics() does not exist.

Right now, what I do is copy over the CodeBuffer class and modify it
so that it use a try-with-resources statement (since the plugin I
develop requires Java 7) instead. It's a hack but it works, sort of.

Is there another solution? A Channel needs to .consume() from a
CodeReader which uses a CodeBuffer, but ideally I'd like to replace
CodeBuffer with something else, for instance.

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

Julien HENRY
Hi Francis,

I think you could use Maven shade plugin to shade your own version of Guava in your plugin.

++

Julien

2015-03-12 14:01 GMT+01:00 Francis Galiegue <[hidden email]>:
I use grappa (https://github.com/fge/grappa) as my sole channel to
parse a language since existing channels just can't do what grappa is
able to do, but I have a problem...

This package requires version 18.0 of Guava; Sonar uses 10.0.1. If, in
my build.gradle file, I exclude the Guava dependency then I get the
complaint that Closeables.closeQuietly() is undefined (it was removed
in 14.0); and if I exclude the dependency from grappa, I then have the
complaint that CacheBuilder's .recordStatistics() does not exist.

Right now, what I do is copy over the CodeBuffer class and modify it
so that it use a try-with-resources statement (since the plugin I
develop requires Java 7) instead. It's a hack but it works, sort of.

Is there another solution? A Channel needs to .consume() from a
CodeReader which uses a CodeBuffer, but ideally I'd like to replace
CodeBuffer with something else, for instance.

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Thu, Mar 12, 2015 at 3:51 PM, Julien HENRY
<[hidden email]> wrote:
> Hi Francis,
>
> I think you could use Maven shade plugin to shade your own version of Guava
> in your plugin.
>
> ++
>
> Julien
>

Well, for starters I use gradle, not maven (which I hate with a
passion), and while I can probably do that, it seems like a
sledgehammer to whack a fly; isn't there a code only solution?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Thu, Mar 12, 2015 at 4:16 PM, Francis Galiegue <[hidden email]> wrote:
[...]
>
> Well, for starters I use gradle, not maven (which I hate with a
> passion), and while I can probably do that, it seems like a
> sledgehammer to whack a fly; isn't there a code only solution?
>

Actually the solution is pretty simple: don't use
Closeables.closeQuietly()! It has been removed for a reason...

Also, why stick to such an antique version of Guava?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

Julien HENRY

2015-03-12 17:58 GMT+01:00 Francis Galiegue <[hidden email]>:
Also, why stick to such an antique version of Guava?

For backward compatibility reasons...
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

Simon Brandhof
In reply to this post by fge
For exactly the same reasons that you raised here. Core and plugins use classes and methods that were dropped in recent versions of Guava.


Simon BRANDHOF | SonarSource
Tech Lead & Co-Founder
http://twitter.com/SimonBrandhof

On 12 March 2015 at 17:58, Francis Galiegue <[hidden email]> wrote:
On Thu, Mar 12, 2015 at 4:16 PM, Francis Galiegue <[hidden email]> wrote:
[...]
>
> Well, for starters I use gradle, not maven (which I hate with a
> passion), and while I can probably do that, it seems like a
> sledgehammer to whack a fly; isn't there a code only solution?
>

Actually the solution is pretty simple: don't use
Closeables.closeQuietly()! It has been removed for a reason...

Also, why stick to such an antique version of Guava?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Thu, Mar 12, 2015 at 6:08 PM, Simon Brandhof
<[hidden email]> wrote:
> For exactly the same reasons that you raised here. Core and plugins use
> classes and methods that were dropped in recent versions of Guava.
>

OK...

Then would it be at least possible to allow the user to implement
CodeReader the way he wants by making it an interface, for instance?
Or an abstract class?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
In reply to this post by Simon Brandhof
On Thu, Mar 12, 2015 at 6:08 PM, Simon Brandhof
<[hidden email]> wrote:
> For exactly the same reasons that you raised here. Core and plugins use
> classes and methods that were dropped in recent versions of Guava.
>

Hold on a minute.

Why, then, do I see this:

<jdk.min.version>1.7</jdk.min.version>

in this:

https://github.com/SonarSource/parent-oss/blob/19/pom.xml

which means that Closeables.closeQuietly() has no reason to be used
anymore whatsoever, since with Java 7 you have try-with-resources?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

Simon Brandhof
Support of Java 6 was recently dropped. 

I exclude the Guava dependency then I get the complaint that Closeables.closeQuietly() is undefined

What's the exact stacktrace please ?
Thanks  


Simon BRANDHOF | SonarSource
Tech Lead & Co-Founder
http://twitter.com/SimonBrandhof

On 12 March 2015 at 23:47, Francis Galiegue <[hidden email]> wrote:
On Thu, Mar 12, 2015 at 6:08 PM, Simon Brandhof
<[hidden email]> wrote:
> For exactly the same reasons that you raised here. Core and plugins use
> classes and methods that were dropped in recent versions of Guava.
>

Hold on a minute.

Why, then, do I see this:

<jdk.min.version>1.7</jdk.min.version>

in this:

https://github.com/SonarSource/parent-oss/blob/19/pom.xml

which means that Closeables.closeQuietly() has no reason to be used
anymore whatsoever, since with Java 7 you have try-with-resources?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Fri, Mar 13, 2015 at 6:56 AM, Simon Brandhof
<[hidden email]> wrote:
[...]
>
> What's the exact stacktrace please ?
> Thanks
>

Well, not really a need for a stack trace; it's in this constructor:

protected CodeBuffer(Reader initialCodeReader, CodeReaderConfiguration
configuration)

I can send a patch replacing it with try-with-resources, that's easy enough...

Alternatively, since Guava 17.0 this method also has been
_reintroduced_. But then this is Java 7, so...

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

Simon Brandhof
Do you use CodeBuffer because of CodeColorizer extension point ? If yes moving to org.sonar.api.source.Highlightable would fix the problem as coupling on sonar-channel is removed.


Simon BRANDHOF | SonarSource
Tech Lead & Co-Founder
http://twitter.com/SimonBrandhof

On 13 March 2015 at 08:48, Francis Galiegue <[hidden email]> wrote:
On Fri, Mar 13, 2015 at 6:56 AM, Simon Brandhof
<[hidden email]> wrote:
[...]
>
> What's the exact stacktrace please ?
> Thanks
>

Well, not really a need for a stack trace; it's in this constructor:

protected CodeBuffer(Reader initialCodeReader, CodeReaderConfiguration
configuration)

I can send a patch replacing it with try-with-resources, that's easy enough...

Alternatively, since Guava 17.0 this method also has been
_reintroduced_. But then this is Java 7, so...

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Mon, Mar 16, 2015 at 11:02 AM, Simon Brandhof
<[hidden email]> wrote:
> Do you use CodeBuffer because of CodeColorizer extension point ? If yes
> moving to org.sonar.api.source.Highlightable would fix the problem as
> coupling on sonar-channel is removed.
>

Uhm, no... I use plain, standard SSLR stuff as far as I'm aware at least:

dependencies {
    compile(group: "org.codehaus.sonar.sslr", name: "sslr", version: "1.20");
    compile(group: "org.codehaus.sonar.sslr", name: "sslr-examples",
        version: "1.20");
    compile(group: "org.codehaus.sonar.sslr-squid-bridge",
        name: "sslr-squid-bridge", version: "2.5.3");
    compile(group: "com.github.fge", name: "grappa-tracer-backport",
        version: "2.0.0");
    testCompile(group: "org.testng", name: "testng", version: "6.8.21") {
        exclude(group: "org.apache.ant", module: "ant");
        exclude(group: "com.google.inject", module: "guice");
        exclude(group: "junit", module: "junit");
        exclude(group: "org.beanshell", module: "bsh");
        exclude(group: "org.yaml", module: "snakeyaml");
    };
    testCompile(group: "org.mockito", name: "mockito-core", version: "1.10.19");
    testCompile(group: "org.assertj", name: "assertj-core", version: "1.7.1");
    testCompile(group: "org.codehaus.sonar.sslr", name: "sslr-testing-harness",
        version: "1.20") {
        exclude(group: "junit", module: "junit");
        exclude(group: "org.easytesting", module: "fest-assert");
    };
}

The test which fails is a check test which is as such:

@Test
public abstract class ObjectScriptCheckTestBase
{
    private final GrammarRuleKey key = mock(GrammarRuleKey.class);
    private final TokenType tokenType;

    private Parser<Grammar> parser;
    private SquidCheck<Grammar> check;
    private SquidAstVisitorContext<Grammar> context;
    private AstWalker walker;

    protected ObjectScriptCheckTestBase(final TokenType tokenType)
    {
        this.tokenType = tokenType;
    }

    @BeforeMethod
    public final void init()
    {
        final Rule rule = createRule();
        final Channel<Lexer> channel = new TestChannel(rule, tokenType);
        final Lexer lexer = Lexer.builder().withChannel(channel).build();
        final LexerfulGrammarBuilder builder = LexerfulGrammarBuilder.create();
        builder.rule(key).is(tokenType);
        builder.setRootRule(key);
        final Grammar grammar = builder.build();
        parser = Parser.builder(grammar).withLexer(lexer)
            .build();

        check = spy(createCheck());

        context = mock(SquidAstVisitorContext.class);
        doReturn(context).when(check).getContext();

        check.subscribeTo(tokenType);
        walker = new AstWalker(check);
    }

    protected abstract Rule createRule();

    protected abstract SquidCheck<Grammar> createCheck();

    /*
     * Elements of the object arrays must be two strings:
     *
     * - the first is the input;
     * - the second is the expected error message.
     */
    @DataProvider
    protected abstract Iterator<Object[]> testInputs();

    @Test(dataProvider = "testInputs")
    public void checkTest(final String input, final String expectedMessage)
    {
        final AstNode node = parser.parse(input);

        final ArgumentCaptor<String> captor
            = ArgumentCaptor.forClass(String.class);

        walker.walkAndVisit(node);

        verify(context).createLineViolation(same(check), captor.capture(),
            any(AstNode.class));

        assertThat(captor.getValue()).isEqualTo(expectedMessage);
    }
}

And the stack trace is as such:

java.lang.NoSuchMethodError:
com.google.common.io.Closeables.closeQuietly(Ljava/io/Closeable;)V
at org.sonar.sslr.channel.CodeBuffer.<init>(CodeBuffer.java:79)
at org.sonar.sslr.channel.CodeReader.<init>(CodeReader.java:58)
at com.sonar.sslr.impl.Lexer.lex(Lexer.java:126)
at com.sonar.sslr.impl.Lexer.lex(Lexer.java:116)
at com.sonar.sslr.impl.Parser.parse(Parser.java:77)
at com.github.fge.objectscript.checks.ObjectScriptCheckTestBase.checkTest(ObjectScriptCheckTestBase.java:84)

More details on demand. But this doesn't happen if I just, uh, copy
the code of CodeBuffer in the main sources, which makes it use the
method defined in guava 18.0 (although it should really use
try-with-resources instead but that's another problem)

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

Dinesh Bolkensteyn-2
Hi Francis,

We're not going to make a new release of SSLR just for that - especially since SSLR itself is currently locked on the version of Guava used by SonarQube.

I suggest that you find a way to proceed with your plugin that doesn't depend on any change on SSLR.

We probably indeed need to think on how we can upgrade the embedded Guava version, but that is not so straightforward because of compatibility issues.

++


On Mon, Mar 16, 2015 at 2:42 PM, Francis Galiegue <[hidden email]> wrote:
On Mon, Mar 16, 2015 at 11:02 AM, Simon Brandhof
<[hidden email]> wrote:
> Do you use CodeBuffer because of CodeColorizer extension point ? If yes
> moving to org.sonar.api.source.Highlightable would fix the problem as
> coupling on sonar-channel is removed.
>

Uhm, no... I use plain, standard SSLR stuff as far as I'm aware at least:

dependencies {
    compile(group: "org.codehaus.sonar.sslr", name: "sslr", version: "1.20");
    compile(group: "org.codehaus.sonar.sslr", name: "sslr-examples",
        version: "1.20");
    compile(group: "org.codehaus.sonar.sslr-squid-bridge",
        name: "sslr-squid-bridge", version: "2.5.3");
    compile(group: "com.github.fge", name: "grappa-tracer-backport",
        version: "2.0.0");
    testCompile(group: "org.testng", name: "testng", version: "6.8.21") {
        exclude(group: "org.apache.ant", module: "ant");
        exclude(group: "com.google.inject", module: "guice");
        exclude(group: "junit", module: "junit");
        exclude(group: "org.beanshell", module: "bsh");
        exclude(group: "org.yaml", module: "snakeyaml");
    };
    testCompile(group: "org.mockito", name: "mockito-core", version: "1.10.19");
    testCompile(group: "org.assertj", name: "assertj-core", version: "1.7.1");
    testCompile(group: "org.codehaus.sonar.sslr", name: "sslr-testing-harness",
        version: "1.20") {
        exclude(group: "junit", module: "junit");
        exclude(group: "org.easytesting", module: "fest-assert");
    };
}

The test which fails is a check test which is as such:

@Test
public abstract class ObjectScriptCheckTestBase
{
    private final GrammarRuleKey key = mock(GrammarRuleKey.class);
    private final TokenType tokenType;

    private Parser<Grammar> parser;
    private SquidCheck<Grammar> check;
    private SquidAstVisitorContext<Grammar> context;
    private AstWalker walker;

    protected ObjectScriptCheckTestBase(final TokenType tokenType)
    {
        this.tokenType = tokenType;
    }

    @BeforeMethod
    public final void init()
    {
        final Rule rule = createRule();
        final Channel<Lexer> channel = new TestChannel(rule, tokenType);
        final Lexer lexer = Lexer.builder().withChannel(channel).build();
        final LexerfulGrammarBuilder builder = LexerfulGrammarBuilder.create();
        builder.rule(key).is(tokenType);
        builder.setRootRule(key);
        final Grammar grammar = builder.build();
        parser = Parser.builder(grammar).withLexer(lexer)
            .build();

        check = spy(createCheck());

        context = mock(SquidAstVisitorContext.class);
        doReturn(context).when(check).getContext();

        check.subscribeTo(tokenType);
        walker = new AstWalker(check);
    }

    protected abstract Rule createRule();

    protected abstract SquidCheck<Grammar> createCheck();

    /*
     * Elements of the object arrays must be two strings:
     *
     * - the first is the input;
     * - the second is the expected error message.
     */
    @DataProvider
    protected abstract Iterator<Object[]> testInputs();

    @Test(dataProvider = "testInputs")
    public void checkTest(final String input, final String expectedMessage)
    {
        final AstNode node = parser.parse(input);

        final ArgumentCaptor<String> captor
            = ArgumentCaptor.forClass(String.class);

        walker.walkAndVisit(node);

        verify(context).createLineViolation(same(check), captor.capture(),
            any(AstNode.class));

        assertThat(captor.getValue()).isEqualTo(expectedMessage);
    }
}

And the stack trace is as such:

java.lang.NoSuchMethodError:
com.google.common.io.Closeables.closeQuietly(Ljava/io/Closeable;)V
at org.sonar.sslr.channel.CodeBuffer.<init>(CodeBuffer.java:79)
at org.sonar.sslr.channel.CodeReader.<init>(CodeReader.java:58)
at com.sonar.sslr.impl.Lexer.lex(Lexer.java:126)
at com.sonar.sslr.impl.Lexer.lex(Lexer.java:116)
at com.sonar.sslr.impl.Parser.parse(Parser.java:77)
at com.github.fge.objectscript.checks.ObjectScriptCheckTestBase.checkTest(ObjectScriptCheckTestBase.java:84)

More details on demand. But this doesn't happen if I just, uh, copy
the code of CodeBuffer in the main sources, which makes it use the
method defined in guava 18.0 (although it should really use
try-with-resources instead but that's another problem)

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Mon, Mar 16, 2015 at 3:31 PM, Dinesh Bolkensteyn
<[hidden email]> wrote:

> Hi Francis,
>
> We're not going to make a new release of SSLR just for that - especially
> since SSLR itself is currently locked on the version of Guava used by
> SonarQube.
>
> I suggest that you find a way to proceed with your plugin that doesn't
> depend on any change on SSLR.
>
> We probably indeed need to think on how we can upgrade the embedded Guava
> version, but that is not so straightforward because of compatibility issues.
>

Sure but then while this is the ideal way, this leads to development
sclerosis; breaking changes do have to happen at some point.

OK, let's say I want to contribute; what packages would I need to
"attack" first? And MOST IMPORTANTLY, can I contribute documentation?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Mon, Mar 16, 2015 at 4:27 PM, Francis Galiegue <[hidden email]> wrote:
[...]
>
> OK, let's say I want to contribute; what packages would I need to
> "attack" first? And MOST IMPORTANTLY, can I contribute documentation?
>

Sorry to insist, but this is becoming a serious issue.

Lexer, as in com.sonar.sslr.impl.Lexer, suffers the same problem:
Closeables.closeQuietly() not defined. And again, the temporary
solution was to just include this file in my plugin so that it worked.

So, is there any plan, FAST, that Sonar use try-with-resources instead
of relying on an antiquated Guava version and upgrade the Guava
dependency as a consequence?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

Simon Brandhof
Francis, the problem with Guava coupling needs to be carefully considered and can't be addressed in the rush.



Simon BRANDHOF | SonarSource
Tech Lead & Co-Founder
http://twitter.com/SimonBrandhof

On 19 March 2015 at 19:11, Francis Galiegue <[hidden email]> wrote:
On Mon, Mar 16, 2015 at 4:27 PM, Francis Galiegue <[hidden email]> wrote:
[...]
>
> OK, let's say I want to contribute; what packages would I need to
> "attack" first? And MOST IMPORTANTLY, can I contribute documentation?
>

Sorry to insist, but this is becoming a serious issue.

Lexer, as in com.sonar.sslr.impl.Lexer, suffers the same problem:
Closeables.closeQuietly() not defined. And again, the temporary
solution was to just include this file in my plugin so that it worked.

So, is there any plan, FAST, that Sonar use try-with-resources instead
of relying on an antiquated Guava version and upgrade the Guava
dependency as a consequence?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] Problem with conflicting Guava versions

fge
On Fri, Mar 20, 2015 at 12:03 AM, Simon Brandhof
<[hidden email]> wrote:
> Francis, the problem with Guava coupling needs to be carefully considered
> and can't be addressed in the rush.
>

Yes, I understand that.

However:

* this has to be addressed some day, so why not now? Especially since...
* as I mentioned already, Sonar now requires Java 7, so getting rid of
all references in Sonar source code to Closeables.closeQuietly()
(which was buggy to start with) is easy; and finally
* a lot of goodness has surfaced since 10.x which Sonar just can't use
because of that.

So, what reason is there left to prevent Sonar from Just Doing It(tm)?

--
Francis Galiegue, [hidden email], https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/fge/grappa

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email