Heya,

The disable profile is in the pom now. If you add the profile disablecheckstyle 
to your eclipse m2e configuration for cloudstack, all checkstyle configuration 
from maven will be ignored.

Cheers,

Hugo

On 16 jan. 2014, at 16:11, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote:

> That sounds good, Hugo - thanks!
> 
> 
> On Thu, Jan 16, 2014 at 2:53 AM, Hugo Trippaers <h...@trippaers.nl> wrote:
> 
>> Yeah,
>> 
>> swapping out branches is a tricky thing in eclipse. I generally use two
>> workspaces, one for master and one for current release branch.
>> 
>> I noticed that when you swap branches eclipse keeps the “old” checkstyle
>> config, but without any of the limitations place on it by the poms, because
>> those are gone.
>> 
>> I’ll fix the problem with the nvp plugin in 4.3 right away, the project
>> config didn’t get removed when the checkstyle project was removed.
>> 
>> Other than that, with the latest updates to the poms it’s running smoothly
>> for me. Even when reimporting the projects, but i removed my
>> .m2/repo../../cloudstack folder as well.
>> 
>> I could make a profile that turns off checkstyle in all the subprojects?
>> That could help to reduce the problems which switching between 4.3 and
>> master.  Once we start the 4.4 track it shouldn’t be that much of a problem
>> any more. Especially if i remove the snapshot tag from the checkstyle
>> project, there is actually no need to keep that versioned together with CS.
>> That way multiple branches can all use the same checkstyle config.
>> 
>> Is that workable for you guys?
>> 
>> Cheers,
>> 
>> Hugo
>> 
>> On 15 jan. 2014, at 18:05, Mike Tutkowski <mike.tutkow...@solidfire.com>
>> wrote:
>> 
>>> Yeah, and to clarify, the reason I sometimes do that is if I switch
>> between
>>> branches. I've noticed many problems in Eclipse when I swap out a branch
>>> underneath it, so I generally remove all the projects and re-import them
>> at
>>> these times.
>>> 
>>> 
>>> On Wed, Jan 15, 2014 at 10:02 AM, Alex Huang <alex.hu...@citrix.com>
>> wrote:
>>> 
>>>> Hugo,
>>>> 
>>>> I didn't see any problems at first either.  Later, when I tried to
>> figure
>>>> out why Mike was seeing problems, I remembered he said he often deletes
>> the
>>>> whole workspace and started over.  So I did the same.  I removed my
>> eclipse
>>>> workspace and removed all .project files and started over completely.
>>>> After that, I started seeing the problems.
>>>> 
>>>> --Alex
>>>> 
>>>>> -----Original Message-----
>>>>> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
>>>>> Sent: Tuesday, January 14, 2014 11:31 PM
>>>>> To: dev
>>>>> Subject: Re: checkstyle problems...
>>>>> 
>>>>> Hey guys,
>>>>> 
>>>>> 
>>>>> There are two ideas behind using checkstyle a i've currently
>> implemented
>>>> it
>>>>> in the maven build. First of all it runs for every project, this means
>>>> that
>>>>> triggering a compile on a single module will also run the checkstyle
>>>> checks on
>>>>> it. So you don't have to recompile the entire project and use the slow
>>>> global
>>>>> checkstyle check, but fast local audit. This also ties in with my plans
>>>> to get
>>>>> incremental builds going, the idea is to get Jenkins feedback on a
>> commit
>>>>> within 5 minutes of doing the commit. For this we need incremental
>> builds
>>>>> which builds only the modules that were touched by a commit (and
>> possibly
>>>>> dependents). By having checkstyle local to the module, it would be
>>>> included
>>>>> in such a build. Secondly by making it a maven module like this it
>> means
>>>>> external plugin developers can include the exact same maven
>> configuration
>>>>> for their project and download our checkstyle configuration using the
>>>> maven
>>>>> framework. Not really a big deal, but it might help when we have more
>>>>> separate repositories for plugins.
>>>>> 
>>>>> The same reasoning goes for the maven license plugin, i'm testing that
>>>> one in
>>>>> the opendaylight plugin and it could replace the rat checks with a
>> simple
>>>>> check that would run on every module individually. But more on that
>> later
>>>>> 
>>>>> So my preference would be to keep it as is obviously, but i'm in
>>>> agreement
>>>>> that it shouldn't cause trouble when using an editor like eclipse. I'm
>>>> not
>>>>> seeing those issues in my eclipse at the moment, so i'll try to
>>>> reproduce them
>>>>> and see if they can be fixed.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Hugo
>>>>> 
>>>>> 
>>>>> 
>>>>> On 15 jan. 2014, at 05:02, Alex Huang <alex.hu...@citrix.com> wrote:
>>>>> 
>>>>>> Yes.  I do believe it runs on every eclipse recompile because it's now
>>>> part of
>>>>> the build for every project.  I've gotten so frustrated with it, I've
>>>> reverted the
>>>>> commit locally but I don't know checkstyle very well so I'm hoping Hugo
>>>> has a
>>>>> better solution.
>>>>>> 
>>>>>> --Alex
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>>>>>>> Sent: Tuesday, January 14, 2014 12:01 PM
>>>>>>> To: dev@cloudstack.apache.org
>>>>>>> Cc: Hugo Trippaers (htrippa...@schubergphilis.com)
>>>>>>> Subject: Re: checkstyle problems...
>>>>>>> 
>>>>>>> I also think the way I have checkstyle configured in Eclipse causes
>>>>>>> it to take a super long time to build. Not sure what setting I turned
>>>>>>> on to do that, but even removing the plug-in for the time being is
>>>>>>> extremely slow because Eclipse always wants to run checkstyle.
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, Jan 14, 2014 at 12:44 PM, Alex Huang <alex.hu...@citrix.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi Hugo,
>>>>>>>> 
>>>>>>>> I see that you added the checkstyle project back in.  I actually
>>>>>>>> tried that first when I made checkstyle required for the entire
>>>>>>>> project.  It is the recommended procedure from the checkstyle
>>>> website.
>>>>>>>> Unfortunately, it causes problems like the following exceptions in
>>>>>>>> eclipse all
>>>>>>> of the time.
>>>>>>>> That's why I went with one checkstyle step for the entire
>> cloudstack.
>>>>>>>> I think given that we have editors that can help with formatting the
>>>>>>>> code, it shouldn't be that much of a problem to do one step only.
>>>>>>>> What do
>>>>>>> you think?
>>>>>>>> 
>>>>>>>> If we prefer the per-project checkstyle still, then we need to
>>>>>>>> resolve these problems because it happens on every recompile.
>>>>>>>> 
>>>>>>>> Errors occurred during the build.
>>>>>>>> Errors running builder 'Checkstyle Builder' on project 'cloudstack'.
>>>>>>>> Fileset from project "cloudstack" has no valid check configuration.
>>>>>>>> Fileset from project "cloudstack" has no valid check configuration.
>>>>>>>> Fileset from project "cloudstack" has no valid check configuration.
>>>>>>>> Fileset from project "cloudstack" has no valid check configuration.
>>>>>>>> Errors running builder 'Checkstyle Builder' on project
>>>>>>>> 'cloudstack-service-console-proxy'.
>>>>>>>> Fileset from project "cloudstack-service-console-proxy" has no valid
>>>>>>>> check configuration.
>>>>>>>> Fileset from project "cloudstack-service-console-proxy" has no valid
>>>>>>>> check configuration.
>>>>>>>> Fileset from project "cloudstack-service-console-proxy" has no valid
>>>>>>>> check configuration.
>>>>>>>> Fileset from project "cloudstack-service-console-proxy" has no valid
>>>>>>>> check configuration.
>>>>>>>> Errors running builder 'Checkstyle Builder' on project 'xapi'.
>>>>>>>> Fileset from project "xapi" has no valid check configuration.
>>>>>>>> Fileset from project "xapi" has no valid check configuration.
>>>>>>>> Fileset from project "xapi" has no valid check configuration.
>>>>>>>> Fileset from project "xapi" has no valid check configuration.
>>>>>>>> 
>>>>>>>> --Alex
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> *Mike Tutkowski*
>>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>>> e: mike.tutkow...@solidfire.com
>>>>>>> o: 303.746.7302
>>>>>>> Advancing the way the world uses the
>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>>> *(tm)*
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkow...@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the
>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>> *™*
>> 
>> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*

Reply via email to