Hi Jeen. Create a new CQ with either just the delta, or with a new complete list (whichever is easier).
This is something that we set up a few years ago after I successfully argued that "build and test" dependencies are really the same as "works with" dependencies. There's more in the handbook <https://www.eclipse.org/projects/handbook/>, but no answer to Jeen's question, so I'll fix that. The idea of grouping many "build and test" libraries was to avoid requiring that project teams create dozens or hundreds of CQs. Naturally, there is some gray area here: technically, the Java compiler and Maven are a build and test dependencies. We don't want to see CQs for the Java compiler or standard Maven. You will notice that some of the build and test CQs do mix in some standard Maven plugins; it's not wrong to do this, it's just not required. The origin of this was in things like unit tests using Mockito. The test code itself is heavily dependent on Mockito, so it was originally considered to be a prerequisite. I argued that the test code was "extra" functionality and that the average consumer would just grab the JAR files produced by the project. That is, the use of Mockito enhanced the functionality of the project as a "works with", but was not required (Mockito is probably a bad example since many versions of it have actually been approved as prerequisites, but I felt that it was a good example of what we want to enable). You'll notice that a handful of the "build and test" CQs in IPZilla cover technologies that are used in examples used in tests. Again, these examples are required to run the tests, but should not be included in the distribution. Code generators may be a bit of a gray area. Since code generators typically inject intellectual property we need to know about their use (yes, I know that we can argue that compilers do this too; believe me that I've been down this rabbit hole a few times). Create a "build and test" CQ for code generators. Like everything else, the EMO leans on the PMC for assistance in determining whether or not something qualifies as a "works with" / "build and test" dependency. If you're not sure, ask. Wayne On Mon, Sep 28, 2020 at 7:26 PM Jeen Broekstra <[email protected]> wrote: > hi all, > > For our build and test dependencies (things like maven plugins etc), we > have a single umbrella CQ that in its description has a list of the various > plugins, each with a version range. See > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=20318 . > > We now face a situation where we need to update that list: there's one new > plugin, and one of the other plugins is updated with a version that is > beyond the range stated in that CQ. > > What is the best way to go about this? Should I log a new umbrella CQ with > an updated list and then withdraw the old one? Or can I just add a comment > on the existing CQ? > > Jeen > _______________________________________________ > incubation mailing list > [email protected] > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/incubation > -- Wayne Beaton Director of Open Source Projects | Eclipse Foundation, Inc. Join us at our virtual event: EclipseCon 2020 <https://www.eclipsecon.org/2020> - October 20-22
_______________________________________________ incubation mailing list [email protected] To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/incubation
