Skip to content

resolve deps directly (don't create deps.lst)#106

Draft
kares wants to merge 1 commit into
jruby:masterfrom
kares:avoid-deps-lst
Draft

resolve deps directly (don't create deps.lst)#106
kares wants to merge 1 commit into
jruby:masterfrom
kares:avoid-deps-lst

Conversation

@kares
Copy link
Copy Markdown
Member

@kares kares commented May 28, 2026

No description provided.

@kares kares linked an issue May 28, 2026 that may be closed by this pull request
@headius
Copy link
Copy Markdown
Member

headius commented May 28, 2026

I have not looked at the code closely myself but one concern I had was that deps.lst avoids re-resolving dependencies repeatedly. If that is the case it might be something we'd want to have users include in the gem, but again I have not looked into this possibility at all yet.

@kares kares force-pushed the avoid-deps-lst branch from 7aec7a2 to 11045c4 Compare May 31, 2026 11:11
@kares kares force-pushed the avoid-deps-lst branch from 11045c4 to f3942df Compare May 31, 2026 11:14
@kares
Copy link
Copy Markdown
Member Author

kares commented Jun 1, 2026

concern I had was that deps.lst avoids re-resolving dependencies repeatedly. If that is the case it might be something we'd want to have users include in the gem

likely the case, the current approach isn't ideal. deps.lst accomplished "something" in that direction but those deps are still stored with a (hard-coded) M2_HOME.

what jar-dependencies should support would be something like:

  1. resolve dependencies and store them in a known location along-side with the gem (ideally gem uninstall also removes downloaded jar dependencies)
  2. users should have an opt out of storing jar dependencies and jar-deps would attempt to resolve them again
  3. an opt-out of installing/resolving dependencies completely

the first use-case wasn't really supported well. not sure I'll really have the time to do a proper feature development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

More robust handling of failures

2 participants