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
