[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Revisiting blanket and test/build CQs
|
Hi Mike
To answer your question - Virgo only downloads hibernate and neither distributes it nor checks it into version control.
The conclusion of the PMC discussions does seem to be, however, that Virgo needs to raise a "works with" CQ for hibernate because of the fact that we have tests that validate the dependency chain Virgo->Spring->(optionally)Hibernate and ensure Hibernate works correctly in Virgo.
Do you concur with this outcome?
Glyn
On 20 May 2010, at 02:51, Mike Milinkovich wrote:
>
> The distinction is that if the code is in our SCM system then we are distributing it. Whereas if we just download as needed into a build process, or if it resides on a test/build server not generally accessible we are not distributing it. From a legal perspective, that is an important difference.
>
>
>> -----Original Message-----
>> From: Content-filter at foundation.eclipse.org
>> [mailto:postmaster@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Jesse McConnell
>> Sent: May-19-10 3:34 PM
>> To: mike.milinkovich@xxxxxxxxxxx
>> Cc: Runtime Project PMC mailing list
>> Subject: Re: [rt-pmc] Revisiting blanket and test/build CQs
>>
>> I suspect the answer to that would be yes, hibernate would only exist
>> on the test machine for that example...
>>
>> but I personally don't see the distinction because what is the
>> difference between something being in SCM vs being downloaded as
>> needed automatically by a build system, in essence that is a
>> technical/implementation point more then any anything..using ant you
>> mostly have jars checked into the scm but you move up to ant+ivy or
>> maven and your pulling them down automatically...i don't think see how
>> those conditions are/should be treated differently
>>
>> I would think (perhaps incorrectly) that the desire is to capture the
>> intent and purpose behind the dependency, in the case of a build/test
>> only dependency being is that dependency strictly a glob of test data
>> that given another option you would not have issue with switching to
>> vs the intent being to test specific compatibility with that specific
>> glob o' data.
>>
>> cheers,
>> jesse
>>
>> --
>> jesse mcconnell
>> jesse.mcconnell@xxxxxxxxx
>>
>>
>>
>> On Wed, May 19, 2010 at 14:19, Mike Milinkovich
>> <mike.milinkovich@xxxxxxxxxxx> wrote:
>>> 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
>>>>>
>>>
>>>
>
> _______________________________________________
> rt-pmc mailing list
> rt-pmc@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/rt-pmc
