Re: [jakartaee-platform-dev] Updating 3rd party dependencies to jakarta

["Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>]

Thanks do we need this for milestones and RCs distributed via staging?

 

From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Wayne Beaton
Sent: 20 May 2020 17:10
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: EMO EMO <emo@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Updating 3rd party dependencies to jakarta

 

Confirmed.

 

Since the project would be distributing modified binary artifacts, you'd need to create a CQ to track each. The IP Team won't engage in a review of the otherwise already approved content. FWIW, the primary concern is that we'd be distributing the modified binary artifact, so we'd need the CQ regardless of whether they are modified on the fly during build or modified versions are placed in some repository.

 

Wayne

 

On Wed, May 20, 2020 at 11:25 AM Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> wrote:

You always have my attention, Kevin.

 

We may need CQs to track that we're distributing modified binaries. I'll confirm with the IP Team.

 

Finding a home for the modified binaries is probably the biggest challenge. Eclipse Orbit is specifically for "bundlized" JARs (i.e., adding OSGi metadata), so it's probably not the right place... Perhaps they can go in nexus.eclipse.org? Just putting them in a Git repo also works.

 

Wayne

 

 

On Wed, May 20, 2020 at 8:42 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:

Wayne,
Since we have your attention, could you entertain the other scenario as well?  What if we wanted to use the Eclipse Transformer to modify a 3rd party dependency jar file from `javax` to `jakarta`, and then wanted to store this modified binary in some accessible repo?  Either a github repo or possibly something like Eclipse Orbit?  Would this type of storage of modified 3rd party jar files need any special IP clearances?

FYI, I know this type of modification could be done exclusively at build time and just brought into the resulting Project binaries -- that is, no need for a storage in a repo.  But, if these are common 3rd party dependencies, then it might be more efficient to just run the Transformer once, store the results, and let others benefit from them.

Thanks for your insights!

---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        "Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:        05/20/2020 05:04
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] Updating 3rd party dependencies        to        jakarta
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx

---

 

Thanks Wayne.

 

Essentially these would hopefully be temporary forks needed to get a release of GlassFish and therefore Jakarta EE 9 out of the door without being dependent on persuading upstream projects out of our control to adopt and make a new release in the Jakarta EE 9 namespace.

 

I will pick up with you on the each individual dependency and our approach to managing it.

 

Steve

 

From:jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Wayne Beaton
Sent: 20 May 2020 05:04
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Updating 3rd party dependencies to jakarta

 

Ideally, the owners of these code bases will make and maintain the updates. Or at very least accept your contributions. From the perspective of the Eclipse IP Policy, the resulting libraries would then be new versions of existing third party dependencies and subject to IP review/vetting.

 

If you do end up needing to create a fork of anything at the Eclipse Foundation, the nature of the dependency changes from being third party to (effectively) being project code and so further due diligence may be required. Check in with the IP Team before you start forking repositories.

 

My recommendation is to first get a sense of what you need to do technically, and I'll help you sort out the best way forward with respect to the IP Policy.

 

Wayne

 

On Mon, May 18, 2020 at 7:15 AM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Hi All,

 

On the Eclipse Glassfish project we have found a number of external 3^rdparty dependencies that need updating to the new namespace before we can release GlassFish 6. For example Apache Commons File Upload and Jackson and likely others as we get closer to release. Can anybody advise on how we should go about modifying and shipping these components both from a preferred technical approach and from an IP/CQ perspective?

 

Thanks

 

Steve

 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020- October 20-22_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020 - October 20-22

 

--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.

Join us at our virtual event: EclipseCon 2020 - October 20-22