Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Revisiting blanket and test/build CQs

I specifically put in that exception to match what other projects I know of do. It is IMHO interesting to know and track what third party libs are being used explicitly and directly in tests. This also simplifies the CQ guidelines.  "You reference it? You CQ it"

Jeff

On 2010-05-14, at 12:07 PM, Mike Keith wrote:

> I agree with Adrian, and with Jeff, with the exception that if the code that explicitly references the lib is only test code and is not shipped with the project then I don't think a CQ should need to be entered, since as Jeff put it, these kinds of test dependencies are only "needed to complete the development process (i.e., build and test)."
> 
> On 5/14/2010 11:45 AM, Jeff McAffer wrote:
>> I vote for not raising the CQs with the understanding that the libraries in question meet the criteria discussed in this thread.  Under that model they are just tools that are needed to complete the development process (i.e., build and test).
>> 
>> The answer would change however if
>> - there is any code in the project (test or otherwise) that explicitly references the libs
>> - there is any indication that users will have to (or may want to) get these libs to make the *Virgo* supplied function go.
>> 
>> I would rely on Virgo project leadership to monitor the cases in which these libs are being used and ensure that they meet the model outlined.
>> 
>> Jeff
>> 
>> On 2010-05-14, at 11:11 AM, Glyn Normington wrote:
>> 
>>   
>>> Virgo has a deadline of Friday 21 May for raising all necessary CQs. I would like the PMCs position on blanket test/build CQs by COB on Wednesday 19 May otherwise I'll create more blanket CQs (for the licenses other than LGPL) like CQ 4083.
>>> 
>>> I have heard various opinions expressed ranging from "don't raise CQs to these at all" (to avoid CQs like 4083 being accidentally abused by piggy-backers) to statements implying that we ought to raise one CQ per separate build/test dependency (but without any clear explanation of the benefit of doing this).
>>> 
>>> I don't want to rehash this thread as we can all look in the archives, but perhaps someone on the PMC would care to propose a direction forward.
>>> 
>>> My vote would be not to raise such CQs as this seems to be the practice in other projects (witness the discussion of allowing the second Hudson build machine access to the internet in order to pull down dependencies at build time).
>>> 
>>> Thanks,
>>> Glyn
>>> On 14 May 2010, at 03:56, Glyn Normington wrote:
>>> 
>>>     
>>>> Confirmed.
>>>> 
>>>> Glyn
>>>> On 13 May 2010, at 17:49, Douglas Clarke wrote:
>>>> 
>>>>       
>>>>> Glyn,
>>>>> 
>>>>> Can you confirm then that:
>>>>> 
>>>>> 1. there will be no shipped code from Virgo that imports classes/interfaces from these LGL libraries?
>>>>> 
>>>>> 2. that there is no functionality of Virgo that will ship that can only be used when one of these LGPL libraries is on the classpath?
>>>>> 
>>>>> Doug
>>>>> -----Original Message-----
>>>>> From: Glyn Normington [mailto:gnormington@xxxxxxxxxx]
>>>>> Sent: May 13, 2010 9:39 AM
>>>>> To: Runtime Project PMC mailing list
>>>>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>>>>> 
>>>>> 
>>>>> The generic thread context class loading support in Virgo is active all the time.
>>>>> 
>>>>> To use the support, the user places the relevant third party library in the Virgo repository and then deploys an application that used the third party library.
>>>>> 
>>>>> The user must ensure that their application bundles export packages for any classes that need to be loaded via a thread context class loader. The must also include their application bundles in a scoped plan if the application has more than one bundle.
>>>>> 
>>>>> Virgo ensures that a suitable thread context class loader is set when the third party library is invoked which the third party library can then use to load application classes.
>>>>> 
>>>>> I hope that's clear! :-)
>>>>> 
>>>>> Glyn
>>>>> 
>>>>> On 13 May 2010, at 14:13, Jesse McConnell wrote:
>>>>> 
>>>>>         
>>>>>> Glyn,
>>>>>> 
>>>>>>           
>>>>>>> 2. There are no dependencies whatsoever from the Virgo runtime to the 3rd party library. For example, a 3rd party library used by Virgo applications uses thread context class loading. We have tests with such libraries to make sure Virgo's thread context class loading support works correctly.
>>>>>>>             
>>>>>> 
>>>>>> What does a user that wants this functionality have to do to make that
>>>>>> sort of support active?  I suspect that will help clear things up some
>>>>>> 
>>>>>> cheers,
>>>>>> jesse
>>>>>> _______________________________________________
>>>>>> rt-pmc mailing list
>>>>>> rt-pmc@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>>>>>           
>>>>> _______________________________________________
>>>>> rt-pmc mailing list
>>>>> rt-pmc@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>>>> _______________________________________________
>>>>> rt-pmc mailing list
>>>>> rt-pmc@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>>>>         
>>>> _______________________________________________
>>>> rt-pmc mailing list
>>>> rt-pmc@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>>>       
>>> _______________________________________________
>>> rt-pmc mailing list
>>> rt-pmc@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>>>     
>> _______________________________________________
>> rt-pmc mailing list
>> rt-pmc@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/rt-pmc
>> 
>>   



Back to the top