[sonar-dev] LoggerFactory error against 5.1 API

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

[sonar-dev] LoggerFactory error against 5.1 API

GARDAIS Ionel
Hi list,

I’m getting LoggerFactory error when trying to build my plugin against the 5.1 API.
It works fine against 5.0.

The messages are 

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project sonar-gerrit-plugin: Compilation failure: Compilation failure:
[ERROR] /Users/ioio/Documents/Devs/sonar-gerrit-plugin/src/main/java/fr/techad/sonar/gerrit/ReviewFileComment.java:[4,16] error: package org.slf4j does not exist
[ERROR] 
[ERROR] /Users/ioio/Documents/Devs/sonar-gerrit-plugin/src/main/java/fr/techad/sonar/gerrit/ReviewFileComment.java:[5,16] error: package org.slf4j does not exist



Here are the dependencies of my pom.xml

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<sonar.buildVersion>5.1</sonar.buildVersion>
<jdk.min.version>1.7</jdk.min.version>
</properties>

<dependencies>
<dependency>
<groupId>org.codehaus.sonar</groupId>
<artifactId>sonar-plugin-api</artifactId>
<version>${sonar.buildVersion}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.8</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.codehaus.sonar</groupId>
<artifactId>sonar-testing-harness</artifactId>
<version>${sonar.buildVersion}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.10.8</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.5</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.4.3</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-project</artifactId>
<version>2.2.1</version>
</dependency>
<dependency>
<groupId>com.intellij</groupId>
<artifactId>annotations</artifactId>
<version>12.0</version>
</dependency>
</dependencies>

Am I missing something ?

Thanks
Ionel

--
Beicip-Franlab SA - 232 av. napoléon Bonaparte - BP 2132-92502 Rueil-Malmaison Cedex
Capital: EUR 6 000 000 - TVA FR 54 679 804 047- RCS Nanterre 679 804 047
This message and any attachments (the message) are confidential and intended solely for the addressees.
Any unauthorised use, dissemination or reproduction is strictly prohibited.
The sender does not accept liability for any errors or omissions in the contents of this message arising as a result of e-mail transmission.

Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] LoggerFactory error against 5.1 API

Julien HENRY
Hi Ionel,

Starting from SQ 5.1 we are trying to move away from slf4j and we have introduced our own logging facade. Please use org.sonar.api.utils.log.Logger.

++

Julien

2015-04-17 17:04 GMT+02:00 GARDAIS Ionel <[hidden email]>:
Hi list,

I’m getting LoggerFactory error when trying to build my plugin against the 5.1 API.
It works fine against 5.0.

The messages are 

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project sonar-gerrit-plugin: Compilation failure: Compilation failure:
[ERROR] /Users/ioio/Documents/Devs/sonar-gerrit-plugin/src/main/java/fr/techad/sonar/gerrit/ReviewFileComment.java:[4,16] error: package org.slf4j does not exist
[ERROR] 
[ERROR] /Users/ioio/Documents/Devs/sonar-gerrit-plugin/src/main/java/fr/techad/sonar/gerrit/ReviewFileComment.java:[5,16] error: package org.slf4j does not exist



Here are the dependencies of my pom.xml

<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<sonar.buildVersion>5.1</sonar.buildVersion>
<jdk.min.version>1.7</jdk.min.version>
</properties>

<dependencies>
<dependency>
<groupId>org.codehaus.sonar</groupId>
<artifactId>sonar-plugin-api</artifactId>
<version>${sonar.buildVersion}</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.8</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.codehaus.sonar</groupId>
<artifactId>sonar-testing-harness</artifactId>
<version>${sonar.buildVersion}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.10.8</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.3.5</version>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.4.3</version>
</dependency>
<dependency>
<groupId>org.apache.maven</groupId>
<artifactId>maven-project</artifactId>
<version>2.2.1</version>
</dependency>
<dependency>
<groupId>com.intellij</groupId>
<artifactId>annotations</artifactId>
<version>12.0</version>
</dependency>
</dependencies>

Am I missing something ?

Thanks
Ionel

--
Beicip-Franlab SA - 232 av. napoléon Bonaparte - BP 2132-92502 Rueil-Malmaison Cedex
Capital: EUR 6 000 000 - TVA FR 54 679 804 047- RCS Nanterre 679 804 047
This message and any attachments (the message) are confidential and intended solely for the addressees.
Any unauthorised use, dissemination or reproduction is strictly prohibited.
The sender does not accept liability for any errors or omissions in the contents of this message arising as a result of e-mail transmission.


fge
Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] LoggerFactory error against 5.1 API

fge
Hello,

On Tue, Apr 21, 2015 at 11:54 AM, Julien HENRY
<[hidden email]> wrote:
> Hi Ionel,
>
> Starting from SQ 5.1 we are trying to move away from slf4j and we have
> introduced our own logging facade. Please use
> org.sonar.api.utils.log.Logger.
>

May I ask the reason why? slf4j is a pretty well established API and
it just works, so why this move at all?

Regards,
--
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] LoggerFactory error against 5.1 API

Olivier Demeijer
Hi Francis,
Because of clashes with Maven (who is natively using slf4j-simple), I guess. I would actually be really happy if this move was already done (and it's not in 5.1)

On Tue, Apr 21, 2015 at 12:53 PM, Francis Galiegue <[hidden email]> wrote:
Hello,

On Tue, Apr 21, 2015 at 11:54 AM, Julien HENRY
<[hidden email]> wrote:
> Hi Ionel,
>
> Starting from SQ 5.1 we are trying to move away from slf4j and we have
> introduced our own logging facade. Please use
> org.sonar.api.utils.log.Logger.
>

May I ask the reason why? slf4j is a pretty well established API and
it just works, so why this move at all?

Regards,
--
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] LoggerFactory error against 5.1 API

fge
Hello,

On Tue, Apr 21, 2015 at 1:08 PM, Olivier Demeijer <[hidden email]> wrote:
> Hi Francis,
> Because of clashes with Maven (who is natively using slf4j-simple), I guess.
> I would actually be really happy if this move was already done (and it's not
> in 5.1)
>

You lost me here; what does maven have to do with this at all? What
conflicts can occur, if any? Do you have an example of a problematic
situation?

Regards,
--
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] LoggerFactory error against 5.1 API

mattadamson
Also out of interest why did we move away from slf4j?


> On 21 Apr 2015, at 12:27, Francis Galiegue <[hidden email]> wrote:
>
> Hello,
>
>> On Tue, Apr 21, 2015 at 1:08 PM, Olivier Demeijer <[hidden email]> wrote:
>> Hi Francis,
>> Because of clashes with Maven (who is natively using slf4j-simple), I guess.
>> I would actually be really happy if this move was already done (and it's not
>> in 5.1)
>
> You lost me here; what does maven have to do with this at all? What
> conflicts can occur, if any? Do you have an example of a problematic
> situation?
>
> Regards,
> --
> 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
>
>

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: [sonar-dev] LoggerFactory error against 5.1 API

Olivier Demeijer
In reply to this post by fge
This problem was reported (http://mail-archives.apache.org/mod_mbox/maven-issues/201406.mbox/%3CJIRA.148505.1378293156082.26291.1402903690887@...%3E, can't point to MNG-5510, codehaus is dying :( ), and is still there in the very latest SQ release.
The last time I had this problem was ... yesterday (SQ 5.1, sonar-maven-plugin 2.5).



On Tue, Apr 21, 2015 at 1:27 PM, Francis Galiegue <[hidden email]> wrote:
Hello,

On Tue, Apr 21, 2015 at 1:08 PM, Olivier Demeijer <[hidden email]> wrote:
> Hi Francis,
> Because of clashes with Maven (who is natively using slf4j-simple), I guess.
> I would actually be really happy if this move was already done (and it's not
> in 5.1)
>

You lost me here; what does maven have to do with this at all? What
conflicts can occur, if any? Do you have an example of a problematic
situation?

Regards,
--
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] LoggerFactory error against 5.1 API

fge
On Tue, Apr 21, 2015 at 1:49 PM, Olivier Demeijer <[hidden email]> wrote:
> This problem was reported
> (http://mail-archives.apache.org/mod_mbox/maven-issues/201406.mbox/%3CJIRA.148505.1378293156082.26291.1402903690887@...%3E,
> can't point to MNG-5510, codehaus is dying :( ), and is still there in the
> very latest SQ release.
> The last time I had this problem was ... yesterday (SQ 5.1,
> sonar-maven-plugin 2.5).
>

Well, you know, a gradle plugin exists now, and it works very well ;)

Honestly though, I fail to see why a project would switch logging
systems because of a bug in a build tool. If the build tool is the
source of the bug, change the build tool, not the project. This is
exactly why I switched to gradle.

--
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] LoggerFactory error against 5.1 API

Julien HENRY
In reply to this post by Olivier Demeijer
This is not only a problem with Maven but with embedding in general (in Eclipse, IntelliJ, ...). The fact slf4j statically link to implementation make it difficult to intercept logs and redirect them without doing some very complex classloading tricks. It is also difficult to configure logs in this situation (enabling debug logs for SonarQube in Eclipse should not require to enable debug logs of the whole Eclipse platform).

++


2015-04-21 13:49 GMT+02:00 Olivier Demeijer <[hidden email]>:
This problem was reported (http://mail-archives.apache.org/mod_mbox/maven-issues/201406.mbox/%3CJIRA.148505.1378293156082.26291.1402903690887@...%3E, can't point to MNG-5510, codehaus is dying :( ), and is still there in the very latest SQ release.
The last time I had this problem was ... yesterday (SQ 5.1, sonar-maven-plugin 2.5).



On Tue, Apr 21, 2015 at 1:27 PM, Francis Galiegue <[hidden email]> wrote:
Hello,

On Tue, Apr 21, 2015 at 1:08 PM, Olivier Demeijer <[hidden email]> wrote:
> Hi Francis,
> Because of clashes with Maven (who is natively using slf4j-simple), I guess.
> I would actually be really happy if this move was already done (and it's not
> in 5.1)
>

You lost me here; what does maven have to do with this at all? What
conflicts can occur, if any? Do you have an example of a problematic
situation?

Regards,
--
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] LoggerFactory error against 5.1 API

fge
Hello,

On Tue, Apr 21, 2015 at 2:39 PM, Julien HENRY
<[hidden email]> wrote:
> This is not only a problem with Maven but with embedding in general (in
> Eclipse, IntelliJ, ...). The fact slf4j statically link to implementation
> make it difficult to intercept logs and redirect them without doing some
> very complex classloading tricks. It is also difficult to configure logs in
> this situation (enabling debug logs for SonarQube in Eclipse should not
> require to enable debug logs of the whole Eclipse platform).
>
> ++
>

Erm, why should IDEs be your concern at all? I really don't get it.

IDEs are not the primary candidates for logging when designing an
application which is destined to run standalone; for these, well, you
have your log configuration to load which you can configure (would
that be only by reading a property file).

And the default is to log to stderr anyway, so I really don't see
where the problem is. IDE integration should be the lowest of lowest
of priorities.

Regards,
--
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] LoggerFactory error against 5.1 API

Simon Brandhof
"IDE integration should be the lowest of lowest of priorities". Francis, that's exactly why you don't understand our technical choices. IDE integration is one of our priorities.


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

On 21 April 2015 at 15:27, Francis Galiegue <[hidden email]> wrote:
Hello,

On Tue, Apr 21, 2015 at 2:39 PM, Julien HENRY
<[hidden email]> wrote:
> This is not only a problem with Maven but with embedding in general (in
> Eclipse, IntelliJ, ...). The fact slf4j statically link to implementation
> make it difficult to intercept logs and redirect them without doing some
> very complex classloading tricks. It is also difficult to configure logs in
> this situation (enabling debug logs for SonarQube in Eclipse should not
> require to enable debug logs of the whole Eclipse platform).
>
> ++
>

Erm, why should IDEs be your concern at all? I really don't get it.

IDEs are not the primary candidates for logging when designing an
application which is destined to run standalone; for these, well, you
have your log configuration to load which you can configure (would
that be only by reading a property file).

And the default is to log to stderr anyway, so I really don't see
where the problem is. IDE integration should be the lowest of lowest
of priorities.

Regards,
--
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] LoggerFactory error against 5.1 API

fge
Hello,

On Tue, Apr 21, 2015 at 3:36 PM, Simon Brandhof
<[hidden email]> wrote:
> "IDE integration should be the lowest of lowest of priorities". Francis,
> that's exactly why you don't understand our technical choices. IDE
> integration is one of our priorities.
>

OK, let's dissect that a little.

What does IDE integration mean for Sonar? What viewpoint is adopted?
The developer's, or the user's?

If the developer's: SonarQube is just a webapp like any other;
therefore it should adapt to the logging system used by either the
SonarQube standalone executable, or the app server running a SonarQube
installation. Both cases are covered by slf4j.

If the user's: the user will run SonarQube as a standalone service, or
will run a dedicated plugin (which will probably end up doing the
former). Logs? slf4j defaults to logging to std{out,err} anyway, but
if you wish to do so you can alter that via configuration -- in the
plugin, programmatically.

Let us dig a little further and consider the integration phase: in
this case you need to run the integration cases and harness the logs;
good, slf4j offers the ability to alter the configuration in this case
as well.

I must be missing something here, but I still see no valid reason for
SonarQube to move away from slf4j.

Save for the fact that Maven, for some reason, seems to leak its own
slf4j usage to the build process which it should not anyway, after all
it's a build tool, and nothing else. And this seems to me, from what I
have read, the only reason why SonarQube shifts away from slf4j.

And while this is my opinion only, but this is not a good decision;
there are build tools out there which do not exhibit this problem and
do not force you to do things The XXX Way(tm), where XXX is the build
tool in question... And the most well known of them is gradle.

Seriously, I mean it. Switch to gradle. Especially since there is now
a fully functional solution for generating plugins, which I use daily,
even though its version is 0.1.0... But with which I am able to do
what I want with not even a third of the lines of what Maven requires.

I don't know how advanced you are in your custom logging facade, but
if not that much and willing to try another way, just go Gradle.
That's what I recommend anyway.

Regards,
--
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] LoggerFactory error against 5.1 API

Olivier Demeijer
I'm dev, deeply implied in the  CI process, using SQ since version ~1.8, and i can honestly tell you that your vision of what SQ is at the opposite of mine.
For a dev standpoint, Sonar is absolutly not "just another webapp" ; integrated to your IDE, it's one of the most valuable tool you have : it gives you ~instant feedback on what you are doing AND a detailed view on where are the potential problem on the code you just checked out. Starting from there, you can learn A LOT, just by reading the how's and why's a violation is considered as such, and how it might be fixed. Far from just another webapp ... 
For a CI standpoint, - and yes, Maven is one of the mostly used tool for integration ... because it works !, SQ is simply, at least for me, THE validator : if what was compiled/tested/packages doesn't meet the expected level of quality, it's up to SQ to break the build and forbid deployment of produced artifact.
So, from my point-of-view, if slf4j is an impediment to achieve that, ... just get rid of it, thank you SQ guys :) (even if i had to wait for that more than a year ;)

Now talking about Gradle ... It looks like a silver bullet, but it's not. I know people going back from it to Maven because, guess what, if it solves problems, it introduces new ones. As usual ;)

Regards,
Olivier




On Tue, Apr 21, 2015 at 4:41 PM, Francis Galiegue <[hidden email]> wrote:
Hello,

On Tue, Apr 21, 2015 at 3:36 PM, Simon Brandhof
<[hidden email]> wrote:
> "IDE integration should be the lowest of lowest of priorities". Francis,
> that's exactly why you don't understand our technical choices. IDE
> integration is one of our priorities.
>

OK, let's dissect that a little.

What does IDE integration mean for Sonar? What viewpoint is adopted?
The developer's, or the user's?

If the developer's: SonarQube is just a webapp like any other;
therefore it should adapt to the logging system used by either the
SonarQube standalone executable, or the app server running a SonarQube
installation. Both cases are covered by slf4j.

If the user's: the user will run SonarQube as a standalone service, or
will run a dedicated plugin (which will probably end up doing the
former). Logs? slf4j defaults to logging to std{out,err} anyway, but
if you wish to do so you can alter that via configuration -- in the
plugin, programmatically.

Let us dig a little further and consider the integration phase: in
this case you need to run the integration cases and harness the logs;
good, slf4j offers the ability to alter the configuration in this case
as well.

I must be missing something here, but I still see no valid reason for
SonarQube to move away from slf4j.

Save for the fact that Maven, for some reason, seems to leak its own
slf4j usage to the build process which it should not anyway, after all
it's a build tool, and nothing else. And this seems to me, from what I
have read, the only reason why SonarQube shifts away from slf4j.

And while this is my opinion only, but this is not a good decision;
there are build tools out there which do not exhibit this problem and
do not force you to do things The XXX Way(tm), where XXX is the build
tool in question... And the most well known of them is gradle.

Seriously, I mean it. Switch to gradle. Especially since there is now
a fully functional solution for generating plugins, which I use daily,
even though its version is 0.1.0... But with which I am able to do
what I want with not even a third of the lines of what Maven requires.

I don't know how advanced you are in your custom logging facade, but
if not that much and willing to try another way, just go Gradle.
That's what I recommend anyway.

Regards,
--
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] LoggerFactory error against 5.1 API

fge
On Tue, Apr 21, 2015 at 5:10 PM, Olivier Demeijer <[hidden email]> wrote:

> I'm dev, deeply implied in the  CI process, using SQ since version ~1.8, and
> i can honestly tell you that your vision of what SQ is at the opposite of
> mine.
> For a dev standpoint, Sonar is absolutly not "just another webapp" ;
> integrated to your IDE, it's one of the most valuable tool you have : it
> gives you ~instant feedback on what you are doing AND a detailed view on
> where are the potential problem on the code you just checked out. Starting
> from there, you can learn A LOT, just by reading the how's and why's a
> violation is considered as such, and how it might be fixed. Far from just
> another webapp ...

OK, then please teach me.

I believe we approached SonarQube from opposite viewpoints; I am a
"server side" guy who has to program a language plugin; which I did.
I've had my fair share of troubles

And I use this plugin with the Sonar runner; how does an IDE plugin
operate if not using that for quality analysis? Does it use the Sonar
runner? If not, what does it use? How does the plugin allow you to
check for errors? By integrating them into the IDE? By providing a
link to a locally running SonarQube instance?

> For a CI standpoint, - and yes, Maven is one of the mostly used tool for
> integration ... because it works !

Define "works". Have you ever used the release plugin? If yes, you
feel my pain. Have you ever used the shade plugin. If yes, you feel my
pain.

>, SQ is simply, at least for me, THE
> validator : if what was compiled/tested/packages doesn't meet the expected
> level of quality, it's up to SQ to break the build and forbid deployment of
> produced artifact.

Fine. With gradle you can do this too.

[...]
> Now talking about Gradle ... It looks like a silver bullet, but it's not. I
> know people going back from it to Maven because, guess what, if it solves
> problems, it introduces new ones. As usual ;)
>

I'd be glad to see examples, but that's off topic for that list; all
people I know who have switched to gradle never looked back...

Regards,
--
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