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

This makes sense but is still ambiguous (well at least to me :-)  For example, if you need lib X at compile time, it seems that you have code that uses lib X. Some cases:

1) If that code is something you ship then an explicit CQ is needed. 
2) If that code is test code for some function that ships, seems like variation of case #1. 
3) There may be a case where a test needs "any old X". Again, presumably that is testing something from the mainline code so either there is already a CQ or it completely does not matter which X is used and no IP discussion is needed.
4) If it is test/build infrastructure like EasyMock then there should be very little IP process required. For example, however we IP clear the JREs running on the build machine.

Are there other cases?

Which cases are at play here?

Jeff


On 2010-05-12, at 9:57 AM, Jesse McConnell wrote:

> build dependency - anything required to run a compile process
> test dependency - anything required to run a test process
> 
> I find it easier to think in terms of scoping though, as maven
> implements things.
> 
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope
> 
> # compile - This is the default scope, used if none is specified.
> Compile dependencies are available in all classpaths of a project.
> Furthermore, those dependencies are propagated to dependent projects.
> 
> # provided - This is much like compile, but indicates you expect the
> JDK or a container to provide the dependency at runtime. For example,
> when building a web application for the Java Enterprise Edition, you
> would set the dependency on the Servlet API and related Java EE APIs
> to scope provided because the web container provides those classes.
> This scope is only available on the compilation and test classpath,
> and is not transitive.
> 
> # runtime - This scope indicates that the dependency is not required
> for compilation, but is for execution. It is in the runtime and test
> classpaths, but not the compile classpath.
> 
> # test - This scope indicates that the dependency is not required for
> normal use of the application, and is only available for the test
> compilation and execution phases.
> 
> # system - This scope is similar to provided except that you have to
> provide the JAR which contains it explicitly. The artifact is always
> available and is not looked up in a repository.
> 
> 
> in the above list of scopes, easy mock is obviously a test dependency
> and similarly hibernate could be compile or test depending on your
> specific use case, as can most anything, all depends on how your using
> it
> 
> jesse
> 
> 
> --
> jesse mcconnell
> jesse.mcconnell@xxxxxxxxx
> 
> 
> 
> On Wed, May 12, 2010 at 08:14, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
>> Stepping back a bit it seems we need to clarify "build/test dependency". For things like EasyMock it seems pretty clear. It is testing infrastructure. Got it. Can you give some concrete examples of other things that would fall under this category?
>> 
>> On a separate note, are you saying that you don't know or control what versions of libs you are building / testing with?
>> 
>> Jeff
>> 
>> On 2010-05-11, at 10:32 PM, Glyn Normington wrote:
>> 
>>> I agree it is good to nail this subject down while it is still unclear in people's minds. Thanks for raising it Doug.
>>> 
>>>> From my perspective, CQ 4083 (in the case of LGPL) provides a formal record that Virgo build/test dependencies which are neither checked in at, nor distributed from, eclipse.org: (a) are agreed to be "works with" dependencies, and (b) are benign from an IP perspective.
>>> 
>>> Such CQs also solve the practical problem that we don't have an automatic means to synchronise a detailed list of build/test dependency CQs with the dependencies encoded in the build system. We also can't generate the list from the transitive dependencies of the runtime code as in many cases there is no such transitive dependency (even when the complete generality of the Spring framework is taken into account).
>>> 
>>> So the only way we could verify we had raised the correct set of CQs would be to do a laborious and error-prone trawl before each release (unlike checked in or distributed dependencies which are relatively bounded in number and trivial to scan for).
>>> 
>>> But suppose for the sake of argument that we had such a system and every time we added a new build/test dependency, we were prompted to raise a new CQ. What value would this provide?
>>> 
>>> Each new CQ would log a build/test dependency on third party library xxx at version nnn with license yyy. I believe the thinking as far as PMC approval would be: the new CQ is yet another in the long list of build/test dependencies so there is no problem in approving it. I also believe the thinking in the legal team would be: if the new CQ has the same license as some of the other build/test dependencies, again there is no problem in approving it. If that analysis is correct, the new CQ would *only* add real value if it introduced a build/test dependency with a previously unused license. Well, that is precisely the same value that CQ 4083 (in the case of LGPL) is providing, but at a much lower net cost to everyone involved.
>>> 
>>> So, personally, I have yet to understand what value a detailed list of build/test dependency CQs would add, even if it was practical to maintain such a list. I'd be grateful if someone could enlighten me.
>>> 
>>> Thanks,
>>> Glyn
>>> On 11 May 2010, at 21:10, Jesse McConnell wrote:
>>> 
>>>> When jetty was going through the review process we had the
>>>> understanding that test dependencies were no different then anything
>>>> else in terms of the code being checked into svn.  If it was required
>>>> to build and/or run at all it had to have a CQ and go through the
>>>> proper channels.  That being said we still use the artifacts from the
>>>> maven central repo for the actual testing but we have solid IPLog
>>>> representation for everything (case by case) and we purposefully left
>>>> code of jetty on The Codehaus because it would have been problematic
>>>> to pass dependencies through the CQ process or the code implementing
>>>> it through the IP Validation/Verification process.  When we move to
>>>> distribute anything from eclipse.org it uses everything from Orbit
>>>> like it should.
>>>> 
>>>> One case I would like to add for clarification is an artifact that is
>>>> never going to be downloaded from eclipse.org, like for example a
>>>> maven plugin.  It has firm dependencies on things like the maven
>>>> plugin api and stuff like that but since its never going to be
>>>> download from eclipse.org, much less will its dependencies see the
>>>> light of orbit....are we still banned from having that in our svn @
>>>> eclipse?  We would release it into the maven central repository same
>>>> as everything else we release to maven central...
>>>> 
>>>> Anyway, I am encouraged to seem further light shown on the issues.
>>>> 
>>>> cheers,
>>>> jesse
>>>> 
>>>> --
>>>> jesse mcconnell
>>>> jesse.mcconnell@xxxxxxxxx
>>>> 
>>>> 
>>>> 
>>>> On Tue, May 11, 2010 at 14:13, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
>>>>> Great topic Doug.  Thanks for the context. I agree with the overall concern
>>>>> around blanket CQs. I am also interested in people's thoughts on the
>>>>> position of test code in the IP landscape.
>>>>> There has been an increase in the number of libs needed only for testing. In
>>>>> the past we have not drawn much of a distinction between coded needed for
>>>>> testing and other dependencies.  Things like EasyMock are somewhat obvious
>>>>> and unproblematic but, what about, *for example*, using Hibernate for
>>>>> testing? Raises questions like:
>>>>> - What are you testing and won't users have to get hibernate too?
>>>>> - If hibernate is just one of the options, can we pick one that would be
>>>>> less problematic?
>>>>> - how does testing code relate to incubating code in the eyes of the IP
>>>>> system?
>>>>> As with much of the IP policy, I am quite open to different positions but
>>>>> feel strongly that we have a clear and simple set of guidelines so we can
>>>>> stop having this kind of discussion :-)
>>>>> Jeff
>>>>> 
>>>>> On 2010-05-11, at 2:38 PM, Douglas Clarke wrote:
>>>>> 
>>>>> RT PMC,
>>>>> 
>>>>> I would like to revisit the discussion on blanket CQs for test/build such as
>>>>> CQ 4083 recently approved for Virgo. I apologize that I was unable to
>>>>> participate in the earlier discussion but after looking at this CQ I believe
>>>>> we need to revisit the issue to ensure we are all clear on how we handle
>>>>> these situations.
>>>>> 
>>>>> My concerns include:
>>>>> 
>>>>> The distinction between build/test and code that is contained in the Eclipse
>>>>> code repositories and the code/binaries that are distributed from the
>>>>> projects.
>>>>> 
>>>>> I firmly believe that all code that is included in the distribution/release
>>>>> from a project that has a 3rd party dependency either explicitly (i.e.
>>>>> import) or implicitly (functionality requires the library must be on
>>>>> classpath to use) should have a separate CQ listing the individual
>>>>> dependency and explaining how it meets the works-with requirements and that
>>>>> CQ be backed up with approval on the PMC mailing list.
>>>>> 
>>>>> Additionally there are some who believe that all code in the repository,
>>>>> including test cases, are part of the project's 'release' even if not
>>>>> distributed in bundles/zip. We should discuss where we draw the line between
>>>>> build/test/release and how these CQs for 3rd party dependencies are handled.
>>>>> I am concerned that a blanket CQ is too broad and does not offer much value
>>>>> from an IP due diligence perspective. I would prefer to see individual CQs
>>>>> or at a minimum a list of projects and versions and possibly jar files that
>>>>> the CQ applies to. In the case of 4083 I believe the intent was for testing
>>>>> utilities only and not to any Virgo code that would be shipped but the broad
>>>>> nature of the CQ makes it unclear what it applies to and could lead to
>>>>> committers inadvertently assuming they can include LGPL dependencies without
>>>>> the proper CQs.
>>>>> 
>>>>> I am happy to get the discussion started here and then continue on next
>>>>> week's PMC call.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Doug
>>>>> 
>>>>> For reference the policy is:
>>>>> http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
>>>>> _______________________________________________
>>>>> 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