Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [incubation] CQs for Maven dependencies

The semantics of Maven's "provided" scope are close.

The handbook has content that deals with this. There are two cases where "works with" applies:
  • the functionality of Eclipse project code is enhanced by the presence of the software, but is otherwise functional and useful without it; or
  • there are multiple choices and reviewing all of them is impractical or impossible.
So... it's not a matter of whether or not the software is "provided", it's the nature of the use. If software is required by your project code, then it is a prerequisite, regardless of how it is obtained. That is, if a consumer must install a bunch of software in order for your project software to function, then that "bunch of software" are "prerequisites".

To qualify as the first type of "works with", a dependency would have to optional. At least at runtime. That is, a consumer could use the software without requiring the dependency. FWIW, I argued years ago that build and test dependencies are "works with" because a consumer can use the software without actually invoking a build (and thereby avoid having to agree to the licensing terms of the build dependencies).

The second type of "works with" handles the multiple options scenario. Your software might work, for example, with any kind of database. In this case, at least one of those databases would have to be taken through the due diligence process and then a "works with" CQ indicates that other options may be substituted.

Taken to the extreme, a Java runtime and even operating system are "prerequisites", but are classified as "exempt prerequisites". This is, of course, where things start to get a bit fuzzy. CQs are not required for runtimes and operating systems that are expected to exist on an end user's workstation (we treat these as implied exempt prerequisites). If, however, you want to actually include a runtime with your project then you do need a CQ. If you're not sure, ask the IP Team.

Note that the IP Policy was updated recently (the board approved the update on October 21) and we're in the process of updating our processes. My expectation is that many of the scenarios where "works with" CQs were previously required will not exist under the new policy. But for those scenarios where CQs are required, we'll need to keep existing processes in place. I owe an update on our progress to the committer community.

Wayne

On Mon, Nov 25, 2019 at 9:13 AM Emilio Lahr-Vivaz <elahrvivaz@xxxxxxxx> wrote:
Hello,

The GeoMesa project has been following these guidelines:

1. Any direct or transitive compile scope dependency require a full CQ
2. Any direct provided scope dependency requires a 'works-with' CQ
3. Any direct test scope dependencies require a single 'test' CQ
4. Any transitive provided or test dependencies can be disregarded for IP purposes

Direct here means a top-level dependency declared in your pom, transitive means that you don't declare it in your pom but it's brought in by another dependency.

We don't track maven plugins. And AFAIK you need a new CQ even for a bug fix version, but usually you can request an 'incremental' review (this is less of an issue with license-only CQs).

If it's helpful, we wrote a bash script to generate our dependencies using the maven dependency tree:

https://github.com/locationtech/geomesa/blob/master/build/calculate-cqs.sh

Thanks,

Emilio

On 11/23/19 4:09 AM, Christian Kaltepoth wrote:
Hi all,

I have a few questions about CQs, especially in the context of Maven dependencies. I'm working on a guideline which I will publish in the project wiki and which other committers of the project can use if they want to add new dependencies. 

I would love to get your feedback about whether the following assumptions are correct.
  • If the dependency is "test"-scoped, it is always a Test and Build dependency and therefore treated as a workswith.
  • If the dependency is "provided"-scoped, it is only used at build-time but not really "distributed" in any way. Instead, it must be provided by the environment in which the corresponding Eclipse project is used in. Such dependencies are therefore also workswith.
  • Dependencies which are "compile"-scoped are usually prereq dependencies. However, if the dependency is part of some kind of "optional addon module" of the Eclipse project and not part of the "core functionality", it is workswith.
  • Maven plugins are usually workswith.
  • You can update to newer patch releases of a third-party dependency without filing a new CQ. So in most cases it is fine to update from something like 1.2.4 to 1.2.9, but not to 1.3.0. Of course this only works the license of the dependency didn't change.
I would love to hear your thoughts.

Christian





--

_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/incubation

_______________________________________________
incubation mailing list
incubation@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/incubation


--

Wayne Beaton

Director of Open Source Projects | Eclipse Foundation, Inc.


Back to the top