Skip to main content

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

Jason,

There is no  a bunch of different projects that each may have followed different conventions. The only exceptions in the Java EE codebase are CDI and Bean Validation which so far have not even been discussed, if they should end up under EE4J or stay under the JBoss umbrella and simply get used by Jakarta EE distributions.

Everything else got contributed by Oracle who pretty much kept a consistent architecture, coding guidelines or licenses across all of Java EE.

Werner



On Mon, Apr 9, 2018 at 9:46 PM, <ee4j-community-request@xxxxxxxxxxx> wrote:
Send ee4j-community mailing list submissions to
        ee4j-community@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://dev.eclipse.org/mailman/listinfo/ee4j-community
or, via email, send a message with subject or body 'help' to
        ee4j-community-request@eclipse.org

You can reach the person managing the list at
        ee4j-community-owner@eclipse.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of ee4j-community digest..."


Today's Topics:

   1. Re: EE4J code conventions? (Jason Greene)
   2. Re: EE4J code conventions? (arjan tijms)


----------------------------------------------------------------------

Message: 1
Date: Mon, 9 Apr 2018 13:59:03 -0500
From: Jason Greene <jason.greene@xxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] EE4J code conventions?
Message-ID: <227C4D41-1FED-4D7D-B9CB-2FC136E82568@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

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 <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@eclipse.org <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@eclipse-foundation.org <mailto:mike.milinkovich@eclipse-foundation.org>> 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@eclipse.org>
> 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@eclipse.org>
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j-community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180409/378d1804/attachment.html>

------------------------------

Message: 2
Date: Mon, 9 Apr 2018 20:46:27 +0100
From: arjan tijms <arjan.tijms@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] EE4J code conventions?
Message-ID:
        <CAE=-AhA-U81ti2pN5dFbAC+ugxvX1yJ-Q7usCwswr5DpHjJMVA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

On Monday, April 9, 2018, Jason Greene <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?

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 ;)

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> 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@eclipse.org [mailto:ee4j-community-
> bounces@xxxxxxxxxxx <ee4j-community-bounces@eclipse.org>] *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@eclipse-foundation.org> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180409/16135906/attachment.html>

------------------------------

_______________________________________________
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


End of ee4j-community Digest, Vol 8, Issue 46
*********************************************


Back to the top