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

Reply via email to