[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ee4j-community] EE4J code conventions?

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 have followed different conventions. Many have established communities and may have strong opinions about this. 

On Apr 9, 2018, at 12:54 PM, Markus KARG <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] 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> 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
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
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