Re: Roadmap

[Alexander Heusingfeld]

-- sent from a mobile device

Am 31.07.2013 um 14:16 schrieb Oleg Mayevskiy <omaye...@gmail.com>:

On 31.07.2013 12:54, Alexander Heusingfeld wrote:

discussion + code review sounds nice, let's go this way. I don't really care about technical details how  actually there are tons of way to do it. But both should happen please just do it ;-)

Perfect! IMO it's a matter of respect for each other that should make us discuss changes first!

@George & Alpar do you agree?

One thing we really do need to agree upon though is the license we want to use for the future source code. 

I don't really care, just copied this from another plugin and replaced the name.  If lgpl is better for us, just take it, if apache is better, well you know.

The questions are

- What do we want to allow?

- What do we want to prohibit?

IMO we should allow binary distribution a.k.a. bundling but I'd like to make sure that all modifications are made available as OpenSource. Would you setup other or further implications?

Based on this I will try to elaborate the differences between Apache Public License, Eclipse Public License and LGPL and discuss this in a separate mail thread.

Sorry for not being too clear on this: 

My personal target is to be able to use the plugin for Java, Groovy, Ruby and Clojure sources. As we also have a feature request for PHP and JavaScript, I would never want to exclude anything that Sonar can analyze!!

So how is the "local analysis" feature meant to work? Like that:

Currently Sonar's local analysis is run by starting Sonar in a separate JVM. This takes up a lot of time and memory! When I say "in-process local analysis" it means that Sonar analysis is run in the same JVM that IntelliJ/ WebStorm/ RubyMine are run in. This can be done because the SonarSource guys extracted the specific code which analysis violations inside Sonar into the so called "sonar-runner". This retrieves the configuration for the selected module from the remote Sonar server and executes the checks locally.

The sonar-runner shouldn't be limited to Java as it's the same code which is used inside Sonar server. It just needs a JVM to run in.

Alpar made a contribution to this SonarSource project because prior to version 2.3 a local analysis couldn't be aborted.

A working travis CI build is IMHO very useful as a first validation of code contributions which are then build automatically.

Actually I don't really use maven to build the plugin ;-) Well I have a pom.xml but it is used by another intellij plugin for just sync the deps to intellij. Afterwards it's built by IntelliJ in the standart way. This is my preferred way, why more complex? KISS ;-) Do we really need CI? We could also apply to convention, that if anyone share code, he runs all tests locally.

It's a large effort to setup environments for different IntelliJ versions just to be able to verify that one's contribution doesn't fail any test in any environment. 

This is even a greater barrier for one-time contributors which sometimes bring in very valuable contributions.

But that is exactly where a good CI process kicks in! The optimum in my point of view would be that each contribution a.k.a. pull-request (in the future) is build and validated against the current version of IntelliJ-community jars, the previous version and the latest EAP build.

Currently this means we'd have three builds for IntelliJ11, 12 and 13 - always the latest release. At the moment I still believe this is realizable via Gradle and Git but I'll have to dig into this a little deeper.

Well I don't had really time for tests till now. Some one should take care about integration tests in intellij, I also would do it, if other features are done and I have time.

I experienced that people have a different understanding of the term "integration tests". As we're talking about a plugin connecting to a remote server, I'd say an integration test would deal with exactly this: Check whether the above mentioned three plugins connect to different Sonar servers/ server versions. Unfortunately we'd need to have some hosted Sonar servers then.

Could you give me your understanding?

Oh did not really noticed, just confused of all those lists, sorry for that. Hm I use mygmail.com account and get mails well fromnabble.com. Looks working for me.

At the moment George and Alpar aren't signed up to the mailing list, yet, so we'll have to keep the firstpoint address in CC. 

Another point is that your replies ain't send to the list because you didn't create your personal mailto-address (you can check it here: http://sonar-intellij-plugin.55862.x6.nabble.com/, only my mails are send there)

Short: nabble's usability sucks big time IMO!

I created a forum at google groups as an alternative (see Cc):https://groups.google.com/forum/#!msg/sonarcube-intellij-plugin/

Let's see how this works. All of you should receive this mail twice now! Once via Firstpoint and once via Google.

Cheers

Alex

[George Shakhnazaryan]

As a heads up, I don't really have much time/energy to dedicate to this project at this point in time. I'm excited that you guys are working together and I look forward to the results. I have a few opinions on stuff, but feel free to ignore since I won't be able to contribute much. Comments are in line.

Thanks,
George

On Wed, Jul 31, 2013 at 6:24 PM, Alexander Heusingfeld <al...@goldstift.de> wrote:

-- sent from a mobile device

Am 31.07.2013 um 14:16 schrieb Oleg Mayevskiy <omaye...@gmail.com>:

On 31.07.2013 12:54, Alexander Heusingfeld wrote:

discussion + code review sounds nice, let's go this way. I don't really care about technical details how  actually there are tons of way to do it. But both should happen please just do it ;-)

Perfect! IMO it's a matter of respect for each other that should make us discuss changes first!

@George & Alpar do you agree?

Code reviews via pull requests sound good.

One thing we really do need to agree upon though is the license we want to use for the future source code. 

I don't really care, just copied this from another plugin and replaced the name.  If lgpl is better for us, just take it, if apache is better, well you know.

The questions are

- What do we want to allow?

- What do we want to prohibit?

IMO we should allow binary distribution a.k.a. bundling but I'd like to make sure that all modifications are made available as OpenSource. Would you setup other or further implications?

Based on this I will try to elaborate the differences between Apache Public License, Eclipse Public License and LGPL and discuss this in a separate mail thread.

Only reason I picked LGPL originally was that was Sonar's license. Looking at IntelliJ, the community edition is licensed with Apache v2. I'd prefer the latter to work with IntelliJ, but no real strong feelings.

Sorry for not being too clear on this: 

My personal target is to be able to use the plugin for Java, Groovy, Ruby and Clojure sources. As we also have a feature request for PHP and JavaScript, I would never want to exclude anything that Sonar can analyze!!

So how is the "local analysis" feature meant to work? Like that:

Currently Sonar's local analysis is run by starting Sonar in a separate JVM. This takes up a lot of time and memory! When I say "in-process local analysis" it means that Sonar analysis is run in the same JVM that IntelliJ/ WebStorm/ RubyMine are run in. This can be done because the SonarSource guys extracted the specific code which analysis violations inside Sonar into the so called "sonar-runner". This retrieves the configuration for the selected module from the remote Sonar server and executes the checks locally.

The sonar-runner shouldn't be limited to Java as it's the same code which is used inside Sonar server. It just needs a JVM to run in.

Alpar made a contribution to this SonarSource project because prior to version 2.3 a local analysis couldn't be aborted.

A working travis CI build is IMHO very useful as a first validation of code contributions which are then build automatically.

Actually I don't really use maven to build the plugin ;-) Well I have a pom.xml but it is used by another intellij plugin for just sync the deps to intellij. Afterwards it's built by IntelliJ in the standart way. This is my preferred way, why more complex? KISS ;-) Do we really need CI? We could also apply to convention, that if anyone share code, he runs all tests locally.

It's a large effort to setup environments for different IntelliJ versions just to be able to verify that one's contribution doesn't fail any test in any environment. 

This is even a greater barrier for one-time contributors which sometimes bring in very valuable contributions.

But that is exactly where a good CI process kicks in! The optimum in my point of view would be that each contribution a.k.a. pull-request (in the future) is build and validated against the current version of IntelliJ-community jars, the previous version and the latest EAP build.

Currently this means we'd have three builds for IntelliJ11, 12 and 13 - always the latest release. At the moment I still believe this is realizable via Gradle and Git but I'll have to dig into this a little deeper.

Having a CI server is definitely a good idea. I tried to make the build reproducible with the maven project, but it required a lot of custom scripts to install the IntelliJ jars. If it's easier with Gradle, go for it. I'm just not sure how that would solve the dependency problem.

Well I don't had really time for tests till now. Some one should take care about integration tests in intellij, I also would do it, if other features are done and I have time.

I experienced that people have a different understanding of the term "integration tests". As we're talking about a plugin connecting to a remote server, I'd say an integration test would deal with exactly this: Check whether the above mentioned three plugins connect to different Sonar servers/ server versions. Unfortunately we'd need to have some hosted Sonar servers then.

Could you give me your understanding?

That sounds good. For testing the plugin manually, I was hitting the official sonar server at nemo (now http://nemo.sonarqube.org/). This may or may not be a good idea since that analysis is always changing.

Oh did not really noticed, just confused of all those lists, sorry for that. Hm I use mygmail.com account and get mails well fromnabble.com. Looks working for me.

At the moment George and Alpar aren't signed up to the mailing list, yet, so we'll have to keep the firstpoint address in CC. 

Another point is that your replies ain't send to the list because you didn't create your personal mailto-address (you can check it here: http://sonar-intellij-plugin.55862.x6.nabble.com/, only my mails are send there)

Short: nabble's usability sucks big time IMO!

I created a forum at google groups as an alternative (see Cc):https://groups.google.com/forum/#!msg/sonarcube-intellij-plugin/

Let's see how this works. All of you should receive this mail twice now! Once via Firstpoint and once via Google.

The Google Groups is definitely easier on my end, but don't have a strong preference one way or another.

Cheers

Alex

--
You received this message because you are subscribed to the Google Groups "SonarCube IntelliJ Plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarcube-intellij...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarcube-intellij-plugin/90D7911C-38F9-4CE9-96CD-8D6230C45F98%40goldstift.de.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alpar Gal]

Hi guys

Sorry for replying late, I've been busy lately and I think I will in august/september as well. If we decide that want to have the run local analysis (i think is a handy feature personally I would use it at my work. Sure we can integrate different way to show the results in the inspection tab. But still need to decide 4 of us in case we need or not) I could try to push to the new repo merged or somewhere else, but I cannot commit for a deadline,

From the feature/pull request point of view I totally agree is a good approach to have pull requests and some of us review each others pulls. Also features would be great to be in git hub so that everyone can see and comment  them. About the licensing personally I don't mind which one is chosen, until is an open source one :).

Also I'm a fan of automation and tests  so I would go for CI integration. Also I would write more functional tests even if they are harder/slower/quite hard get to work with maven than pure unit test. I think it can help us a lot. I read somewhere the gradle can be a solution to get the intellij func tests to work. 


Kind regards

Alpar

Sent from my iPad

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarcube-intellij-plugin/CAF1gAWtP8UuJceFuE7o%2BtEior90KUDVwfc6akva-zwJNUvRcMw%40mail.gmail.com.

[Alexander Heusingfeld]

Hi guys,

great you agree!

@Alpar +1 on the local analysis feature. I'm absolutely sure Oleg will also +1 when he sees what the code changes are about!

On the "Inspections tab": Oleg's code base already comes with an abstraction for inspections. Therefore the task should take less effort as you can "simply" create a new implementation of the abstraction. :)

Of course nobody will force you to commit to a deadline as each one of us is dedicating his spare time on the project. We'll all do what we can to drive the project forward!

So I guess the only thing left before we can start is the decision on a license, right? I hope to come up with a comparison by Sunday.

Cheers

Alex

-- sent from a mobile device

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarcube-intellij-plugin/4AFA0903-1686-4205-A204-B12C9D02039A%40gmail.com.

[omayevskiy]

Am Donnerstag, 1. August 2013 01:24:45 UTC+2 schrieb aheusingfeld:

Sorry for not being too clear on this: 

My personal target is to be able to use the plugin for Java, Groovy, Ruby and Clojure sources. As we also have a feature request for PHP and JavaScript, I would never want to exclude anything that Sonar can analyze!!

So how is the "local analysis" feature meant to work? Like that:

Currently Sonar's local analysis is run by starting Sonar in a separate JVM. This takes up a lot of time and memory! When I say "in-process local analysis" it means that Sonar analysis is run in the same JVM that IntelliJ/ WebStorm/ RubyMine are run in. This can be done because the SonarSource guys extracted the specific code which analysis violations inside Sonar into the so called "sonar-runner". This retrieves the configuration for the selected module from the remote Sonar server and executes the checks locally.

The sonar-runner shouldn't be limited to Java as it's the same code which is used inside Sonar server. It just needs a JVM to run in.

Alpar made a contribution to this SonarSource project because prior to version 2.3 a local analysis couldn't be aborted.

My main worry is about how it works. E.g. for groovy you need a sonar groovy plugin to be downloaded. How does it work with sonar-runner? Does it care about this? At the end if this feature really works for any language, it's great, but we should not forget all the cases and also test it with something else then java. You can take this as base for project example for different languages:

https://github.com/SonarSource/sonar-examples/tree/master/projects/languages

 

A working travis CI build is IMHO very useful as a first validation of code contributions which are then build automatically.

Actually I don't really use maven to build the plugin ;-) Well I have a pom.xml but it is used by another intellij plugin for just sync the deps to intellij. Afterwards it's built by IntelliJ in the standart way. This is my preferred way, why more complex? KISS ;-) Do we really need CI? We could also apply to convention, that if anyone share code, he runs all tests locally.

It's a large effort to setup environments for different IntelliJ versions just to be able to verify that one's contribution doesn't fail any test in any environment. 

This is even a greater barrier for one-time contributors which sometimes bring in very valuable contributions.

But that is exactly where a good CI process kicks in! The optimum in my point of view would be that each contribution a.k.a. pull-request (in the future) is build and validated against the current version of IntelliJ-community jars, the previous version and the latest EAP build.

Currently this means we'd have three builds for IntelliJ11, 12 and 13 - always the latest release. At the moment I still believe this is realizable via Gradle and Git but I'll have to dig into this a little deeper.

My question: who takes care about CI and do it? :) In my opinion it is enough to release for current stable version only. For Backwards support a user should take an older release which was built for it, but well he will be missing new features.

Well I don't had really time for tests till now. Some one should take care about integration tests in intellij, I also would do it, if other features are done and I have time.

I experienced that people have a different understanding of the term "integration tests". As we're talking about a plugin connecting to a remote server, I'd say an integration test would deal with exactly this: Check whether the above mentioned three plugins connect to different Sonar servers/ server versions. Unfortunately we'd need to have some hosted Sonar servers then.

Could you give me your understanding?

Yes there is no simple answer for it. My idea of integration test is: 

mock the results of sonar server

create test source files (or just use the sonar example projects)

ensure that plugin:

 marked the code in editor

 added violations

this one for different languages, that is

[Tobias Nyholm]

A working travis CI build is IMHO very useful as a first validation of code contributions which are then build automatically.

Actually I don't really use maven to build the plugin ;-) Well I have a pom.xml but it is used by another intellij plugin for just sync the deps to intellij. Afterwards it's built by IntelliJ in the standart way. This is my preferred way, why more complex? KISS ;-) Do we really need CI? We could also apply to convention, that if anyone share code, he runs all tests locally.

It's a large effort to setup environments for different IntelliJ versions just to be able to verify that one's contribution doesn't fail any test in any environment. 

This is even a greater barrier for one-time contributors which sometimes bring in very valuable contributions.

But that is exactly where a good CI process kicks in! The optimum in my point of view would be that each contribution a.k.a. pull-request (in the future) is build and validated against the current version of IntelliJ-community jars, the previous version and the latest EAP build.

Currently this means we'd have three builds for IntelliJ11, 12 and 13 - always the latest release. At the moment I still believe this is realizable via Gradle and Git but I'll have to dig into this a little deeper.

I would like to contribute to this team. I don't have years of Java experience but I think I can give something to the application. I can set up a Jenkins CI server and Sonar for software quality. Just tell me when to start. 

[Alpar Gal]

Hi Oleg,

Sonar runner (http://docs.codehaus.org/display/SONAR/Analyzing+with+SonarQube+Runner)  is recommended as the default launcher to analyze a project with SonarQube. (copied this from the project site). Sonnar runner will download the necessary jars/plugins and do the analysis. Sure other alternatives are the sonar maven plugin, ant, groovy to run the same way the analysis, but you need this tools be be installed in case you use these alternatives. To run sonar-runner you need only have to be there and that's it. 

For example (forget our intellij plugin) if you would download the sonar runner kit from sonar site and you would lunch sonar-sonar-runner.bat or linux version (sure before doing that in sonar-project.properties you need to specify the source folder, user, password and also module(s) programming language and sonar server url) you will be able to do local analysis on the  your local machine without having sonar server installed. 

Now if we don't want when we run sonar runner to push the results to sonar server there is a special flag for that:

# Set the "sonar.dryRun" property to "true" to run a local analysis sonar-runner -Dsonar.dryRun=true

By doing this sonar runner will make a *.json file where the analysis result will be stored it won't touch the target sonar server. Class -> {List of violations}.

Now the idea is to integrate sonar runner into our plugin so we show up to date results right away. 

My contribution v1 is dealing only with java, but that is quite easy to change/improve .  When we are running sonar runner from plugin at the end we are executing sonar runner with a few command line arguments..  If we would say -Dsonar.language=cobol then sonar runner will treat as a cobol project.

i.e.

# required metadata

-Dsonar.projectKey=my:project

-Dsonar.projectName=My project

-Dsonar.projectVersion=1.0

# path to source directories (required)

-Dsonar.sources=srcDir1,srcDir2

# The value of the property must be the key of the language.

-Dsonar.language=cobol

If we decide to go (+1 from me as well). I can adapt to guess the module language before running the local analysis. 

Kind regards

Alpar

--
You received this message because you are subscribed to the Google Groups "SonarQube IntelliJ Plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube-intellij...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube-intellij-plugin/adff96df-e159-4677-9715-49ebac75705c%40googlegroups.com.

[Alexander Heusingfeld]

Hi Tobias,

Am 06.08.2013 um 16:18 schrieb Tobias Nyholm <tobias...@gmail.com>:

> I would like to contribute to this team. I don't have years of Java experience but I think I can give something to the application. I can set up a Jenkins CI server and Sonar for software quality. Just tell me when to start.

That's great to hear. If you like you could setup a Jenkins build including Sonar analysis as soon as Oleg ported the sources to https://github.com/sonar-intellij-plugin/sonar-intellij-plugin

On the long run I'd like to setup a travisCI build as I read that you can run builds for each pull-request this way. As I didn't use TravisCI before, I don't know when I'll finish this. Therefore it would be great to have an alternative in the meantime. Thanks for your offer!

Cheers
Alex

[Alpar Gal]

Hi Tobias,

Good to have here. Welcome! I think as soon as we have something in the common codebase we can start doing CI.  Would be really helpful your help. Not sure if Alexander wanted to do some CI, maybe worth to check with him what was his ideas as well.

@oleg to answer your question about the CI Tobias can help us to set up continuos integration. Also if grandle would help us to run the functional tests we could add a graddle build as well.

Alpar

--
You received this message because you are subscribed to the Google Groups "SonarQube IntelliJ Plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube-intellij...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube-intellij-plugin/7109cac3-fea3-417f-8cc2-1f3a6dea8e36%40googlegroups.com.

[Oleg Mayevskiy]

Hi Alpar,

thx for the explanation, got the idea.
So the issue for our plugin is provide the sonar project configuration correctly to sonar-runner.
Actually this is the same thing as just running sonar-runner in folder where sonar.properties is located. But well this also depends on project configuration, some projects will use mvn or some thing else to run sonar.

So I think:
 * we should provide a nice way to configure sonar-runner. Additionally we can have some auto detect, e.g. if found sonar.properties , then use this.
 * add a switch between remote and local in the ui. Depends on this remote sonarService or sonar-runner logic should be used to get the violations.

Best, Oleg.

[Alexander Heusingfeld]

Sounds reasonable!
But as this doesn't have much to do with the "Roadmap" subject, I'd suggest that you continue the feature discussion in a github issue. Agreed?

@Oleg can you already see when you will be ready to move the sources to the new repo?

Cheers
Alex

[omayevskiy]

no need to wait, you can clone code from https://github.com/omayevskiy/sonar-intellij-plugin and start working.

later you can easily switch git remote. (actually you can also have more then one remote)

to answer your question: if mischa has did a release

[Tobias Nyholm]

This project has stalled for a while now. I imported the  https://github.com/omayevskiy/sonar-intellij-plugin repo. 

mvn install seems to be broken. Can @omayevskiy have a look?