Skip to main content

[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/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=




Back to the top