Remove or replace onejar download

[abrokenjester]

The current onejar distribution is a jar file that can be downloaded and used without getting tools like Apache Maven or Gradle involved, and just having the entire RDF4J framework in one library file.

However, it is of limited use in practice, as it doesn't contain any third party dependencies, so it often catches first time users out with NoClassDefFoundErrors (in particular, for loggers, but also potentially for things like apache commons dependencies or whatever else rdf4j uses internally). Figuring out which third party dependencies are needed is not straightforward (and having to do this kind of defeats the purpose of having a onejar in the first place).

We should look at producing a more useful download artifact. Options:

1. produce the onejar as an actual maven artifact in its own right (so downloadable from the central repo, instead of hosted on our own site) - that way maven can be used to automatically pull in third party dependencies. Open question: how is this more useful than just using the bom + the runtime (or client, or storage) dependency?
2. Change the onejar to include all third party dependencies, including a specific logger implementation. The use case would be a very easy "getting started" download for people who want to play with RDF4J but are unfamiliar with maven.
3. Just have no onejar.

[pmcb55]

Hi Jeen,

Yeah, I know this has been a long-standing issue - so it's great to see that you're trying to tackle it head-on!

For me, the only reason I've ever used the onejar is when I need something quick (which is always of course!), but I can't remember which specific RDF4J JARs I need to depend on to get my quick job done - so I just use the onejar. I do always go back and remove the onejar, and add the JARs I actually need one-by-one (and usually start by cut-and-pasting from an older project).

Basically what would have helped me was a super-simple addition to the documentation telling me the specific JARs I need for a simple HelloWorld! RDF4J app that, say, reads a local Turtle file, i.e. I think it's just these:
org.eclipse.rdf4j:rdf4j-model:$rdf4jVersion
org.eclipse.rdf4j:rdf4j-rio-api:$rdf4jVersion
org.eclipse.rdf4j:rdf4j-rio-turtle:$rdf4jVersion

[abrokenjester]

Yeah, I know this has been a long-standing issue - so it's great to see that you're trying to tackle it head-on!

Thanks Pat, and as always, appreciate your input!

For me, the only reason I've ever used the onejar is when I need something quick (which is always of course!), but I can't remember which specific RDF4J JARs I need to depend on to get my quick job done - so I just use the onejar. I do always go back and remove the onejar, and add the JARs I actually need one-by-one (and usually start by cut-and-pasting from an older project).

Basically what would have helped me was a super-simple addition to the documentation telling me the specific JARs I need for a simple HelloWorld! RDF4J app that, say, reads a local Turtle file, i.e. I think it's just these:
org.eclipse.rdf4j:rdf4j-model:$rdf4jVersion
org.eclipse.rdf4j:rdf4j-rio-api:$rdf4jVersion
org.eclipse.rdf4j:rdf4j-rio-turtle:$rdf4jVersion

We do have some pointers along those lines in the documentation, but I agree we could be clearer. So if I can summarize: for you it's not so much that it's "everything in a single jar" but more that it's a simple way to get started without having to think about what you need. In other words: if we provided a solution that wouldn't be a single jar but would still (via maven) give you everything you need, that'd suit you? Or is the fact that you don't even need a maven setup part of the "quick project" for you as well?

[Rshr]

Hello Jeen,

I am relatively a new user of RDF4J but not the RDF specification. I recently started using the 3.1.0-M1 oneJar because I wasn't able to figure out which maven dependency had the FedXFactory class, among some other class. So I am in the same boat as pmcb55 on this one, I find it useful to use the oneJAR for dev purposes. Although I would like to trim it down to the precise RDF4J JAR when I move to the next stage in my development process.

[abrokenjester]

Thanks for the input Rowen, appreciated.

I'm leaning more and more in the direction of option 2: make the onejar include everything, including third party dependencies, and focus it specifically on "getting started quickly without worrying about maven and loggers and all that".

[radkovo]

I use rdf4j in a 'modularized' Java 11 application (containing module-info.java for importing the java.desktop module) and it would be really helpful for me to have a single rdf4j maven artifact (i.e. option (1)). Currently, rdf4j seems not to be suitable for modularized apps since the individual jar maven artifacts are treated as separate modules and some of them share the same java packages, which is not allowed among jigsaw modules. Therefore, I have to use onejar as a local dependency which is not very practical with maven.

[abrokenjester]

Thanks @radkovo, good point. We should also clean up our packaging, so that the maven modules can be used for modularized apps. We have an open issue for that: #1494.

I also don't think the options here are "either/or", there's no reason we couldn't distribute both a "rdf4j-all" single jar maven artifact (option 1) as well as create a onejar with all third party dependenies for the "don't care" quick start scenario (option 2).