Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of trippie@gmail.com designates
 74.125.83.44 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: 
 <CACOnxCjLc1U4vS19TPKB5Lgg3+FQGZRgSxT9qBJYj=SPfGx0Hw@mail.gmail.com>
Date: Thu, 16 Jan 2014 10:53:40 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <763CD319-830B-46A3-9363-B2AF453F36EC@GMAIL.com>
References: <20CF38CB4385CE4D9D1558D52A0FC0581E7CE5@SJCPEX01CL03.citrite.net>
 <CACOnxCiGx2BDC-E9jWYKqHei4Rf=h2t-dfSNNhfnFCJH6Ktiuw@mail.gmail.com>
 <20CF38CB4385CE4D9D1558D52A0FC0581E83B9@SJCPEX01CL03.citrite.net>
 <8AF983DE-7639-4465-84CD-303081FDE674@GMAIL.com>
 <20CF38CB4385CE4D9D1558D52A0FC0581E8617@SJCPEX01CL03.citrite.net>
 <CACOnxCjLc1U4vS19TPKB5Lgg3+FQGZRgSxT9qBJYj=SPfGx0Hw@mail.gmail.com>
To: dev <dev@cloudstack.apache.org>

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 =93old=94 =
checkstyle config, but without any of the limitations place on it by the =
poms, because those are gone.

I=92ll fix the problem with the nvp plugin in 4.3 right away, the =
project config didn=92t get removed when the checkstyle project was =
removed.

Other than that, with the latest updates to the poms it=92s 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=92t 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=20

On 15 jan. 2014, at 18:05, Mike Tutkowski <mike.tutkowski@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.
>=20
>=20
> On Wed, Jan 15, 2014 at 10:02 AM, Alex Huang <Alex.Huang@citrix.com> =
wrote:
>=20
>> Hugo,
>>=20
>> 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.
>>=20
>> --Alex
>>=20
>>> -----Original Message-----
>>> From: Trippie [mailto:trippie@gmail.com] On Behalf Of Hugo Trippaers
>>> Sent: Tuesday, January 14, 2014 11:31 PM
>>> To: dev
>>> Subject: Re: checkstyle problems...
>>>=20
>>> Hey guys,
>>>=20
>>>=20
>>> 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.
>>>=20
>>> 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
>>>=20
>>> 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.
>>>=20
>>> Cheers,
>>>=20
>>> Hugo
>>>=20
>>>=20
>>>=20
>>> On 15 jan. 2014, at 05:02, Alex Huang <Alex.Huang@citrix.com> wrote:
>>>=20
>>>> 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)*
>>=20
>>=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>
> *=99*