You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Usually, java dependencies are jar files. However, on the publisher side, we don't want to enforce having to bundle all data as jars and rather make it possible to download e.g. .csv files or .ttl.bz2 files directly.
Usually, one can place resources such as datasets into src/main/resources and upon deployment they become part of the jar bundle.
With non-jar resources, we can't use traditional <dependency> blocks to bundle them with an application.
However, a project can declare an additional resource folder under the target folder and then use the maven-dependency-plugin to copy non-jar resources there. Instead of <dependency> blocks, references are expressed using <artifactItem> - but the rest is the same. The additional overhead seems acceptable; essentially its a copy&paste of the snippet below.
Usually, java dependencies are jar files. However, on the publisher side, we don't want to enforce having to bundle all data as jars and rather make it possible to download e.g.
.csv
files or.ttl.bz2
files directly.Usually, one can place resources such as datasets into
src/main/resources
and upon deployment they become part of the jar bundle.With non-jar resources, we can't use traditional
<dependency>
blocks to bundle them with an application.However, a project can declare an additional
resource
folder under thetarget
folder and then use themaven-dependency-plugin
to copy non-jar resources there. Instead of<dependency>
blocks, references are expressed using<artifactItem>
- but the rest is the same. The additional overhead seems acceptable; essentially its a copy&paste of the snippet below.In the IDE it then looks like this:
The text was updated successfully, but these errors were encountered: