On Tue, Jul 16, 2013 at 6:26 PM, Lennart Jörelid <lennart.jore...@gmail.com>wrote:
> This is not (or should not be) an entirely technical question - support for > various versions of JDK may be the simpler criterion to discuss, but I feel > the more relevant question is > > "Do we first and foremost see small-scale projects [small organisations] or > enterprise-scale projects [enterprise-scale organisations] as the > recipients of what we build?" > > I think that the premise of the question is utterly wrong! It is not an "OR" question. The fact is that we do, and need too, cater for both! It's an "AND". > In the former case, we are at liberty to cut support for older JDK versions > and trust in the more modern toolchain and vice versa. While some > long-standing problems with newer JDKs (like retina support for JDK 7 on > Macs, proper font support for JDK on Linux, or sluggishness of JEE > container upgrades for example) can certainly hinder or prevent upgrading > the toolchain, to what extent do you believe these problems to be relevant > for small-scale projects and enterprise-scale projects respectively? > > In my experience, the upgrade speed of ASF / Codehaus / Eclipse (which > manufacture the toolchains that pretty much everyone uses) is one of the > major factors in determining the upgrade speed of most projects out there. > Quite few players are willing to pay the cost to sculpt their development > process and toolchain entirely from their own needs. > > In the enterprise space, from what I've seen, it's comes down to one thing: COST. If the existing solution works, then it tends to stay put. As upgrading costs, hugely! The best example that I can think of is that the latest (or later?) of one of the Tivoli products (TIM or TAM) still sits on top of WAS 6.1 (which is EOL) but, as it's embedded into TIM/TAM it is a restricted use, sort of, so it is still supported. My point here is that it is not the specifics of the technology involved (how new or old it is) rather it is the function performed. That is what the enterprise space looks at, they generally do not care how it's done, they just want the job done. I will also be the first to admit, that as things get leaner, and/or start to move to the cloud, that the technology used is getting a better look in. However, with embedded produts, I can not see that changing too much at all. In the open source space, sure, feel free to let the OS stuff lead, as it does eventually find it's way into the corporate space. IMHO it would be good to upgrade to a JDK 7 based chain, for reasons of > both technology, customer affinity and open source society progress - but > there are certainly valid opinions for other choices as well. > > > 2013/7/16 Mirko Friedenhagen <mfriedenha...@gmail.com> > > > I would prefer going from JDK5 to 7 immediately as well, old JDK means > > usage of old tools. > > > > Regards Mirko > > -- > > Sent from my mobile > > On Jul 16, 2013 7:07 AM, "Stephen Connolly" < > > stephen.alan.conno...@gmail.com> > > wrote: > > > > > So what I am hearing is that until we bump core to require JDK6 (or 7) > > then > > > logback is the only runner from a technical point of view (never mind > > that > > > log4j2 is still not GA) > > > > > > OTOH I would be interested in bumping JDK all the way to 7 if we were > > happy > > > that toolchains is good enough and we had tests in play that use > > toolchains > > > > > > On Tuesday, 16 July 2013, Arnaud Héritier wrote: > > > > > > > Hi > > > > > > > > FYI I rebased both branches on current master : > > > > * > > > > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/slf4j-log4j2 > > > > * > > > > > > > > > > > > > > https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/slf4j-logback > > > > With all work done by Herve both branches have only one interesting > > > commit > > > > to update few deps. > > > > > > > > If you want to test them I shared some archives : > > > > * > > > > > > > > > > > > > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-log4j2-bin.tar.gz > > > > * > > > > > > > > > > > > > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-log4j2-bin.zip > > > > * > > > > > > > > > > > > > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-logback-bin.tar.gz > > > > * > > > > > > > > > > > > > > https://dl.dropboxusercontent.com/u/501043/apache-maven-3.2-SNAPSHOT-logback-bin.zip > > > > (You just have to replace the non-color config file in conf/logging > by > > > the > > > > -color one) > > > > > > > > LOG4J2 has 2 issues : > > > > ** It requires Java 6 (while our core is always requiring Java 5 for > > > now) > > > > ** beta 7 and beta 8 aren't supporting some methods we used in our > > > > integration : > > > > [WARNING] setRootLoggerLevel: operation not supported > > > > [WARNING] reset(): operation not supported > > > > > > > > Cheers > > > > > > > > ----- > > > > Arnaud Héritier > > > > http://aheritier.net > > > > Mail/GTalk: aheritier AT gmail DOT com > > > > Twitter/Skype : aheritier > > > > > > > > > > > > > -- > > > Sent from my phone > > > > > > > > > -- > > -- > +==============================+ > | Bästa hälsningar, > | [sw. "Best regards"] > | > | Lennart Jörelid > | EAI Architect & Integrator > | > | jGuru Europe AB > | Mölnlycke - Kista > | > | Email: l...@jguru.se > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==============================+ >
