Hi Karel, with the appropriate templates in place, that would make
sense.
I vote for adding it on CI.
+1
In general I like the idea of checkstyle and friends, but it really
slows down the code test commit flow when something trips me up.
It should probably be a profile thing like you said before.
On 2014-05-22, Karel Piwko wrote:
> This is the same issue as with unit tests. If they tend to take too
> much time, people are skipping them.
>
> What about activating checkstyle in CI and or Git push hook, for both PRs and
> direct commits upstream. This way a developer can develop without constraints
> *until* he wants to push the code upstream. Would it help?
>
> Thanks,
>
> Karel
>
> On Wed, 21 May 2014 11:38:02 -0300
> Bruno Oliveira <bruno(a)abstractj.org> wrote:
>
>> I don't think you need to prove anything, to me is just the matter of
>> reach a consensus and think about what works for the whole team.
>>
>> Is still possible skip checkstyle and leave the mess to the person doing the
>> release, even worse, the person doing the release can also skip this.
>>
>> The only thing able to guarantee the quality of the code is the developer's
>> conscience. I don't think that enforcing checkstyle default rules will make
>> us more conscious tbh.
>>
>> On 2014-05-21, Karel Piwko wrote:
>>> 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:
>>>
>>>
http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaScript-formatt...
>>>
>>> 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
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> --
>>
>> abstractj
>>
>> JBoss, a division of Red Hat
>> _______________________________________________
>> 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 >Phone:404 941 4698
>Java is my crack.