Add the target-artifact of pom.xml to load path with LockJar.load

[Hachmaninow]

We are using lock_jar in several mixed-language java-jruby-projects. In such a project we use the pom instruction in the Jarfile and lock_jar manages to add all the dependencies to the load path when we call Lockjar.load. Unfortunately the classes contained directly in the java-part of this project are not added to the load path and are thus not available from the ruby code.

Are we missing something or is this a conceptual limitation of lock_jar we have to deal with manually?

[Michael Guymon]

So you are using a pom in a Jarfile and you want to access to the classes that are compiled to the local workspace or access to the packaged target for the pom?

[Hachmaninow]

Thank you for this reply and the work on lock_jar!

Currently we are using the second approach and require the jar file manually from the target folder. That works, but feels inconvenient, as the dependency has already been stated in the Jarfile.

In an ideal world even both approaches should work:

1. In the dev-environment use target/classes/-folder (should be supported by jruby afaik)
2. otherwise use the jar-file from target/

But that's a tall order. ;-)

[Michael Guymon]

What about using groups, something along the lines of

group 'development' do
  map 'the:packaged:jar:6.0.35', 'target/classes'
end

group 'production' do
  jar 'the:packaged:jar:6.0.35'
end

When you call LockJar.load, you would have to load the appropriate groups

 LockJar.load ['default', 'development']

---

map is an undocumented part of the Jarfile that allows a artifact to be mapped to a directory or another artifact. It should work, just needs some additional testing

[Michael Guymon]

For that example to work,map will need to be updated to support groups.

[Hachmaninow]

Hi,

thank you for the suggestion regarding map, which we were not aware of. The feature works, as described (without group), but that's fine for us during development.

The more 'severe problem' is with the explicit jar instruction to add the project-jar to the load path. As shown in your example this is usually a versioned file and the number originates from our pom.xml. That way the update process includes the following steps:

1. change version in pom
2. package jar
3. change version in Jarfile
4. update Jarfile.lock (at the moment call 'bundle install' with lockjar-bundler integration enabled)

Currently we disable versioning of the jar to be able to render steps 3+4 unnecessary. Maybe it's a matter of taste whether the primary Java artifact of a pom should be added to the load path implicitly or not. We would like it, but it's not such a big deal right now!

Kind regards,
Björn

[Michael Guymon]

There is a bit of a gap in using a pom in a Jarfile. You can reference a pom in the Jarfile , for example - pom ext/pom.xml

This will load all the dependencies for the pom. Unfortunately it does not load jar for the actual pom, which makes it almost useful. LockJar expects to be able to resolve deps from a Maven repository. A pom project will have its package installed in the target dir normally. For it to work, there will need to be a contract of sort sort that a local pom will be packaged at an expected place.