Also, I believe the CQ process, in this scenario, should be invoked on demand i.e. only when an Eclipse project explicitly declares an external dependency on older version - JSONPv1.0 which is in the JavaEE repository. If we were to begin to sanitize every tag in the JavaEE JSONP repository for the sake of incorporating history, I believe, it would not be an efficient utilization of time and resources given the cost and benefits, assuming most of the tags would never be used again. Now imagine retriggering the CQ process at EF every time a MR is published there. Keeping the existing JavaEE repository-as-is would serve the same purpose and ease the responsibility and load on the EF. But for current versions of EE4J projects, just like other official Eclipse projects, it needn’t have to take the same process flow that is mandatory for vetting external dependencies if an existing/new Eclipse project were to depend on it. So, I think it makes sense to have it the way it is now (i.e. to exclude history). This will definitely speed up the process of incorporating more JavaEE projects into the EE4J umbrella without shadowing any initial contributions (so long as the existing repositories are maintained/archived by the respective owners). -Mrinal Werner, are you clear on my stand with the topic of this thread? JSONP is just an hypothetical example that I used to explain the scenario; and I believe the link you provided is only accessible to existing committers or requires more privileges than an ordinary Eclipse account (that I have). -Mrinal Please check IPZilla for those kinds of things. https://dev.eclipse.org/ipzilla/show_bug.cgi?id=13739 is the ticket for javax.json-api 1.0 Should Eclipse MicroProfile or other Eclipse projects wish to use javax.json-api 1.1 or above, then it'll need new/updated CQs. On Mon, Jan 15, 2018 at 9:54 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 (Mrinal Kanti M)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Jan 2018 02:24:50 +0530
From: Mrinal Kanti M <mrinal.kanti@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
Projects
Message-ID: <5a5d151b.0667620a.bdc4.1bd2@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Werner,
With respect to JSONP, I see that the existing JavaEE repository at GH also has tags for jsonp-1.1 and json-1.0 which I assume, are implementations of two different JSRs. In the current scenario only the latest code would be have been imported after vetting. Hypothetically speaking, in the current scenario, if a Eclipse plugin developer (say, for a JSON editor) decides to incorporate both JSONP versions then he can safely ship JSONPv1.1 in his plugin and provide a mechanism for the end user to download the JSONPv1.0 from maven or from developer?s own hosted P2 repository. EF would be safe here as the JSONPv1.0 code is not published by EF.
But if the JSONPv1.0 code is incorporated into the EE4J repository without vetting then the plugin developer remains free to build JSONPv1.0 plugin jars from the EE4J repository and ship it as part of his plugin which could become an official Eclipse release. Now you see the issue?
Therefore, I believe that the history also needs to be vetted for licensing/copyright.
-Mrinal
From: Werner Keil
Sent: 16 January 2018 01:52
To: EE4J community discussions
Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
Mrinal,
I am not aware of such fancy build-scripts.
A POM like that of JSONP:?https://github.com/eclipse-ee4j/jsonp/blob/master/pom.xml (which I know by being a committer ever since the first JSON-P standard)? shows the SCM:?scm:git:git://github.com/eclipse-ee4j/jsonp.git
And there is no "outside" or pre EE4J source code repository that would get used by that Maven build script. All the other dependencies are Maven binaries.?
Eclipse IP checks have been done for all of these binaries to ensure, a CQ exists and the library may be used under Eclipse. JCache 1.0 is not legitimate to use there ;-) So while Spring does not care and seems to use it already, EE4J has to wait till at least the MR1 got accepted by? a CQ.
Werner
On Mon, Jan 15, 2018 at 9:10 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 (Mrinal Kanti M)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Jan 2018 01:40:50 +0530
From: Mrinal Kanti M <mrinal.kanti@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
? ? ? ? Projects
Message-ID: <5a5d0acb.8d12620a.b961.1b09@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
@Werner
As long as there are binary dependencies which are resolved from an external repository then there is no concern. But if the EE4J build scripts check out and pack any old (unmodified) files using old tags from the EE4J repository during the release process, then I believe, we have a problem if those files are not cleared for license/copyright.
@Mariano
Think of something like Spring Boot or the microprofile with release sources. It should not be difficult to imagine scenarios where a new functionality needs to be supported for older JavaEE versions not in the EE4J repository. Sure, one can pull those dependencies as binaries using maven which should be perfectly permissible. But if the old unvetted versions are present in the EE4J repository, then it would also be technically possible for EE4J developer to use a build script that checks out old tags from EE4J repository for the same dependencies, wherein the issue lies.
In the former scenario, EF may choose not incorporate the dependencies in its official releases as there is a clear segregation. But in the later case, the dependencies ?can? become part of an official EE4J release and it would be difficult to ?enforce? any repository-wide policy that old tags are not retrieved while making and publishing new releases.
Also, we need to remember that EE4J projects can be used outside the EE4J umbrella (such as tool development). And those tools may need to support older JavaEE versions. Which makes it more challenging to enforce that other Eclipse projects outside EE4J umbrella do not rely on old tags from the EE4J repository.
-Mrinal
From: Werner Keil
Sent: 16 January 2018 01:00
To: EE4J community discussions
Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
Hi,
Of course there are dependencies "pre EE4J" but all I could imagine are BINARY dependencies in Maven repositories like MavenCentral, JCenter or similar.
Those exist ever since. Even java.net still exists and may do so for some time in the Maven repository context.?
The average EE developer would rarely have to check out any of these APIs like Servlet, Security API, JSON-P, JPA or others from the source and "patch" them in their environment. That would contradict compatibility, or is there a use case you can tell us more about?
Werner
On Mon, Jan 15, 2018 at 8:18 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 (Mrinal Kanti M)
? ?2. Re: Retaining History for incoming EE4J Projects (Mariano Amar)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Jan 2018 00:32:09 +0530
From: Mrinal Kanti M <mrinal.kanti@xxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
? ? ? ? Projects
Message-ID: <5a5cfab2.c496620a.c94d3.1255@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
David,
I am referring to resolving dependencies of older versions from the new EE4J repository instead of resolving those dependencies from the existing projects at the JavaEE repository (or through maven). AFAIK, the absence of the entire history in the EE4J repository is the concern here. If the existing JavaEE repositories are left as is and the old dependencies continue to get resolved from the existing JavaEE repository then, I believe,? it is not under the scope of the EF.
On the other hand, it would be very cumbersome to review each and every ?unmodified? dependent file every time for copyright/license during every release from the EE4J repository, especially for those old versions of files that belong to existing (imported into EE4J repo) projects which are not directly part of the release. Making old code current would only be applicable if there are any changes/modifications made to the old versions (which is not likely). I am referring to the scenario where there is a future release which is published from the EE4J repository with a dependency on the old code here.
-Mrinal
From: David Lloyd
Sent: 15 January 2018 23:43
To: EE4J community discussions
Subject: Re: [ee4j-community] Retaining History for incoming EE4J Projects
I believe this is inaccurate.? Anyone can declare a dependency on an
older version of the code already as the entire history is already
published.? In order to bring old code to be current, it would have to
be reviewed in the same manner as any other change.? So again, AFAICT
there is no real legal issue here.
On Mon, Jan 15, 2018 at 12:06 PM, Mrinal Kanti M <mrinal.kanti@xxxxxxxxx> wrote:
> I think Mike has a point here. If the due diligence is not done then it
> would be technically possible for someone (in future) to make a release
> (say, for the sake of maintenance) by declaring a dependency on an older
> version of the code. And since the older version is not completely vetted,
> the release might end up having license/copyright issues.
>
>
>
> Besides, I have some bandwidth to spare. If its purely a time, effort or
> resource issue then I think it would be a good opportunity to call for
> volunteers from the community and see if the existing teams can be augmented
> to meet the resource demands during this transition process.
>
>
>
> -Mrinal
>
>
>
> P.S. I have already accepted the ECA and do not anticipate any issues in
> getting other relevant paperwork processed.
>
>
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Mike Milinkovich
> Sent: 15 January 2018 23:21
> 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
>
--
- DML
_______________________________________________
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/0ece1edd/attachment.html>
------------------------------
Message: 2
Date: Mon, 15 Jan 2018 16:18:32 -0300
From: Mariano Amar <mariano.amar@xxxxxxxxxx>
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Retaining History for incoming EE4J
? ? ? ? Projects
Message-ID:
? ? ? ? <CAJauv3RGh8yB24OTCja4ZSsYpcKg0DH3Ef44PL+=zZjgAQM+_Q@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
Mrinai,
Could you give a good (hypothetical) example of how we could have a release
published from EE4J that somehow has dependencies to code from before EE4J?
Maybe if we could have more concrete issues to talk about, we might be able
to handle this issue without losing too much time.
- Mariano
* <http://www.wes-it.com/>*
*Mariano Amar*
*Senior Consultant*
*email/hangouts:* mariano.amar@xxxxxxxxxx <franco.guarnieri@xxxxxxxxxx>
*skype:* marianoamar
www.wes-it.com
AVISO DE CONFIDENCIALIDAD DE CORREO ELECTR?NICO
Esta comunicaci?n contiene informaci?n que es confidencial y tambi?n puede
contener informaci?n privilegiada. Es para uso exclusivo del destinatario.
Si usted no es el destinatario tenga en cuenta que cualquier distribuci?n,
copia o uso de esta comunicaci?n o la informaci?n que contiene est?
estrictamente prohibida. Si usted ha recibido esta comunicaci?n por error
por favor notif?quelo por correo electr?nico(info@xxxxxxxxxx) o por
tel?fono (+54 11 3249 7503)
This communication contains information that is confidential and may also
be privileged. It is for the exclusive use of the recipient. If you are not
the intended note that any distribution, copying or use of this
communication or the information it contains is strictly prohibited. If you
have received this communication in error please notify us by email(
info@xxxxxxxxxx) or phone (+54 11 3249 7503)
On Mon, Jan 15, 2018 at 4:02 PM, Mrinal Kanti M <mrinal.kanti@xxxxxxxxx>
wrote:
> David,
>
>
>
> I am referring to resolving dependencies of older versions from the new
> EE4J repository instead of resolving those dependencies from the existing
> projects at the JavaEE repository (or through maven). AFAIK, the absence of
> the entire history in the EE4J repository is the concern here. If the
> existing JavaEE repositories are left as is and the old dependencies
> continue to get resolved from the existing JavaEE repository then, I
> believe,? it is not under the scope of the EF.
>
>
>
> On the other hand, it would be very cumbersome to review each and every
> ?unmodified? dependent file every time for copyright/license during every
> release from the EE4J repository, especially for those old versions of
> files that belong to existing (imported into EE4J repo) projects which are
> not directly part of the release. Making old code current would only be
> applicable if there are any changes/modifications made to the old versions
> (which is not likely). I am referring to the scenario where there is a
> future release which is published from the EE4J repository with a
> dependency on the old code here.
>
>
>
> -Mrinal
>
>
>
> *From: *David Lloyd <david.lloyd@xxxxxxxxxx>
> *Sent: *15 January 2018 23:43
> *To: *EE4J community discussions <ee4j-community@xxxxxxxxxxx>
>
> *Subject: *Re: [ee4j-community] Retaining History for incoming EE4J
> Projects
>
>
>
> I believe this is inaccurate.? Anyone can declare a dependency on an
>
> older version of the code already as the entire history is already
>
> published.? In order to bring old code to be current, it would have to
>
> be reviewed in the same manner as any other change.? So again, AFAICT
>
> there is no real legal issue here.
>
>
>
> On Mon, Jan 15, 2018 at 12:06 PM, Mrinal Kanti M <mrinal.kanti@xxxxxxxxx>
> wrote:
>
> > I think Mike has a point here. If the due diligence is not done then it
>
> > would be technically possible for someone (in future) to make a release
>
> > (say, for the sake of maintenance) by declaring a dependency on an older
>
> > version of the code. And since the older version is not completely
> vetted,
>
> > the release might end up having license/copyright issues.
>
> >
>
> >
>
> >
>
> > Besides, I have some bandwidth to spare. If its purely a time, effort or
>
> > resource issue then I think it would be a good opportunity to call for
>
> > volunteers from the community and see if the existing teams can be
> augmented
>
> > to meet the resource demands during this transition process.
>
> >
>
> >
>
> >
>
> > -Mrinal
>
> >
>
> >
>
> >
>
> > P.S. I have already accepted the ECA and do not anticipate any issues in
>
> > getting other relevant paperwork processed.
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > Sent from Mail for Windows 10
>
> >
>
> >
>
> >
>
> > From: Mike Milinkovich
>
> > Sent: 15 January 2018 23:21
>
> > 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
>
> >
>
>
>
>
>
>
>
> --
>
> - DML
>
> _______________________________________________
>
> 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/20180115/5a831afd/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 29
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180116/acb1df74/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 31
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://dev.eclipse.org/mailman/private/ee4j-community/attachments/20180116/daec4f58/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 33
*********************************************
|
