Puck for library jar creation

[amiracam]

I'm working on a Jruby Vertx project and because of Vertx fatjar creation I have concluded that I need a way of packing up gems into a jar in such a way that those gems are in Jruby loadpath, to be clear the final jar which is driven by the shadowJar plugin is meant to pack up all java dependencies along with a jar that represents needed Jruby gems

I have struggled to find a beast that does all of that.

Your readme does not directly mention whether the resulting jar from the Puck packaging process could indeed be used as a library jar but maybe you could elaborate ?

thanks once again

[iconara]

If you need the gems to be in the load path I don't think you can do what you describe. I'm not clear on whether or the application will be booted by JRuby, but I assume it is. In that case I think you could reverse the process: you build your Java dependencies and use the :merge_archives feature of Puck to create a final jar with all the gems, and the Java dependencies.

The issue is that if you use shadowJar (I assume you're talking about the Maven plugin here), it won't create a jar that will boot JRuby, which in turn means that there won't be anything that sets up the load path.

If you can't do it the way I suggest, you can always look at how Puck sets up the jar and try to replicate that in your build process. It's not that much that needs to be done. Most of the complexity is in dealing with Bundler and building the jar.

[amiracam]

Actually using shadowJar plugin for Gradle which in the case of vertx also makes changes to the manifest that setups the boot of the application. I use gradle also to bundle in the jruby complete jar and have tried as well manually creating a jar of gem repos and then including that as a dependency in gradle Gradle / shadowJar will indeed wrap all dependencies into the jar and supposedly all of these are in the classpath but yet in a virgin remote box that is insufficient i.e. I cannot “require” the gems added Supposedly back in the 1.7x Jruby line , Nick Sieger had added the capability of scanning the classpath for gem specifications and adding those to the load path but maybe that has not been updated to the 9.x line, see here if interested: http://blog.nicksieger.com/articles/2009/01/10/jruby-1-1-6-gems-in-a-jar/ I’m not sure if Jruby “boots” but if the gems are in the load path as they are on my development box i.e. just due to the sheer fact that I had used bundler on the gemfile then the app will start a la fashion of “java -jar myApp.jar”, so one option (not as desirable) would be to equip the remote target with access to the gems there, the issue with that is that I have to setup the “jruby_home” env var upon invocation of the app or perhaps pass the path of the gem repo to my app upon startup and then add said path to the loadpath at said start up time i.e. within initialization of the app I will test your suggestion , I’ll first create a simple project which uses Bundler to gather up my required gems, make my “app.jar” available and use puck to merge, although I fear that may alter the manifest which I need to stay as is in order to startup Vertx Thanks again Charles A. Monteiro Chief Technology Officer Datasoft, Inc Phone: 347-853-7349 Web: tradeblazer.com From: Theo Hultberg Tolv Sent: Tuesday, December 3, 2019 5:50 AM To: iconara/puck Cc: amiracam; Author Subject: Re: [iconara/puck] Puck for library jar creation (#34) If you need the gems to be in the load path I don't think you can do what you describe. I'm not clear on whether or the application will be booted by JRuby, but I assume it is. In that case I think you could reverse the process: you build your Java dependencies and use the :merge_archives feature of Puck to create a final jar with all the gems, and the Java dependencies. The issue is that if you use shadowJar (I assume you're talking about the Maven plugin here), it won't create a jar that will boot JRuby, which in turn means that there won't be anything that sets up the load path. If you can't do it the way I suggest, you can always look at how Puck sets up the jar and try to replicate that in your build process. It's not that much that needs to be done. Most of the complexity is in dealing with Bundler and building the jar. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.