The semantics of Maven's "provided" scope are close. The handbook <https://www.eclipse.org/projects/handbook/#ip-third-party-workswith> 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 <https://www.eclipse.org/projects/handbook/#ip-third-party-exempt>". 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 <[email protected]> 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 > > <https://wiki.eclipse.org/Development_Resources/IP/Test_and_Build_Dependencies> > 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 > > > > > > -- > Christian Kaltepoth > Blog: http://blog.kaltepoth.de/ > Twitter: http://twitter.com/chkal > GitHub: https://github.com/chkal > > > _______________________________________________ > incubation mailing [email protected] > To change your delivery options, retrieve your password, or unsubscribe from > this list, visithttps://www.eclipse.org/mailman/listinfo/incubation > > > _______________________________________________ > incubation mailing list > [email protected] > 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.
_______________________________________________ incubation mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/incubation
