Re: [eclipse.org-planning-council] [Fwd: Re: Swordfish Release, Missing

[David M Williams <david_williams@xxxxxxxxxx>]

I've opened bug 282036 to track mechanical tasks associated with this 
issue. 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282036





From:
Wayne Beaton <wayne@xxxxxxxxxxx>
To:
"eclipse.org-planning-council" <eclipse.org-planning-council@xxxxxxxxxxx>
Date:
06/30/2009 10:58 AM
Subject:
Re: [eclipse.org-planning-council] [Fwd: Re: Swordfish Release, Missing 
CQs]
Sent by:
eclipse.org-planning-council-bounces@xxxxxxxxxxx



I just compared the JARs in the repository with those in Oliver's list 
and I am pretty sure that we don't have to worry about this. 
Specifically, AFAICT, there appears to be exactly one version of each of 
the JARs listed by Oliver. One thing that I'm not sure how to determine 
is whether or not anybody else cares about any of these JARs. They 
shouldn't, but it is possible.

Wayne

Wayne Beaton wrote:
> My concern with option 1 is that the p2 resolver might, under some 
> conditions, select some of the JARs that must be removed. This might 
> happen if, for example, one of the errant JARs is one of two different 
> versions of the same library.
>
> I did a quick scan of the plugins directory and didn't see anything, 
> but closer scrutiny is required. I will look closer.
>
> Wayne
>
> David M Williams wrote:
>> Option 1. The easiest, would be just to delete the files from Galileo 
>> site. Once that had percolated to all mirrors then Swordfish would 
>> still show up in the Categories, but would fail if someone tried to 
>> install it. Not that great, but easiest and in some ways safest.
>> Option 2. Respin. This might work but some projects have changed 
>> feature versions in their .build files since Galileo was released. 
>> Specifically: Currently in .build files; <features 
>> id="org.eclipse.emf.ecoretools.sdk" version="0.9.0.v200906221231" 
>> repo="//@repositories.0">
>> <features id="org.eclipse.emf.mint.sdk" version="0.8.0.v200906161513" 
>> repo="//@repositories.0">
>> <features id="org.eclipse.uml2tools.sdk" 
>> version="0.9.0.v200906190654" repo="//@repositories.0">
>> But, in Galileo repo: <features id="org.eclipse.emf.ecoretools.sdk" 
>> version="0.9.0.v200906031210" repo="//@repositories.0">
>> <features id="org.eclipse.emf.mint.sdk" version="0.8.0.v200906110922" 
>> repo="//@repositories.0">
>> <features id="org.eclipse.uml2tools.sdk" 
>> version="0.9.0.v200906031456" repo="//@repositories.0">
>>
>> Are these significant? Does anyone care? Are they used anywhere, such 
>> as in EPP packages? Would the old versions still work?
>> Option 3. Regenerate meta-data only, using what's on the Galileo site 
>> (or, the version of the .build files tagged RC5a) minus the Swordfish 
>> contributions and features. I've asked Thomas to comment on what this 
>> would take in his builder.
>> Anyone have preferences? Any other ideas?
>> I've removed Swordfish from the Galileo contributions and am trying a 
>> respin, to see if it works at all, and if it does work, we might be 
>> able to get a more exact understanding of what's changed and what 
>> hasn't.
>>
>>
>>
>>
>>
>>
>>
>> From:
>> Wayne Beaton <wayne@xxxxxxxxxxx>
>> To:
>> "eclipse.org-planning-council" 
>> <eclipse.org-planning-council@xxxxxxxxxxx>
>> Date:
>> 06/29/2009 10:56 PM
>> Subject:
>> [eclipse.org-planning-council] [Fwd: Re: Swordfish Release, 
>> Missing CQs]
>> Sent by:
>> eclipse.org-planning-council-bounces@xxxxxxxxxxx
>>
>>
>>
>> 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 PM
>>> To: 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 
>> not
>> 
>>> matching 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_1.0.1.1_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_1.0.1.1_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.jar
>>>
>>> This leaves us with 10 jars for which new CQs would have to be filed 
>>> 
>> (all of
>> 
>>> them 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, 
>> how
>> 
>>> would 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 versionsand 
>>> with 
>> all
>> 
>>> the 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-council 
>>
>>
>> IMPORTANT: 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.
>>
>>
>>
>>
>> _______________________________________________
>> eclipse.org-planning-council mailing list
>> eclipse.org-planning-council@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>
>> IMPORTANT: 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.
>>
>>
>>
>> _______________________________________________
>> eclipse.org-planning-council mailing list
>> eclipse.org-planning-council@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>>
>> IMPORTANT: 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.
>> 
> _______________________________________________
> eclipse.org-planning-council mailing list
> eclipse.org-planning-council@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>
> IMPORTANT: 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.
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council

IMPORTANT: 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.