[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [rt-pmc] Revisiting blanket and test/build CQs
|
At the risk of saying something stupid, shouldn't the rule be more along the
lines of "if you distribute it or if the consumer must have it, you CQ it" ?
> -----Original Message-----
> From: rt-pmc-bounces@xxxxxxxxxxx [mailto:rt-pmc-bounces@xxxxxxxxxxx] On
> Behalf Of Glyn Normington
> Sent: May-14-10 2:01 PM
> To: Runtime Project PMC mailing list
> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>
> That "You reference it? You CQ it" rule would lead Virgo into needing
> detailed CQs for many more 3rd party libraries. Consider a simple test of
> thread context class loading. The test would most likely have a dependency
> on the library doing the thread context class loading, but only because
the
> test is specifically checking that library. So we would end up raising a
CQ
> for something which has no dependency from the runtime Virgo code. I'm not
> sure of the value of this except to keep the rules simple, which
admittedly
> has some value in and of itself, but not much IMO.
>
> Glyn
> On May 14, 2010, at 5:29 PM, Jeff McAffer wrote:
>
> > 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 wantsthis 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
> >>>
> >>>
> >
> > _______________________________________________
> > 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