Add example of TEA API

[ppkarwasz]

This adds an example of statically generated TEA service.

This example does not follow the currently published OpenAPI, but tries to be up-to-date with the Koala Work Camp calls.

[msymons]

A couple of general thoughts on the PR...

1. Log4j 1 is a great use case for several reasons...

   • generalAvailability of the product itself predated generalAvailability of v1.2 by a considerable time,
   • There never was a version available prior to v1.2 (ie, do not bother looking for any).
   • Both generalAvailability dates were before the creation of Maven.

2. Log4j 2 has vers:maven/>=2|<3 for generalAvailability . This is absolutely crystal clear that all the alpha and betas for v3 can be ignored by tooling (such as Dependency-Track) which often struggles to report "latest version" correctly in such cases.

I mention the above not as suggestion to change anything in the JSON but to observe that what is there already tells a good story that might be the basis of some explanation in a README. Something that illustrates the value that can be extracted from the data.

In follow up on Slack and in the WG meeting, @ppkarwasz observed...

Since 2.0-alpha1 < 2.0-alpha2 < 2.0-rc2 < 2 according to Maven, I am wondering what we should do with all the pre-releases? It is probably the same product, but it should have a separate leaf.

...to which I would add "Do we need a CLE event type for preRelease now on can it be added later?" (as CLE is aiming to deliver an MVP by end of 2025). Thoughts, @noqcks ?

Separately, Piotr also observed that we will need additional examples from other ecosystems.

[oej]

Let's wait until this follows the specs

[noqcks]

re: CLE usage, think its totally fine to use a mock version of CLE even if we're not done yet. Happy to see an effort to make it used!

I haven't been keep up with TEA development. However, the CLE spec for a product will cover many different versions of a product? It could cover Bootstrap 2.x and 3.x. It could just cover a list of minor versions. So I think attaching a CLE to a specific version like a leaf version would be incorrect here if that is whats happening. CLE specifically should not be attached to version of something. It should live alongside or be attached to a product or a component if that makes sense, that can describe many or all versions of the product.

[oej]

re: CLE usage, think its totally fine to use a mock version of CLE even if we're not done yet. Happy to see an effort to make it used!
I opened a separate issue to discuss CLE in TEA. Thanks for commenting @noqcks !

[ppkarwasz]

I haven't been keep up with TEA development. However, the CLE spec for a product will cover many different versions of a product? It could cover Bootstrap 2.x and 3.x. It could just cover a list of minor versions. So I think attaching a CLE to a specific version like a leaf version would be incorrect here if that is whats happening. CLE specifically should not be attached to version of something. It should live alongside or be attached to a product or a component if that makes sense, that can describe many or all versions of the product.

I perfectly agree and that is why my TEA Leaves point to minor versions. If TEA Leaves end up being single releases, than the CLE information does not make sense.

[ppkarwasz]

Closing this, since the examples were updated to the new schema and included into:

• Clarify TEA Product fields #111
• Clarify TEA Component fields #128
• Clarify TEA Component Release fields #136
• Clarify TEA Collection fields #137