This is maybe slightly specialized, but I’ve been trying to figure this one out.
I’m building a simple SFTP module. I’ve built it around the Scripting module example on the Inductive engineering Github.
When its built, and installed on a system the sftp library(jsch or sshj in this case) aren’t included in the module no matter how I try to build the thing.
This is a fairly simple implementation written in Kotlin. Based on everything I’ve looked through this SHOULD work, but I can’t figure out why it doesn’t.
It installs correctly, all of the metadata is there, the only thing that seems to be breaking is the actual call of the sftp library jar, which cannot be found at runtime.
I’m sure I’m missing something obvious. Any thoughts would be awesome.
Looking at the buildscripts, I think you’re missing a key part of the module plugin: the toModl dependency configuration, used in place of ‘implementation’ or ‘compile’. This configuration is required to ‘mark’ the dependencies for collection and inclusion into the final modl file. It also adds the dependencies to the module.xml that is generated. So you can change implementation dependencies to toModl and see if that fixes the issue.
That said, the plugin you are using (and indeed the one used in our sdk examples) is on the way out and won’t see any further development. It’s not usable for more-current (7.x) versions of gradle due to the use of deprecated/removed apis, and it doesn’t support all the latest features.
The configuration is quite similar, but will require some changes. The benefits are that it’s open source, uses/supports current versions of gradle (as well as more recent gradle features such as incremental assembly and build-caching), and will see continued support/development. It’s not yet at its first ‘final’ release version, but it’s published to the Gradle plugin repository and we’re using it internally for builds, so I feel pretty comfortable suggesting it in place of the ‘old’ one. I’d also suggest migrating build.gradle to build.gradle.kts as I find it’s much nicer to deal with, but it’s not strictly necessary.
The new plugin, similar to the old one, uses ‘custom’ dependency configurations to mark implementation or api dependencies that should be included in the modl (use the java-library plugin instead of plain java).
I haven’t quite finished testing the changes made to switch out the plugins on the public sdk examples, but you can see it on this branch if you’d like to see example configuration.
But take a look at the README on the new plugin/“module tools” repo and let me know if you have any questions.
Hey, thanks for your input! I’ve tried to figure out the migration to build.gradle.kts and using the newer plugin. I can get the plugin to setup, but then the toModl isn’t available in the various scopes(gateway, designer etc) and intellij keeps refusing to build saying it can’t find the method.
I’ve implemented a hybrid solution for now using build.gradle at the top level and build.gradle.kts within the various scopes. This isn’t ideal, and I’ll keep trying the new module as it gets updated. The hang up that I’m facing right now is: this build works, and changing to the new module breaks it.
The toModl option isn’t very apparent in your documentation and I don’t think its used in any of your examples. That might be worth referencing in some way that makes it apparent that is the correct route to follow. The only project in that branch using the Gradle plugin is the perspective-component module correct? I didn’t see any other implementations to base stuff off of, and everything I’ve tried breaks the build other than this current solution.
The other solution I found was to create a ‘fatjar’ using some additional code. Wasn’t perfect but it got the job done. toModl is much nicer.
Sorry I wasn’t clear enough - the toModl is the OLD plugin configuration. The new plugin uses modlApi and modlImplementation. From Ignition’s perspective, these two have the same result. The difference is largely in whether or not a project exposes a dependency (and its transitive dependencies) to consumers, as well as how some tools like IDE’s might resolve the classpath.
So in the case of a ‘common’ project that has a dependency you want to be resolved by consumers of the common project, you’d want to use the modlApi. If the dependency is just an implementation detail that you don’t want/need consuming projects to get access to, use modlImplementation. The java-library plugin docs explain the behavior in more detail. Keep in mind that Ignition itself only cares about what is in the modl, and what entries are in the module.xml, so the differences between modlApi and modlImplementation are for the build tooling, dependency resolution, and IDE environment: not Ignition.
The new configurations are documented in the Readme, under Usage, point #4.
Sorry I skipped this - but yes, that is currently accurate. We'll be moving at least some of the projects over to gradle from Maven -- specifically those which require front-end (nodejs) build processes. But as of right now, the tentative plan is to leave the remaining example modules as maven, since we still support maven's use, and there are folks who prefer it.
lol. There’s nothing wrong with Maven - it’s battle tested and there’s plenty of docs out there. It’s just quite rigid, for better or worse. I prefer Gradle, but also would be the first to recommend Maven to people who have simple needs and don’t want to take the time to actually learn the tool. That said, with Gradle’s kotlin buildscripts being nicely integrated and mature now, the ease of use and dev-time feedback largely negates what was one of Maven’s biggest benefits over Gradle.