| Re: [ee4j-community] Retaining History for incoming EE4J Projects |
On a similar vein... Are the github issues being transferred over from https://github.com/javaeeto the https://github.com/eclipse-ee4j repos? Many of these projects have open and active github issues. I hope we don't have to recreate these...
--------------------------------------------------- https://www.linkedin.com/in/
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn:kevinwsutter
From: Werner Keil <werner.keil@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Date: 01/16/2018 02:27 PM
Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
Sent by: ee4j-community-bounces@eclipse.org
Mike,
Thanks for the clarification.
As long member of the Java EE EG (since at least EE6) I also know how big the codebase is.
Eclipse Science https://science.eclipse.org/content/eclipse- probably made a very good example about a TLP (like EE4J) doing its own Release Train outside the annual "IDE" centric one in June. In fact a timing like that in October or Fall could work very well if JavaOne stays there. And it also matches roughly when Java EE 8 went Final in 2017.science-2017-simultaneous- release-here
Werner
On Tue, Jan 16, 2018 at 8:39 PM, <ee4j-community-request@eclipse.org > 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: Retaining History for incoming EE4J Projects (Markus KARG)
2. Re: Retaining History for incoming EE4J Projects
(Mike Milinkovich)
3. Re: Feedback to Joint Community Open Letter on Java EE Naming
and Packaging (John Hogan)
------------------------------------------------------------ markus@xxxxxxxxxxxxxxx>----------
Message: 1
Date: Tue, 16 Jan 2018 20:17:14 +0100
From: "Markus KARG" <
To: "'EE4J community discussions'" <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
Projects
Message-ID: <00f901d38efe$a0fb7db0$e2f27910$@eu> ee4j-community-bounces@
Content-Type: text/plain; charset="us-ascii"
Now I am confused even more. So what can commiters like me help with to make
the history being migrated?
-Markus
-----Original Message-----
From:eclipse.org
[mailto:ee4j-community-bounces@xxxxxxxxxxx ] On Behalf Of Mike Milinkovich
Sent: Dienstag, 16. Januar 2018 20:09
To: ee4j-community@xxxxxxxxxxx
Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
None of that is true, and I have no idea what was said that drove you to
that conclusion.
Surely you can recognize that the initial code contribution for projects of
this size and complexity are a bit of a special case.
On 2018-01-16 1:37 PM, Markus KARG wrote:
> So what you actually try to tell us is that Oracle and the EF have to scan
> EACH single commit of the history for legal issues and copyright headers
and
> neither of both parties trusts Oracle that Oracle's licence terms and file
> headers did not change between the history and the LAST commit?
Furthermore
> you want to express that only Oracle and the EMO can do that job but not
the
> newly elected commiters of that projects (which all have signed an
agreement
> to do such checks for each new commit)?
>
> Okay, THEN we (the committers) really cannot help.
>
> -Markus
>
>
> -----Original Message-----
> From: ee4j-community-bounces@eclipse.org
> [mailto:ee4j-community-bounces@xxxxxxxxxxx ] On Behalf Of Mike Milinkovich
> Sent: Montag, 15. Januar 2018 18:51
> To: ee4j-community@xxxxxxxxxxx
> Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
>
> On 2018-01-15 12:40 PM, Markus KARG wrote:
>> If it is not a legal issue, the file headers can stay as they are, and
>> if it is only a time issue,_I_ can fetch and push the commits between
the
> repos.
>> So why not letting me do that?
> Because that's not how it works....
>
> Like every large company we have ever worked with, before Oracle
contributes
> any code to any open source foundation they have a process to follow.
> (Scanning code, reviewing copyright headers, checking license
compatibility,
> etc.)
>
> Before the Eclipse Foundation accepts significant code contributions to
its
> projects, we have a process that we follow. (Scanning code, reviewing
> copyright headers, checking license compatibility, etc.)
>
> As I said: real time, effort, and resources are required to move the
> history.
>
> --
> Mike Milinkovich
> mike.milinkovich@eclipse-foundation.org
> (m) +1.613.220.3223
>
> _______________________________________________ ee4j-community@xxxxxxxxxxx
> ee4j-community mailing list
>
> To change your delivery options, retrieve your password, or unsubscribe
from
> this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
> _______________________________________________ ee4j-community@xxxxxxxxxxx
> ee4j-community mailing list
>
> To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j- community
--
Mike Milinkovich
mike.milinkovich@eclipse-foundation.org
(m) +1.613.220.3223
_______________________________________________
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
------------------------------
Message: 2
Date: Tue, 16 Jan 2018 14:32:50 -0500
From: Mike Milinkovich <mike.milinkovich@eclipse-foundation.org >
To: ee4j-community@xxxxxxxxxxx
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
Projects
Message-ID:
<5262fcba-a53b-5887-cebd-e651959ad9d8@eclipse- >foundation.org
Content-Type: text/plain; charset=utf-8; format=flowed
On 2018-01-16 2:17 PM, Markus KARG wrote:
> Now I am confused even more. So what can commiters like me help with to make
> the history being migrated?
Nothing. Just accept that the history is staying where it is.
I owe you an apology, as I read your initial email too quickly and
misunderstood what you were saying. You were correct the first time:
there is nothing that the committers can do to help move the history
over. The initial code contribution for projects of this size and
complexity are a special case.
> -----Original Message-----
> From: ee4j-community-bounces@eclipse.org
> [mailto:ee4j-community-bounces@xxxxxxxxxxx ] On Behalf Of Mike Milinkovich
> Sent: Dienstag, 16. Januar 2018 20:09
> To: ee4j-community@xxxxxxxxxxx
> Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
>
>
> None of that is true, and I have no idea what was said that drove you to
> that conclusion.
>
> Surely you can recognize that the initial code contribution for projects of
> this size and complexity are a bit of a special case.
>
>
> On 2018-01-16 1:37 PM, Markus KARG wrote:
>> So what you actually try to tell us is that Oracle and the EF have to scan
>> EACH single commit of the history for legal issues and copyright headers
> and
>> neither of both parties trusts Oracle that Oracle's licence terms and file
>> headers did not change between the history and the LAST commit?
> Furthermore
>> you want to express that only Oracle and the EMO can do that job but not
> the
>> newly elected commiters of that projects (which all have signed an
> agreement
>> to do such checks for each new commit)?
>>
>> Okay, THEN we (the committers) really cannot help.
>>
>> -Markus
>>
>>
>> -----Original Message-----
>> From: ee4j-community-bounces@eclipse.org
>> [mailto:ee4j-community-bounces@xxxxxxxxxxx ] On Behalf Of Mike Milinkovich
>> Sent: Montag, 15. Januar 2018 18:51
>> To: ee4j-community@xxxxxxxxxxx
>> Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
>>
>> On 2018-01-15 12:40 PM, Markus KARG wrote:
>>> If it is not a legal issue, the file headers can stay as they are, and
>>> if it is only a time issue,_I_ can fetch and push the commits between
> the
>> repos.
>>> So why not letting me do that?
>> Because that's not how it works....
>>
>> Like every large company we have ever worked with, before Oracle
> contributes
>> any code to any open source foundation they have a process to follow.
>> (Scanning code, reviewing copyright headers, checking license
> compatibility,
>> etc.)
>>
>> Before the Eclipse Foundation accepts significant code contributions to
> its
>> projects, we have a process that we follow. (Scanning code, reviewing
>> copyright headers, checking license compatibility, etc.)
>>
>> As I said: real time, effort, and resources are required to move the
>> history.
>>
>> --
>> Mike Milinkovich
>> mike.milinkovich@eclipse-foundation.org
>> (m) +1.613.220.3223
>>
>> _______________________________________________ ee4j-community@xxxxxxxxxxx
>> ee4j-community mailing list
>>
>> To change your delivery options, retrieve your password, or unsubscribe
> from
>> this list, visit https://dev.eclipse.org/mailman/listinfo/ee4j- community
>>
>> _______________________________________________ ee4j-community@xxxxxxxxxxx
>> ee4j-community mailing list
>>
>> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
--
Mike Milinkovich
mike.milinkovich@eclipse-foundation.org
(m) +1.613.220.3223
------------------------------
Message: 3
Date: Tue, 16 Jan 2018 14:39:35 -0500
From: John Hogan <jhogan515@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Feedback to Joint Community Open Letter
on Java EE Naming and Packaging
Message-ID:
<CAMgrf37YV=aGOSA4vzrPCboHP11t5E-6j-dg1LCgCN1gs+BuFw@mail. >gmail.com
Content-Type: text/plain; charset="utf-8"
Well put Ryan. I totally agree.
On Tue, Jan 16, 2018 at 11:33 AM, Ryan Cuprak <rcuprak@xxxxxxxxx> wrote:
> Hello,
> I just wanted to express my disappointment specifically with the Java EE
> branding. While I applaud the efforts Oracle has been making in donating
> Java EE to the Eclipse Foundation, the lack of brand continuity going
> forward I believe is going to hurt the platform. I disagree that Java EE is
> perceived as being an Oracle technology. From my experience, it perceived
> as a standard with implementations from Oracle, IBM, Apache, etc.
> Ultimately, the confusion over Java EE branding I think will hurt the
> commercial containers (like WebLogic) as Java EE may no longer be viewed as
> a long-term stable platform with a future.
> Transitioning Java EE to new stewards and establishing new processes for
> the platform is a major undertaking. Rebranding is very risky under the
> best of circumstances. I hope that this position will be rethought or
> modified. Maintaining name continuity for at least a couple of years until
> the new process is up and running would go a long way to ensuring the
> success of this platform.
>
> -Ryan
> Connecticut Java Users Group
>
> On Jan 16, 2018, at 10:04 AM, will.lyons@xxxxxxxxxxwrote:
>
> Hello -
>
> Reza Rahman has recently posted a Joint Community Open Letter on Java EE
> Naming and Packaging
> <https://javaee-guardians.io/2018/01/02/joint-community- >.open-letter-on-java-ee-naming- and-packaging/
> Our feedback is given below - most of it is context explaining our
> direction. We hope it is helpful.
>
> Oracle has previously communicated that it intends to work with the EE4J
> community to:
> 1) Define a branding strategy for the platform, including a new name for
> Java EE to be determined.
> 2) Enable use of existing javax package names, and enable extension of
> existing javax namespaces (e.g. javax.servlet.*) to enable compatibility
> and evolution of existing APIs.
> 3) Use a different namespace naming convention, i.e. different from
> ?javax.*?, for net new APIs/technologies.
>
> Note that doing the above remains work in process, but it remains our
> intent.
>
> The open letter requests that Oracle and other EE4J stakeholders work
> together:
> 1) To allow the new platform to retain the Java EE name
> 2) To allow use of existing ?javax? packages for existing technologies
> 3) To allow use of the ?javax.enterprise? package for new technologies
>
> Oracle has already expressed its intent to do what is requested in point
> #2 above. This would allow for compatibility between EE4J releases and
> existing Java EE releases at the package level. We will focus on points
> #1 and #3 below. Why not allow use of the Java EE name, and why not allow
> use of the javax.enterprise namespace for all new EE4J technologies?
>
> The industry has changed since the Java EE development process was
> originally created. The process was not seen as being nimble, flexible or
> open enough. Our shared goal is to create a more nimble process, with more
> flexible licensing, and more open governance that is not dependent on a
> single vendor. We believe this will encourage more participation and
> innovation. We see general support for this new direction from across the
> community.
>
> This new direction implies many changes, starting with a change in the
> technology development process. The Java EE process, or to be more
> specific, the JCP process that was used for Java EE development, is a
> highly structured process that grants specification leads significant
> influence over how technologies are specified and implemented. The EE4J
> process will be different. It will be more open. Single vendors including
> Oracle will continue to contribute, but will no longer have the same level
> of influence over how new EE4J technologies evolve. We believe there is
> consensus that this is a positive step for the community.
>
> This new development process drives choices around use of the Java EE
> name, and use of the javax.* package names for new technologies. The Java
> EE and javax.* names leverage the Java trademark, and indicate that the
> source of these technologies is Oracle and community processes managed by
> Oracle. As a critical identifier of the source of products to our users, we
> must continue to reserve use of such names using the Java trademark to
> serving that fundamental source identifying function. This will help us to
> maintain the Java trademark, which is in Oracle?s interest and in the
> community?s interest. We recognize there are likely to be requirements to
> create new versions of existing Java EE specifications that were already
> created using the existing JCP process. We believe we can work out an
> approach to allow use of javax.* names for extensions to these existing
> specifications in order to accommodate these requirements. However, if we
> adopt a new process for new EE4J technologies, as is desired by the
> community, we believe we must require that a new namespace be used for the
> new EE4J technologies that are developed using that process, and a new
> brand (other than Java EE) that includes these new technologies. There is
> a tradeoff here, and we believe that the net benefit of the new process
> warrants the adoption of a new namespace for new EE4J technologies, and a
> new brand.
>
> We will work with the EE4J community to mitigate continuity concerns that
> accompany this change. We are making it very clear that EE4J will be an
> evolution of existing Java EE 8 technologies:
> ? We are contributing our existing GlassFish Java EE 8 Reference
> Implementation sources to EE4J.
> ? We will contribute our existing TCKs.
> ? We are intending to allow certain uses of existing javax packages as
> those packages evolve for compatibility.
> ? We are intending to allow use of existing specification names for
> component specifications.
> ? We are building an initial EE4J implementation that is intended to be
> both Java EE 8 and ?EE4J? compatible.
> ? We will work with the EE4J community to promote the new brand.
>
> These are positive steps we can take.
>
> We support the efforts of the EE4J Project Management Committee to make
> branding recommendations to the Eclipse Foundation. We encourage the
> community to support the effort as well, and extend thanks to all for the
> continued interest in Java EE and EE4J technologies. And we hope to
> deliver soon more new projects with GlassFish sources contributed to EE4J!
>
> Thanks
>
> Will
>
> _______________________________________________ ee4j-community@xxxxxxxxxxx
> ee4j-community mailing list
>
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ee4j- community
>
>
>
> _______________________________________________ ee4j-community@xxxxxxxxxxx
> ee4j-community mailing list
>
> 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/ 20180116/3855632a/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 5, Issue 45
*********************************************
_______________________________________________ https://urldefense.proofpoint.
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visitcom/v2/url?u=https-3A__dev. eclipse.org_mailman_listinfo_ ee4j-2Dcommunity&d=DwICAg&c= jf_iaSHvJObTbx-siA1ZOg&r= R9dtOS3afYnRUmu_ zogmh0VnVYl2tse_V7QBUA9yr_4&m= kbRoPfn3w_eigsqqLn_ 5MsCJCYP1ODAcMjnouYGlZ7Y&s= Wdv8QjJDVEypuaM2MyQNzB7- QuheLmJ5rYdgqC3o_XM&e=
_______________________________________________
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