|Re: [ee4j-community] EE4J code conventions?|
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.
On Mon, Apr 9, 2018 at 2:18 PM, Mike Milinkovich <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.