That's not true, it was discussed during team meeting at
the times we've been using G+ as well (I can't prove that) and on ML as well:
It just took 7 month for the PR to be merged. The point of initial checkstyle
rules set was chosen because:
* It was identified as the least annoying setup on ML, there were a lot of +1s
* There was a bug in released library caused by using unused import that was not
available on classpath. I might be able to dig it out but it would take me a
lot of time as I don't recall what project it was.
+9001 for abstract's proposal on having same setup for IDE as well. There is
nothing more annoying then something working in IDE but not in Maven. -1 for the
specific profile, as it shifts responsibility to clean up the mess to the person
doing the release.
Karel
On Tue, 20 May 2014 16:20:52 -0300
Bruno Oliveira <bruno(a)abstractj.org> wrote:
The only reason to have checkstyle enabled by default is: if we agree
on
which rules should be active or not and provide an specific IDE setup.
Other than that, people like me will skip it. Why? Simple, I'm trying to
solve critical problems and also strugging to figure out why checkstyle
is do care about method lenght.
So to me if you're guys really want to introduce it we need:
- Definition of which rules were supposed to be active
- IDE profiles for Eclipse/IntelliJ
- Make the error messages something clear
Otherwise, I'm -∞. It was never discussed here and if it exists on
aerogear-parent is all our fault.
On 2014-05-20, Daniel Bevenius wrote:
> -1 I'd prefer to have checkstyle enabled by default, and integrate the
> checkstyle into the IDE to avoid having to discover issue later when
> building with maven.
>
>
> On 20 May 2014 20:56, Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
> > +1 on having an specific profile for checkstyle
> >
> > On 2014-05-20, Matthias Wessendorf wrote:
> > > Hello,
> > >
> > > w/ the advent of the 0.2.0 parent, we have checkstyle enabled;
> > >
> > > However, I am not that happy, as the default rules are IMO a bit odd
> > (e.g.
> > > the unused imports is pretty nasty when developing)
> > >
> > > We could:
> > > a) get rid of it (perhaps not)
> > > b) disable it on normal execution and only execute it on a release
> > profile
> > > or like that
> > >
> > > right now I am running w/ skip - but that's a bit nasty...
> > >
> > > Thoughts?
> > > Matthias
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > blog:
http://matthiaswessendorf.wordpress.com/
> > > sessions:
http://www.slideshare.net/mwessendorf
> > > twitter:
http://twitter.com/mwessendorf
> >
> > > _______________________________________________
> > > aerogear-dev mailing list
> > > aerogear-dev(a)lists.jboss.org
> > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> >
> > --
> >
> > abstractj
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev