Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of trippie@gmail.com designates
 74.125.83.47 as permitted sender)
Sender: Trippie <trippie@gmail.com>
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Subject: Re: checkstyle problems...
From: Hugo Trippaers <hugo@trippaers.nl>
In-Reply-To: <20CF38CB4385CE4D9D1558D52A0FC0581E83B9@SJCPEX01CL03.citrite.net>
Date: Wed, 15 Jan 2014 08:31:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AF983DE-7639-4465-84CD-303081FDE674@GMAIL.com>
References: <20CF38CB4385CE4D9D1558D52A0FC0581E7CE5@SJCPEX01CL03.citrite.net>
 <CACOnxCiGx2BDC-E9jWYKqHei4Rf=h2t-dfSNNhfnFCJH6Ktiuw@mail.gmail.com>
 <20CF38CB4385CE4D9D1558D52A0FC0581E83B9@SJCPEX01CL03.citrite.net>
To: dev <dev@cloudstack.apache.org>

Hey guys,


There are two ideas behind using checkstyle a i=92ve 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=92t 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=92m 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=92m in =
agreement that it shouldn=92t cause trouble when using an editor like =
eclipse. I=92m not seeing those issues in my eclipse at the moment, so =
i=92ll try to reproduce them and see if they can be fixed.

Cheers,

Hugo


On 15 jan. 2014, at 05:02, Alex Huang <Alex.Huang@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.
>=20
> --Alex
>=20
>> -----Original Message-----
>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
>> Sent: Tuesday, January 14, 2014 12:01 PM
>> To: dev@cloudstack.apache.org
>> Cc: Hugo Trippaers (HTrippaers@schubergphilis.com)
>> Subject: Re: checkstyle problems...
>>=20
>> 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.
>>=20
>>=20
>> On Tue, Jan 14, 2014 at 12:44 PM, Alex Huang <Alex.Huang@citrix.com>
>> wrote:
>>=20
>>> Hi Hugo,
>>>=20
>>> 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?
>>>=20
>>> If we prefer the per-project checkstyle still, then we need to =
resolve
>>> these problems because it happens on every recompile.
>>>=20
>>> 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.
>>>=20
>>> --Alex
>>>=20
>>=20
>>=20
>>=20
>> --
>> *Mike Tutkowski*
>> *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkowski@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the
>> cloud<http://solidfire.com/solution/overview/?video=3Dplay>
>> *(tm)*