Re: [ee4j-pmc] Project/Specification dependencies

[Wayne Beaton <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx>]

GlassFish absolutely needs the artifacts produced by the API projects; it won't function without them.

I understand. But I don't think that having the diagram indicate that GlassFish implements all of the specifications is useful. Like I said earlier, it's not clear to me that expressing the that Jakarta EE references all of the specifications, while true, is all that useful on the diagram.

GlassFish does implement JPA, but it implements JPA by way of consuming EclipseLink. This is the interesting relationship IMHO, as it describes the relationships between the projects and makes it clear that GlassFish doesn't implement that particular specification directly. 

Again, I'm pretty sure that GlassFish does implement EJB. IMHO, by saying GlassFish consumes EclipseLink, but implements EJB gives me more information about where to look for stuff. 

I'll take a look at the pull request.

Wayne

On Thu, May 17, 2018 at 6:49 PM, Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:

Wayne Beaton wrote on 05/16/2018 03:55 PM:

I think of the "consumes" relationship as meaning "consumes an implementation".

Ok, so even though GlassFish consumes all the API projects, you only want to indicate the separate implementation projects that it consumes?

So... EclipseLink implements the JPA specification and Eclipse GlassFish consumes EclipseLink. I believe that Eclipse GlassFish implements some specs itself (EJB?) and consumes implementations provided by others. Assuming this relationship is correct, Eclipse GlassFish has no direct relationship with JPA (though I could argue this either way; this is very much a choice between creating a meaningful chart and one that's overly pedantic).

GlassFish absolutely needs the artifacts produced by the API projects; it won't function without them.

The relationships from Eclipse GlassFish, I believe, are actually the most interesting ones.

If anything, we can eliminate the references implementation from the Jakarta EE Platform project as it references everything, and so isn't all that interesting on this chart. 

FWIW, it's pretty simple to just eliminate that project and references from the dot file and render the chart without it:

grep -v jakartaee relationships.dot | dot -Tsvg > ~/chart.svg

Does this make sense?

I'm going to leave all this in for my pull request, but I'd like to hear from others as to whether any of these relationships should be removed to make the picture more useful.


Also, there's a bunch of optional dependencies that aren't captured.  For example, JTA has an optional dependency on Interceptors and CDI.

And a bunch of specs use Common Annotations, but I'm not completely clear on which cases are hard dependencies and which are optional.  Likely there are some hard dependencies on Common Annotations that are missing.

I submitted a pull request.  I'm sure it's still not completely correct.

--

Wayne Beaton

Director of Open Source Projects

The Eclipse Foundation