MP 3.3 CQs - Help

[John Clingan]

I can't seem to find CQs for the following dependencies in IPZilla. Please reply with CQ #s. Oh, and feel free to educate me on a better way to search :-)

Fault Tolerance 2.1

• Toplevel POM
• • maven-checkstyle-plugin 3.1.0

Config 1.3

• api POM
• • org.osgi.annotation.versioning 1.1.0
  • bnd-baseline-maven-plugin 2.1
• top-level POM
• • maven-source-plugin 3.2.0
  • maven-jar-plugin 3.2.0
  • maven-javadoc-plugin 3.1.1
  • microprofile-maven-build-extension

Health 2.2

• api POM
• • bnd-baseline-maven-plugin 2.1

Metrics 2.3

• api POM
• • bnd-baseline-maven-plugin 2.2

[Emily Jiang]

Hi John,

As mentioned a couple of times on the call and some explaination on my email, which you might have missed, Eclipse Foundation no longer needs us to maintain CQ. All we need to do is to search the third party dependencies from here. If you cannot find the third party lib there, you then raise CQ to get them added to the ClearlyDefined database. Therefore, we don't need to have a spreadsheet to maintain CQ neither do we need to create any piggyback CQ (as Eclipse Foundation does not care which project uses the third party any more). You can read the blog from Wayne for more details.

By the way, I checked all of the listed dependencies and they are all in the database except microprofile-maven-build-extension, which is our own I think.

The other thing is that the bnd-baseline-maven-plugin version is 4.3. I think the command you ran might output the wrong version. Anyway, the plugin is in the database.

Based on my search, we are good.

Thanks

Emily

[Emily Jiang]

Further to our above explaination, I also updated MicroProfile's third party dependency wiki.

Thanks

Emily

[John Clingan]

Guilty as charged on all counts. Thanks for the reminder. For some reason I thought clearlydefiend was coming, but it's already here.

Thanks. +1 on bnd. Not sure how I got version 2.1, but I blew away my local repo and cloned from scratch. 

[Emily Jiang]

No worries!

Thanks

Emily

[Martin Stefanko]

John and Emily, 

what type of IP Due Diligence Type should we use for minor spec upgrades in the release plans? Some specs for MP 3.3 use type A (https://projects.eclipse.org/projects/technology.microprofile/releases/metrics-2.3) and some use type B (https://projects.eclipse.org/projects/technology.microprofile/releases/fault-tolerance-2.1).

Thanks,

Martin

[Emily Jiang]

Hi Martin,

From Wayne's blog on IP:

A project team can decide what level of IP Due Diligence they require for each release. Hypothetically, a project team could opt to make several Type A releases followed by a Type B release, and then switch back. I can foresee this being something that project teams that need to engage in short release cycles will do.

 

After graduation, project teams can decide what they want to do. We foresee at least some project teams opting to issue regular multiple Type A releases along with an annual Type B release (at this point in the time, there is no specific requirement to be Type A or Type B to participate in the simultaneous release).

It seems we can do mixed Type A or Type B release. Since MP 3.3 is a minor release, we should be ok with Type A. I will update FT to use Type A.

Thanks

Emily