[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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 have
followed different conventions.
Many have established communities and may have strong opinions about
this.
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.
thanks,
--lukas
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,
Arjan
On 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
