Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rdf4j-dev] SHACL in javadocs

I had a closer look to (re)acquaint myself with the current build process and how it all fits together. Here's a summary both for as my own mental notes and as a refresher/check with you folks.

RDF4J uses a staggered build model over multiple repos, where each sub-repo creates its own aggregated binary jar and source jar (using the maven shade plugin), as well as its own aggregated javadoc (using the maven javadoc plugin). For the rdf4j-storage modules, this is all configured in rdf4j-storage/storage/pom.xml. In other words, we produce three aggregated resources for the rdf4j-storage project:

 - a binary jar
 - a source jar
 - a javadoc jar

The assembly module in rdf4j-tools then depends on these aggregated projects and downloads them to create an "uber-aggregated" javadoc bundle to include in the SDK distribution. All fairly straightforward I guess. What was doing my head in was that although the SHACL javadoc was included in the aggregated javadoc produced by rdf4j-storage, it wasn't in the end-result, the 'uber-aggregated' javadoc.

Now the reason for that is this: rdf4j-tools/assembly has a dependency on the rdf4j-storage module. That dependency resolves to the aggregated source/binary jars produced by the shade plugin in rdf4j-storage/storage. The javadoc module then builds the aggregated javadoc for inclusion in the sdk by including all dependencies. The thing is: although the shacl module is included in the aggregated javadoc for rdf4j-storage, it's not in the configuration for the shade plugin - so it's not in the aggregated binary/source jars, and therefore it's not included as a dependency for the maven assembly module.

I was sort of right about it being caused by breaking naming/org conventions: the shade plugin in storage is configured to include every rdf4j module that starts with sail-*. Since the SHACL module breaks this convention, it needs to be included specifically in the config to be included.

TLDR; I need to tweak the shade plugin config in rdf4j-storage/storage, and we should be more careful in following conventions when creating new modules :)

Cheers,

Jeen 

PS I hadn't really realized before that with the new setup, the SDK distro does not contain jars for individual rdf4j modules anymore, instead it contains the aggregated jars for client and storage. I'm not entirely sure that's as intended tbh.



On Mon, Dec 24, 2018 at 10:02 AM Jeen Broekstra <jeen.broekstra@xxxxxxxxx> wrote:
I don't immediately know, but part of the problem in figuring this stuff out is that the configuration of the build has grown rather Byzantine. There's at least 3 or 4 different poms where the layout of the javadoc is being configured. Coupled with that is the fact that the SHACL sail breaks naming/organizing conventions (it's in a module rdf4j-shacl, rather than rdf4j-sail-shacl). I'll take a closer look. It might be something as simple as the order in which the modules are processed by the reactor. 

Jeen

On Mon, Dec 24, 2018 at 1:18 AM Håvard Ottestad <hmottestad@xxxxxxxxx> wrote:
Hi,

I was wondering why nothing related to the ShaclSail is showing up in the javadocs?


Anything I need to do to make it show up?

Cheers,
Håvard
_______________________________________________
rdf4j-dev mailing list
rdf4j-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/rdf4j-dev

Back to the top