|Re: [ee4j-community] EE4J code conventions?|
On 4/9/18 9:46 PM, arjan tijms wrote:
Hi,On Monday, April 9, 2018, Jason Greene <jason.greene@xxxxxxxxxx <mailto:jason.greene@xxxxxxxxxx>> wrote:The other factor to keep in mind is there is going to be gigantic source import from a bunch of different projects that each may havefollowed different conventions.Many have established communities and may have strong opinions aboutthis.You are right that if it would be totally different projects from different origins that would be a major issue, but in this case aren’t all the transferred projects the RI projects from Oracle?
yes and no. EclipseLink while being among those being transferred is under EF control since 2007 and its roots dates back to 1996 (if we are talking only about its Java version), with Oracle and IBM being most active committers there during last say ~5 years
They already have essentially the Sun/Eclipse conventions with spaces. At least, as far as I know not a single one of the former Oracle projects use tabs. One project that does uses tabs is OmniFaces btw ;)
there were parts which were using Tabs; there were also files which were using mixed line-endings (yeah believe it or not there really were files where some lines ended with LF and others with CR/LF - don't ask me how that could happen) - both of these "issues" were "fixed" few years ago and that was the only (history destructive) code-formatting change we were willing to make.
One important thing to note is that the proposal in the opening post is just that, a proposal. The idea was that a convention would be established by committers from all EE4J modules (projects), which however are not rarely the same people.Kind regards, ArjanOn Apr 9, 2018, at 12:54 PM, Markus KARG <markus@xxxxxxxxxxxxxxx <mailto:markus@xxxxxxxxxxxxxxx>> wrote: You assumption is wrong. The open source project is not EE4J. EE4J is only a common organization within the EF, and the projects are self-governing. Believe Mike, he should know best… ;-)____ __ __ BTW, I am contributing to dozens of open source projects, none of them share formatting rules, and never had a problem with that. ;-)____ __ __ Anyways, the PMC will be wise enough to decide.____ __ __ -Markus____ __ __ __ __ *From:*ee4j-community-bounces@xxxxxxxxxxx <mailto:ee4j-community-bounces@xxxxxxxxxxx> [mailto:ee4j-community-bounces@xxxxxxxxxxx <mailto:ee4j-community-bounces@xxxxxxxxxxx>] *On Behalf Of *arjan tijms *Sent:* Montag, 9. April 2018 16:42 *To:* EE4J community discussions *Subject:* Re: [ee4j-community] EE4J code conventions?____ __ __ Hi,____ __ __ On Mon, Apr 9, 2018 at 2:18 PM, Mike Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx <mailto:mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>> wrote:____ Because Eclipse Foundation open source projects are self-governing meritocracies, and we don't tell them what to do. Ultimately, it is the committers who would need to do the work, and I don't think any of us get to tell them how to spend their time. ____ __ __ I can see that, but in this case the open source project would be EE4J, with all the concrete projects being sub-projects of that, not totally independent projects.____ __ __ I know it's not totally the same, but suppose that in Mojarra I'm responsible for the component package, while say Bauke works on the websocket package. Naturally we'd want a single code convention for Mojarra, not one per package.____ __ __ Now when seeing EE4J as one project, the question might be whether it really makes sense to have separate code conventions per 'module', but I guess it also depends on how much one sees EE4J as 1 framework, or more as a set of somewhat cobbled together independent projects. I personally would lean more to the former, but I know historically it has been more of the latter.____ __ __ There is the issue though that in EE4J we do have an amount of committers that are active on many EE4J projects, and the Jakarta EE/Eclipse process might make that easier than before with Java EE and the JCP.____ __ __ For those people specifically it would perhaps not be entirely optimal having to change between conventions all the time, say if Mojarra decided to got for tabs, but Soteria would go for spaces. It also would make building and sharing build knowledge more difficult if for example Mojarra switched over the Gradle, but Soteria kept using Maven, and then Jersey switched over to Ant, with Grizzly going to Make.____ __ __ Kind regards,____ Arjan____ __ __ __ __ __ __ __ __ __ __ __ __ ____ I'm not saying that this is an unreasonable idea. But generally speaking open source projects don't respond well to being ordered about. Ivar has already said that he'll raise it with the PMC. Let's wait and see how that plays out. ____ _______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community <https://dev.eclipse.org/mailman/listinfo/ee4j-community>____ __ __ _______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxx <mailto:ee4j-community@xxxxxxxxxxx> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community <https://dev.eclipse.org/mailman/listinfo/ee4j-community>_______________________________________________ ee4j-community mailing list ee4j-community@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j-community
Back to the top