|Re: [eclipse.org-architecture-council] [Fwd: Re: Swordfish Release, Missing CQs]|
Sorry. Wrong list. Architecture council, please disregard. Wayne Wayne Beaton wrote:
I am resending as my original note was put into a holding pattern... -------- Original Message -------- Hello Planning Council.It has been determined that the Swordfish project has included several third party libraries in their downloads, their update site, and the Galileo Update site that have not been taken through the Eclipse IP Due Diligence process. The full list of problems is copied below.I have been informed by the IP Team that they cannot reasonably complete the ten reviews suggested by Oliver by Friday.This leaves us with an IP exposure in the Galileo Update site that we need to mitigate. I believe that the Galileo update site will need to be respun, excluding Swordfish. I understand that this is no simple chore and that it will require effort from many of us to complete. I assume, for example, that the testing effort will be non-trivial.I am seeking your guidance on how we can proceed.I further request that the Planning Council initiate a conversation with Swordfish on how best to move forward once the IP issues have been resolved.Thanks, Wayne Barb Cochrane wrote:Hi Oliver,It's hard for us to predict whether we're going to be able to clarify IP for any given package. The best thing to do would be to start entering the CQs (attaching just the jars you require to each) so we can start to assess the packages on a case by case basis. Thanks!Barb -----Original Message-----From: Oliver Wolf [mailto:oliver.wolf@xxxxxxxxx] Sent: Monday, June 29, 2009 12:05 PMTo: Runtime Project PMC mailing list; Wayne Beaton; Eclipse Management Organization; emo-ip-team@xxxxxxxxxxx Cc: Zsolt Beothy-Elo; Dietmar Wolz; Jürgen Kindler Subject: Swordfish Release, Missing CQs Dear RT PMC members, EMO, and IP team,The Swordfish project has finalized the in-depth analysis of missing or notmatching CQs. These are our findings: 1. Third party libs w/o CQ -------------------------- org.apache.servicemix.document_1.0.0.v200906161300.jar servicemixcommon_2009.1.0.v200906161300.jar servicemixhttp_2009.1.0.v200906161300.jar servicemixsoap2_2009.1.0.v200906161300.jar servicemixsoap_2009.1.0.v200906161300.jar servicemixutils_1.1.0.v200906161300.jar net.sf.cglib_2.1.3.v200906161300.jar org.apache.axiom_1.2.5.v200906161300.jar org.apache.servicemix.cxf.binding.nmr_4.0.0.v200906161300.jar org.apache.servicemix.cxf.transport.nmr_4.0.0.v200906161300.jar org.apache.servicemix.cxf.transport.osgi_4.0.0.v200906161300.jar org.apache.xbean.xbean.spring_3.5.0.v200906161300.jar org.codehaus.stax2_3.2.7.v200906161300.jar org.jvnet.staxex_1.0.0.v200906161300.jar org.objectweb.howl_22.214.171.124_v200906161300.jar Of these, the following ones have been unnecessarily included and can be removed without any impact on functionality: org.codehaus.stax2_3.2.7.v200906161300.jar org.jvnet.staxex_1.0.0.v200906161300.jar org.objectweb.howl_126.96.36.199_v200906161300.jar net.sf.cglib_2.1.3.v200906161300.jar Of the remaining ones, one has previously been approved for use within Eclipse: org.apache.axiom_1.2.5.v200906161300.jarThis leaves us with 10 jars for which new CQs would have to be filed (all ofthem Apache2-licensed, hosted at Apache and relatively small): org.apache.servicemix.document_1.0.0.v200906161300.jar servicemixcommon_2009.1.0.v200906161300.jar servicemixhttp_2009.1.0.v200906161300.jar servicemixsoap2_2009.1.0.v200906161300.jar servicemixsoap_2009.1.0.v200906161300.jar servicemixutils_1.1.0.v200906161300.jar org.apache.servicemix.cxf.binding.nmr_4.0.0.v200906161300.jar org.apache.servicemix.cxf.transport.nmr_4.0.0.v200906161300.jar org.apache.servicemix.cxf.transport.osgi_4.0.0.v200906161300.jar org.apache.xbean.xbean.spring_3.5.0.v200906161300.jar@IP team: Given your prior experience analyzing ServiceMix source code, howwould you rate the risk? 2. Third party libs w/ CQ, but version shipped differs from CQ --------------------------------------------------------------org.apache.xbean.xbean.classloader_3.5.0.v200906161300.jar (approved: 3.4.1) org.springframework.osgi.io_1.2.0.rc1_v200906161300.jar (approved: 1.0.2)org.springframework.osgi.extender_1.2.0.rc1_v200906161300.jar (approved: 1.0.2)org.springframework.osgi.core_1.2.0.rc1_v200906161300.jar (approved: 1.0.2)org.springframework.core_2.5.6.v200906161300.jar (approved: 2.5.2) org.springframework.context_2.5.6.v200906161300.jar (approved: 2.5.2) org.springframework.beans_2.5.6.v200906161300.jar (approved: 2.5.2) org.springframework.aop_2.5.6.v200906161300.jar (approved: 2.5.2) org.apache.cxf.cxf-bundle_2.1.4.v200906161300.jar (approved: 2.1.3)org.apache.cxf.cxf-rt-bindings-jbi_2.1.4.v200906161300.jar (approved: 2.1.3)org.apache.cxf.cxf-rt-transports-jbi_2.1.4.v200906161300.jar (approved: 2.1.3) Of these, for one we would have to file a new CQ requesting a version change:org.apache.xbean.xbean.classloader_3.5.0.v200906161300.jar (approved: 3.4.1)In all other cases, we'll be able to switch back to the approved version.We are confident that we would be able to file the missing CQs and create and regression test a new build containing the correct versions and with allthe unnecessary jars removed until Friday EOB. @RT PMC, EMO: Please advise us on how to proceed from here. Best Regards, Oliver_______________________________________________ eclipse.org-architecture-council mailing list eclipse.org-architecture-council@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-councilIMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
Back to the top