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> *™*