Version `2.3.0` creates an uber-jar which causes class file duplicates

[mhm90]

Hi,

I currently upgraded from CANAR-2.3.1 to 2.3.0 and I found out that you are using apache's maven-shade-plugin on the build at pom.xml. I think you should avoid creating uber-jar in psl-java because I assume it was not intended as a standalone executable application before, was it? I think the standalone version of PSL is the psl-cli.

Anyway, the exact problem is when I use this uber-jar the Slf4J or any common dependency between psl-java and my application causes class file duplication.

[mhm90]

You should consider excluding third-party dependencies as described in: Selecting Contents for Uber JAR

[eriq-augustine]

As of 2.3.0 psl-java is intended to build with an executable uber jar.
It now provides an interface to the PSL common runtime.

Maybe we can split the psl-java package into psl-java and psl-runtime packages.
Where psl-runtime has no actual code, but builds an uber jar.

[mhm90]

Do you have any suggestions for now?

[eriq-augustine]

Are you using the PSL runtime?

If you are, then I suggest building locally (or using the Sonatype snapshot repository, where we push all our dev builds (but we don't officially support that)).

If you are not using the runtime, then psl-core is probably the dependency you want to target.

[mhm90]

OK, I just looked at the psl-java source code and I think it has only the runtime classes. I think I should move to psl-core. I will let you know if anything from psl-java is needed.

[mhm90]

So, I have implemented my PSL job according to psl-examples so there is a need for psl-parser and PSLModel classes. I still think the uber-jar is not a suitable choice for psl-java because it clearly means you want it to use in a java project. Even the psl-cli which is intended for runtime should not use an uber-jar in my opinion. We all know that the classpath option is doing all things and we can find out which part of code is defined in which jar file. You can use .sh files like before to add the classpath option.

[eriq-augustine]

I have already moved the uber jar out of psl-java and into psl-runtime.
f7f2eb7

psl-cli needs to be packaged with all dependencies, and should be a stand-alone executable.
So it would not just be an issue of maintaining a classpath, but also fetching dependencies.

[mhm90]

I have already moved the uber jar out of psl-java and into psl-runtime.
f7f2eb7

Sounds great! Do you plan to create a release for this?

psl-cli needs to be packaged with all dependencies, and should be a stand-alone executable.

I know that the psl-cli has really its standalone nature, but I was thinking about someone might want to use the psl-neural in his java project like the way I used the psl-java. In this case the problem arises with the uber-jar since the psl-neural is dependent on the psl-cli and it is an uber-jar!

[eriq-augustine]

We don't have any dates for the next release yet.

Eventually psl-neural will use the PSL Runtime (this was part of the reason for the creation of the runtime), so that will eventually solve the issue.