well if it is not validated by default we just get rid of them IMHO.
Having to rely on the CI for it is a pain and slows down the dev
process. If it is too long it can also means our code should be
refactored (too big classes/too much classes by modules) so
definitively +1 to have it on by default


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-10-03 13:52 GMT+02:00 Thiago Veronezi <[email protected]>:
> I agree. It should be triggered by default, but it depends if we are OK on
> having a slower build.
> It would take a bit longer to build the project with these guys enabled.
>
> I have a good computer :), so My vote also goes to "activated by default".
>
> []s,
> Thiago.
>
>
> On Fri, Oct 3, 2014 at 7:24 AM, Romain Manni-Bucau <[email protected]>
> wrote:
>
>> Btw we should have it by default in the build no?
>>
>> Le vendredi 3 octobre 2014, Thiago Veronezi <[email protected]> a écrit
>> :
>> > We have pmd and checkstyle rules in the project. You can take a look at
>> it
>> > here ->
>> http://svn.apache.org/repos/asf/tomee/tomee/trunk/src/main/style/
>> >
>> > Not all the rules are already applied. Some of them are too hard to fix,
>> or
>> > even conflicting with the existing ones.
>> > You can start it by uncommenting one rule at a time and checking what
>> > breaks. You can run the checks at the root level with...
>> >
>> > mvn checkstyle:check -Pstyle
>> > mvn pmd:check -Pstyle
>> >
>> > Check the "style" profile here to see whats covered ->
>> > http://svn.apache.org/repos/asf/tomee/tomee/trunk/pom.xml
>> >
>> >>> (I've seen several methods that are too long for
>> >>> me).
>> > This is one of the commented out rules.
>> >
>> > []s,
>> > Thiago.
>> >
>> >
>> >
>> > On Fri, Oct 3, 2014 at 3:42 AM, Romain Manni-Bucau <
>> [email protected]>
>> > wrote:
>> >
>> >> About lombok: it is great but our constraints would be: no transitive
>> >> dependency on it (delombokization + no usage of some parts), no over
>> usage
>> >> (some equals hascode or other lombok impl would break the container)
>> >>
>> >>
>> >>
>> >> Le vendredi 3 octobre 2014, Andy Gumbrecht <[email protected]> a
>> >> écrit :
>> >> > Hi Daniel,
>> >> > The builds are here:
>> >> > http://ci.apache.org/builders/tomee-1.7.x-ubuntu
>> >> > http://ci.apache.org/builders/tomee-trunk-ubuntu
>> >> >
>> >> > Trunk is and has not been stable since the branch, so please feel free
>> to
>> >> help out there.
>> >> > There is simply a hell of a lot of work going on, so it's catch up
>> time.
>> >> >
>> >> > If you need things stable then check out the 1.7.x branch, which is
>> also
>> >> very actively maintained.
>> >> >
>> >> > It is an apache rule that we not boldly promote or point to snapshot
>> >> activity on the site in order to conserve bandwidth, so you are right to
>> >> come here on the dev list and ask about it. That is why it is buried a
>> >> little deeper in the site.
>> >> >
>> >> > As long as a refactor is performed independently of any other action
>> then
>> >> usually it is fine, but don't go too crazy with it and always try to at
>> >> least do a full build with or without tests. That said, I think it's
>> best
>> >> done on trunk rather than 1.7.x
>> >> >
>> >> > Finals ensure that your intention is clear. It would have been nice to
>> >> have this as a vm default. They prevent the introduction of side effects
>> >> stat. Of which there have been many in such a large project. Issues
>> related
>> >> to non final variables that should have been declared so are extremely
>> hard
>> >> to track down, so it's a tiny overhead for an IDE to point them out and
>> for
>> >> you to apply them.
>> >> >
>> >> > Some of us are at JavaOne, so we should be back next week and get more
>> >> active on TomEE soon.
>> >> >
>> >> > Have fun,
>> >> >
>> >> > Andy.
>> >> >
>> >> > On 03/10/2014 01:04, Daniel Kasmeroglu wrote:
>> >> >>
>> >> >> Hi there,
>> >> >>
>> >> >> I'm currently trying to get in touch with Tomee/OpenEJB's codebase in
>> >> >> order to gain more insights about it.
>> >> >>
>> >> >> My usual procedure is to run a clean build in order to verify that
>> >> >> everything works fine before I make an attempt to provide some
>> patches.
>> >> >>
>> >> >> Unfortunately the build is not completely passing through
>> >> >> (http://svn.apache.org/repos/asf/tomee/tomee/trunk@1629078) even
>> >> >> though I disabled the tests. Checked under Windows 7 (my main system)
>> >> >> as well as under Ubuntu Linux.
>> >> >>
>> >> >> So basically I have some questions to get the build properly going:
>> >> >>
>> >> >> * Is there a Continuous Integration system and if so, where can I
>> find
>> >> >> it ? I failed to locate a link on the tomee site.
>> >> >>
>> >> >> * What is the general policy regarding the code quality ? I mean
>> >> >> usually I intend to keep everything going, so if someone breaks a
>> >> >> build he's responsible to solve it.
>> >> >>
>> >> >> * The contribution site points out that it's common practice to use
>> >> >> final variables and fields. Can someone elaborate on this ? I see
>> that
>> >> >> a lot but in open source code but I think there's usually no point in
>> >> >> doing that (I can elaborate on that).
>> >> >>
>> >> >> * I personally would focus first on refactorings in order to get the
>> >> >> code more readable (I've seen several methods that are too long for
>> >> >> me). One nice tool for this would be lombok
>> >> >> (http://projectlombok.org/). I know that it's supported through
>> >> >> Eclipse/IDEA and Maven. Are there any objections ?
>> >> >>
>> >> >>
>> >> >> Best regards
>> >> >>
>> >> >> Daniel Kasmeroglu
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> >   Andy Gumbrecht
>> >> >   https://twitter.com/AndyGeeDe
>> >> >   http://www.tomitribe.com
>> >> >
>> >> >
>> >>
>> >> --
>> >>
>> >>
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: http://rmannibucau.wordpress.com/
>> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >> Github: https://github.com/rmannibucau
>> >>
>> >
>>
>> --
>>
>>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>

Reply via email to