[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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-ee4jrepos? Many of these projects have open and active github issues.
I hope we don't have to recreate these...
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Java EE architect
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutterFrom:
Werner Keil <werner.keil@xxxxxxxxx>To:
EE4J community discussions
<ee4j-community@xxxxxxxxxxx>Date:
01/16/2018 02:27 PMSubject:
Re: [ee4j-community]
Retaining History for incoming EE4J ProjectsSent by:
ee4j-community-bounces@xxxxxxxxxxx
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-science-2017-simultaneous-release-hereprobably 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.Werner
On Tue, Jan 16, 2018 at 8:39 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@xxxxxxxxxxx
You can reach the person managing the list at
ee4j-community-owner@xxxxxxxxxxx
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)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Jan 2018 20:17:14 +0100
From: "Markus KARG" <markus@xxxxxxxxxxxxxxx>
To: "'EE4J community discussions'" <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
Projects
Message-ID: <00f901d38efe$a0fb7db0$e2f27910$@eu>
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: ee4j-community-bounces@xxxxxxxxxxx
[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@xxxxxxxxxxx
> [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@xxxxxxxxxxxxxxxxxxxxxx
> (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
>
> _______________________________________________
> 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
--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(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@xxxxxxxxxxxxxxxxxxxxxx>
To: ee4j-community@xxxxxxxxxxx
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
Projects
Message-ID:
<5262fcba-a53b-5887-cebd-e651959ad9d8@xxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx
> [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@xxxxxxxxxxx
>> [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@xxxxxxxxxxxxxxxxxxxxxx
>> (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
>>
>> _______________________________________________
>> 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
>
--
Mike Milinkovich
mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
(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@xxxxxxxxxxxxxx>
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 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/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
*********************************************
_______________________________________________
ee4j-community mailing list
ee4j-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://urldefense.proofpoint.com/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=