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

Jesse, et al,

One of the key factors in our eyes is whether any of the code in question is going to be contained in the Eclipse SCM. In the example of "virgo -> spring -> hibernate", will a copy of hibernate be contained in the Eclipse SCM? Or would Hibernate only be on some test machine somewhere?

Thanks.


> -----Original Message-----
> From: Content-filter at foundation.eclipse.org
> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
> Sent: May-18-10 12:36 PM
> To: Runtime Project PMC mailing list
> Cc: mike.milinkovich@xxxxxxxxxxx
> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
> 
> I talked with Jeff about this at length earlier and offered to take a
> stab and writing up our discussion.  Jeff, feel free to chime in as
> needed on it.
> 
> Starting off simply...
> 
> A project needs to declare a CQ for anything in use that is outwardly
> facing to a user...be it a direct dependency (servlet-api) or a
> transitive dependency that your specifically using (equinox http
> service -> jetty -> servlet-api).
> 
> The caveat that we spoke to directly here as being open to
> interpretation was in the case of virgo (virgo -> spring ->
> hibernate).  There are two things going on here that I think give form
> to the intent of the process.
> 
> * if the usage is purely for test (virgo -> spring -> using hibernate
> as purely test data as it exercises a peculiar classloader issue) then
> you do not need a CQ
> * if the usage is to test/validate interoperability (virgo -> spring
> -> using hibernate as lots of clients use it and we validate it works
> with it) then that is clearly a case for a Works With CQ
> 
> The specific litmus test being that if someone came along and
> implemented a couple of classes that exhibited the desired classloader
> issues would you switch over to those classes or would you still test
> with hibernate.
> 
> I think that example clearly defines the scoping in which a project
> lead needs to think about things when asking themselves if they need
> any sort of CQ for a given test or build dependency.
> 
> If you can go through the rigor of examining any given test or build
> dependency with that sort of litmus test then I suspect we are
> adhering to the spirit of the law here, at least until such time as it
> is codified in process somewhere
> 
> thoughts?
> 
> jesse
> 
> --
> jesse mcconnell
> jesse.mcconnell@xxxxxxxxx
> 
> 
> 
> On Fri, May 14, 2010 at 15:11, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
> > Agreed and I absolutely want to limit burden and do not propose super
> detail defs or procedures. Keep it simple.
> >
> > My original query on the meaning of "distribute" was driven by the fact
> that I've seen all of the following uses of the word "distribute" by
> perfectly sane, reasonable and rational comitters at Eclipse.
> > - putting code in CVS at eclipse
> > - compiling code (or not) and making it available as a convenience zip on
> the project page without a release review
> > - whatever you put through the release review
> >
> > This is not unique to "tests" but comes up in that space because
> different teams do different things with their tests.
> >
> > Which is it?  Enquiring minds want to know...
> >
> > Jeff
> >
> >
> > On 2010-05-14, at 3:57 PM, Mike Milinkovich wrote:
> >
> >> Gimme a break.
> >>
> >> "Distribute" means distribute via any reasonable mechanism. Eclipse
> downloads and update sites are obvious inclusions. But pushing something to
> Maven Central is obviously distributing.
> >>
> >> Definitions and procedures detailed enough to prevent people from doing
> things which obviously break the spirit and intent of our community is,
> unfortunately, what leads to burdensome bureaucracy.
> >>
> >>> -----Original Message-----
> >>> From: Content-filter at foundation.eclipse.org
> >>> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
> >>> Sent: May-14-10 3:45 PM
> >>> To: Runtime Project PMC mailing list
> >>> Cc: mike.milinkovich@xxxxxxxxxxx
> >>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
> >>>
> >>> i love this definition as it lets me freely develop maven plugins in
> >>> eclipse svn and push them into maven central without a care in the
> >>> world since we would never put it up for direct download on
> >>> eclipse.org
> >>>
> >>> defeats some of the purpose of the whole process through I suspect :/
> >>>
> >>> jesse
> >>>
> >>> --
> >>> jesse mcconnell
> >>> jesse.mcconnell@xxxxxxxxx
> >>>
> >>>
> >>>
> >>> On Fri, May 14, 2010 at 13:24, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
> wrote:
> >>>> Sure.  We do need a definition then for "distribute". If that means
> "have
> >>> it in your zip on downloads.eclipse.org" then projects that do not make
> >>> pre-built tests available can write test code checked into CVS that has
> >>> direct references to GPL code with no CQs. We can choose to not care
> about
> >>> this (I'm more than happy to stop entering CQs for the things we use in
> our
> >>> tests) but there has to be a very clear definition.
> >>>>
> >>>> Related, do projects "release" their tests?  That is, do the IP logs
> >>> submitted for release reviews need to cover the test related code?
> >>>>
> >>>> Jeff
> >>>>
> >>>> On 2010-05-14, at 2:08 PM, Mike Milinkovich wrote:
> >>>>
> >>>>> 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
> >>>>>> forsomething 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
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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