Probably late at this one, but I'm also +1 on Style C..
br, juan pablo On Sun, Jul 21, 2013 at 2:03 PM, Glen Mazza <[email protected]> wrote: > Part of JSPWiki's selling point is its quickness/speed, so yes, weighing > down the project with Spring would probably not be a useful direction for > us. If you can equivalently accomplish those items where Spring would be > most beneficial for us without needing to bring in Spring itself, offhand, > sounds good... > > Glen > > > On 07/20/2013 06:17 PM, Ichiro Furusato wrote: > >> All I'm doing is replicating the existing objects and instantiation order >> by capturing that configuration in an XML file, which replaces, in two >> parts, the module configuration and the redeclarations in >> jspwiki.properties using identical syntax files. Nothing more. A >> dependency >> manager would be great but then we're heading into the complexity of >> Spring, which is lovely and golden but extremely heavyweight, especially >> for a wiki. But I don't want to get into a religious discussion with >> Spring >> advocates since we're already in a religious discussion with syntax >> advocates. >> >> One thing I have always liked about JSPWiki is its simplicity. I'm >> actually >> trying to simplify (or at least organise) the bootstrap code, not make it >> more complicated. If you have any ideas on how to actually accomplish such >> a dependency manager without making life more complicated for either the >> team programmers or those hacking the code I'm all ears. >> >> Ichiro >> >> >> On Sun, Jul 21, 2013 at 2:53 AM, Janne Jalkanen <[email protected] >> >**wrote: >> >> It sounds to me like you're reinventing Spring here. >>> >>> The initialization order is very tricky, yes. A better solution would be >>> to have a dependency manager (you could declare the dependencies using >>> annotations) for example, and then autodiscover the components from the >>> class path. XML is just doing manually stuff that should be done >>> automatically anyway. >>> >>> /Janne >>> >>> On Jul 20, 2013, at 16:18 , Ichiro Furusato <[email protected]> >>> wrote: >>> >>> Well, what I'm doing right now is pretty drastic. I don't in the end >>>> know >>>> what's going to happen to this but I continue to move forward. >>>> >>>> As a progress report, I've so far begun to gradually replace some of the >>>> managers with interfaces, built the EntityManager that acts like a >>>> bootstrap loader and creates all of the managers from an XML >>>> >>> configuration >>> >>>> file, then provides Map-style access to them (so that all of the getter >>>> methods in WikiEngine could be removed). Instantiation of managers is >>>> now >>>> happening within the EntityManager rather than within the WikiEngine. >>>> >>> I've >>> >>>> managed to do the first five managers (in instantiation order), but I'm >>>> noting that the order in which things are instantiated and initialised >>>> is >>>> in the future going to get a bit tricky, so if everything fails my >>>> >>> fallback >>> >>>> is to let the WikiEngine request the managers from the EntityManager >>>> >>> using >>> >>>> the existing instantiation/initialisation order via local variables, >>>> providing access only via the EntityManager once everything is up and >>>> running. >>>> >>>> Not sure that makes sense written down but my tests are passing. >>>> >>>> Changing the coding convention to "Style C" is relatively easy within >>>> Eclipse: just select the code you want formatted and choose >>>> >>> Source:Format, >>> >>>> then go in and make any minor adjustments. With all due respect, I wish >>>> I >>>> agreed with your idea of a readable convention -- I frankly don't find >>>> >>> the >>> >>>> long-and-drawn-out vertical of the Avalon style easy to read at all >>>> since >>>> even with a reasonable size screen it's about twice as many lines as the >>>> Eclipse/Sun standard. But I likewise respect that each of us has norms >>>> >>> that >>> >>>> we've grown used to. I didn't bring the subject up and I think computers >>>> telling us what to do (e.g. Sonar) is regrettable, but I would like this >>>> resolved so I don't spend too much time formatting and reformatting the >>>> code I'm working on. I've so far touched probably two dozen files and I >>>> don't want to spend hours trying to match Style B. Getting to Style C >>>> >>> takes >>> >>>> seconds since (as I mentioned above) it's roughly the default in >>>> Eclipse. >>>> >>>> And frankly, I'm not myself all *that* fussed about what the convention >>>> >>> is >>> >>>> but recognise that it's better to be consistent across a project. I'd >>>> >>> just >>> >>>> rather have this resolved. >>>> >>>> This reminds me of a two line aphorism a friend and I wrote (each one >>>> >>> line) >>> >>>> on a post-it during a meeting: >>>> >>>> Code is poetry >>>> Machines don't care >>>> >>>> With that in mind I'm going back to coding... >>>> >>>> Ichiro >>>> >>>> >>>> On Sat, Jul 20, 2013 at 11:28 PM, Janne Jalkanen >>>> <[email protected]>**wrote: >>>> >>>> BTW, changing the coding convention also means that anyone maintaining >>>>> >>>> any >>> >>>> sort of a patch against the current codebase will need to do a complete >>>>> rebase. Which is why I would advise against doing anything so drastic >>>>> except during major releases (which can be expected to break backwards >>>>> compatibility anyway). >>>>> >>>>> /Janne >>>>> >>>>> On Jul 20, 2013, at 13:32 , Ichiro Furusato <[email protected] >>>>> > >>>>> wrote: >>>>> >>>>> Hi Janne, >>>>>> >>>>>> I've looked around the Apache site and unfortunately can find no >>>>>> >>>>> ASF-wide >>> >>>> coding conventions. It seems that ASF has never had a consistent set of >>>>>> conventions across its many projects, with some choosing an >>>>>> Avalon-like >>>>>> style for braces to avoid the K&R style (with all other syntax >>>>>> >>>>> following >>> >>>> the Sun standard). Other projects adopted other styles. There are many >>>>>> >>>>> to >>> >>>> choose from: Ambler, Lea, ESA (yes, the European Space Agency). Given >>>>>> >>>>> no >>> >>>> one "standard" is without flaws in someone's eyes this is not entirely >>>>>> surprising. While I don't like every bit of it, the one benefit of the >>>>>> >>>>> Sun >>>>> >>>>>> standard is that it is by far the most widely known and practiced, if >>>>>> >>>>> we >>> >>>> aren't too strict in interpretation. >>>>>> >>>>>> I do note one thing clearly expressed on the JSPWikiCodingStandard >>>>>> >>>>> page: >>> >>>> no >>>>> >>>>>> one seemed remotely in agreement about what constitutes "increased >>>>>> readability". It seems what one person thought readable others thought >>>>>> >>>>> not >>>>> >>>>>> so readable. >>>>>> >>>>>> A point you made was that once anyone had checked code into the >>>>>> JSPWiki >>>>>> project it was no longer the domain of the original programmer but >>>>>> >>>>> became >>> >>>> "common code". By the same token, code checked into the Apache JSPWiki >>>>>> project is now the domain of the ASF. Since historically it seems that >>>>>> >>>>> each >>>>> >>>>>> ASF team has chosen its own coding conventions, developers should >>>>>> >>>>> therefore >>>>> >>>>>> follow whatever conventions are chosen for the project by the project >>>>>> >>>>> team, >>>>> >>>>>> which I guess is the question before us. >>>>>> >>>>>> That is, unless someone from ASF has some guidance. >>>>>> >>>>>> Ichiro >>>>>> >>>>>> On Sat, Jul 20, 2013 at 6:47 PM, Janne Jalkanen < >>>>>> >>>>> [email protected]>**wrote: >>>>> >>>>>> Reasoning for style "B", aka K&R is here: >>>>>>> http://ecyrd.com/JSPWiki/wiki/**JSPWikiCodingStandard<http://ecyrd.com/JSPWiki/wiki/JSPWikiCodingStandard> >>>>>>> >>>>>>> I do believe Sun made a mistake going for not aligning the braces - >>>>>>> my >>>>>>> experience is that keeping braces on the same line significantly >>>>>>> >>>>>> increases >>>>> >>>>>> code readability and works better in multi-line conditionals. >>>>>>> >>>>>>> /Janne >>>>>>> >>>>>>> On Jul 20, 2013, at 06:26 , Ichiro Furusato < >>>>>>> >>>>>> [email protected]> >>> >>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>>> >>>>>>>> I'd much prefer Style C as that's the "Sun standard", as you note >>>>>>>> >>>>>>> used >>> >>>> in >>>>> >>>>>> many Apache projects, and the default style of Eclipse's Format >>>>>>>> >>>>>>> command, >>>>> >>>>>> which means that it's easy to auto-format an existing file to match >>>>>>>> >>>>>>> the >>> >>>> Sun >>>>>>> >>>>>>>> standard. Style B is IMO a bit ridiculous -- it extends the logic of >>>>>>>> >>>>>>> a >>> >>>> class vertically across so many lines that it becomes actually hard >>>>>>>> >>>>>>> to >>> >>>> read >>>>>>> >>>>>>>> and the only benefit seems to be increasing the count of lines for >>>>>>>> >>>>>>> those >>>>> >>>>>> who think that's a benefit. But rather than be ambiguous about it, >>>>>>>> >>>>>>> I'd >>> >>>> suggest we simply reference the actual style of "Style B" in >>>>>>>> >>>>>>> JSPWiki's >>> >>>> documentation: >>>>>>>> >>>>>>>> Code Conventions for the Java Programming Language >>>>>>>> >>>>>>>> http://www.oracle.com/**technetwork/java/codeconv-**138413.html<http://www.oracle.com/technetwork/java/codeconv-138413.html>(home >>>>>>>> >>>>>>> page) >>>>>>> >>>>>>>> >>>>>>>> http://www.oracle.com/**technetwork/java/javase/** >>> documentation/codeconvtoc-**136057.html(web<http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html(web> >>> >>>> TOC) >>>>>>>> >>>>>>>> http://www.oracle.com/**technetwork/java/** >>>>> codeconventions-150003.pdf(**PDF)<http://www.oracle.com/technetwork/java/codeconventions-150003.pdf(PDF)> >>>>> >>>>>> I'm not sure where Style B came from in the JSPWiki project, as the >>>>>>>> >>>>>>> Sun >>> >>>> standard has been around for a very long time. >>>>>>>> >>>>>>>> FWIW, all of the code for the Neocortext project (which uses JSPWiki >>>>>>>> >>>>>>> as a >>>>> >>>>>> component) is roughly in the Sun standard (without being anal about >>>>>>>> >>>>>>> it), >>>>> >>>>>> and I'd much prefer to not have to reformat the code for Style B in >>>>>>>> >>>>>>> order >>>>> >>>>>> to submit any portions of it, such as plugins, etc. >>>>>>>> >>>>>>>> So while I don't have a vote, +1 for Style C. >>>>>>>> >>>>>>>> Ichiro >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Jul 20, 2013 at 9:35 AM, Glen Mazza <[email protected]> >>>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Team, the next Sonar complaint, and there's a significant 500 of >>>>>>>>> >>>>>>>> them >>>>> >>>>>> within JSPWiki, is that we're not using braces for single-line >>>>>>>>> >>>>>>>> if/while/for >>>>>>> >>>>>>>> loops. I know for CXF braces are always required, and I suspect the >>>>>>>>> majority of Apache projects today also disallow them, so the >>>>>>>>> >>>>>>>> requirement is >>>>>>> >>>>>>>> not unreasonable. Fixing them is not the problem, what *is* the >>>>>>>>> >>>>>>>> problem is >>>>>>> >>>>>>>> our older-fashioned bracing system, i.e., instead of switching from >>>>>>>>> >>>>>>>> this >>>>> >>>>>> Style A: >>>>>>>>> >>>>>>>>> if (a > b) >>>>>>>>> c = 10; >>>>>>>>> else if (d > e) >>>>>>>>> f = 20; >>>>>>>>> >>>>>>>>> to this (the bracing system JSPWiki presently uses): >>>>>>>>> >>>>>>>>> Style B: >>>>>>>>> >>>>>>>>> if (a > b) >>>>>>>>> { >>>>>>>>> c = 10; >>>>>>>>> } >>>>>>>>> else if (d > e) >>>>>>>>> { >>>>>>>>> f = 20; >>>>>>>>> } >>>>>>>>> >>>>>>>>> I'd like to be doing this instead: >>>>>>>>> >>>>>>>>> Style C: >>>>>>>>> >>>>>>>>> if (a > b) { >>>>>>>>> c = 10; >>>>>>>>> } else if (d > e) { >>>>>>>>> f = 20; >>>>>>>>> } >>>>>>>>> >>>>>>>>> I've checked five major open source projects -- Style C is all they >>>>>>>>> >>>>>>>> use: >>>>> >>>>>> CXF - >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/****cxf/trunk/rt/transports/http/****<http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/http/**> >>> >>>> src/main/java/org/apache/cxf/****transport/https/** >>>>>>>>> CertConstraintsFeature.java?****revision=828758&view=markup< >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/**cxf/trunk/rt/transports/http/** >>> src/main/java/org/apache/cxf/**transport/https/** >>> CertConstraintsFeature.java?**revision=828758&view=markup<http://svn.apache.org/viewvc/cxf/trunk/rt/transports/http/src/main/java/org/apache/cxf/transport/https/CertConstraintsFeature.java?revision=828758&view=markup> >>> >>>> Camel - >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/****camel/trunk/components/camel-****<http://svn.apache.org/viewvc/**camel/trunk/components/camel-**> >>>>> >>>>>> atom/src/main/java/org/apache/****camel/component/atom/** >>>>>>>>> AtomUtils.java?revision=****1190212&view=markup< >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/**camel/trunk/components/camel-** >>> atom/src/main/java/org/apache/**camel/component/atom/** >>> AtomUtils.java?revision=**1190212&view=markup<http://svn.apache.org/viewvc/camel/trunk/components/camel-atom/src/main/java/org/apache/camel/component/atom/AtomUtils.java?revision=1190212&view=markup> >>> >>>> Tomcat - >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/****tomcat/trunk/java/org/apache/****<http://svn.apache.org/viewvc/**tomcat/trunk/java/org/apache/**> >>>>> >>>>>> catalina/filters/FilterBase.****java?revision=1189413&view=**** >>>>>>>>> markup< >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/**tomcat/trunk/java/org/apache/** >>> catalina/filters/FilterBase.**java?revision=1189413&view=**markup<http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/filters/FilterBase.java?revision=1189413&view=markup> >>> >>>> Hadoop - >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/****hadoop/common/trunk/hadoop-**<http://svn.apache.org/viewvc/**hadoop/common/trunk/hadoop-**> >>> >>>> mapreduce-project/hadoop-****mapreduce-client/hadoop-** >>>>>>>>> >>>>>>>>> mapreduce-client-common/src/****main/java/org/apache/hadoop/**** >>> mapred/** >>> >>>> LocalDistributedCacheManager.****java?revision=1466196&view=****markup< >>>>>>>>> >>>>>>>> http://svn.apache.org/viewvc/**hadoop/common/trunk/hadoop-** >>> mapreduce-project/hadoop-**mapreduce-client/hadoop-** >>> mapreduce-client-common/src/**main/java/org/apache/hadoop/**mapred/** >>> LocalDistributedCacheManager.**java?revision=1466196&view=**markup<http://svn.apache.org/viewvc/hadoop/common/trunk/hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-common/src/main/java/org/apache/hadoop/mapred/LocalDistributedCacheManager.java?revision=1466196&view=markup> >>> >>>> Spring Framework: >>>>>>>>> >>>>>>>> https://github.com/****SpringSource/spring-framework/****<https://github.com/**SpringSource/spring-framework/**> >>>>> >>>>>> blob/master/spring-jdbc/src/****main/java/org/springframework/**** >>>>>>>>> jdbc/object/SqlFunction.java< >>>>>>>>> >>>>>>>> https://github.com/**SpringSource/spring-framework/** >>> blob/master/spring-jdbc/src/**main/java/org/springframework/** >>> jdbc/object/SqlFunction.java<https://github.com/SpringSource/spring-framework/blob/master/spring-jdbc/src/main/java/org/springframework/jdbc/object/SqlFunction.java> >>> >>>> Style B might be OK for projects that still allow Style A, but it >>>>>>>>> >>>>>>>> makes >>>>> >>>>>> the code too bloated once Style A is disallowed. I don't think >>>>>>>>> >>>>>>>> we'll >>> >>>> be >>>>> >>>>>> able to attract many committers sticking with Style B anymore. >>>>>>>>> >>>>>>>> Basically, >>>>>>> >>>>>>>> to avoid the busywork of converting Style B to Style C, we'll allow >>>>>>>>> >>>>>>>> either >>>>>>> >>>>>>>> in our source code but with the expectation that more and more code >>>>>>>>> >>>>>>>> will be >>>>>>> >>>>>>>> adopting Style C as time moves on, how does that sound? (Or, do we >>>>>>>>> >>>>>>>> want to >>>>>>> >>>>>>>> continue with allowing Style A and Style B?--we're welcome to ignore >>>>>>>>> >>>>>>>> Sonar >>>>>>> >>>>>>>> on this.) >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Glen >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
