The plan is to migrate the issues, we just haven't gotten to it
yet.
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/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@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=
_______________________________________________
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
