Use Cases

Scenarios for various ways Jar dependencies need to be handle for JRuby applications, libraries, etc.

TODO: Add some app related scenarios, these are all for Gem packaging

Gems that require Jars (Gem -> Jar)

User needs a Jars dependences for a Gem.

1. User creates a new Gemspec
2. Sets Jar coordinates as a dependency in the Gemspec
3. Configures Gemspec to download the Jars when the Gem installs

In this scenario, we would not need a Jarfile.lock. The user does not care about transitive dependencies and/or takes the responsibility to set all required Jars in the Gemspec. The caveat is all the Jars must be either installed locally or either in the core Maven repo.

User needs jars and their transitive dependencies for a Gem

1. User creates a new Gemspec
2. Sets a Jar coordinates as a dependency in the Gemspec
3. User locks the Gemspec to create a Jarfile.lock
4. Configures Gemspec to download the Jars when the Gem installs

In this scenario, we do need a Jarfile.lock. The transitive dependencies we be generated from the Gemspec and saved as the Jarfile.lock. Same caveat as above.

User needs Jars from a custom repo

1. User creates a new Gemspec
2. User creates a Jarfile with Jar coordinates and Remote repository urls
3. User locks the Jarfile to create a Jarfile.lock
4. Configures Gemspec to download the Jars when the Gem installs.

In this scenario, we need a Jarfile.lock. The transitive dependencies we be generated from the Jarfile and saved as the Jarfile.lock, including the remote repo urls.

User needs Jars from Remote Repo and Jar packaged with the Gem

1. User creates a new Gemspec
2. User creates a Jarfile with Jar coordinates, Remote repository urls, and an override for the package Jar
3. User locks the Jarfile to create a Jarfile.lock
4. Configures Gemspec to download the Jars when the Gem installs.

In this scenario, we need a Jarfile.lock. The transitive dependencies we be generated from the Jarfile, using remote repo urls, with an override to use the Jar packaged with the Gem and saved as the Jarfile.lock.

User uses dependencies from a pom.xml for a custom Jar they want to package with the Gem

1. User creates a new Gemspec that includes path to custom Jar
2. User creates a Jarfile
3. User adds the pom.xml path as a dependency to Jarfile
4. User adds custom Jar file as a dependency to Jarfile
5. User generates the Jarfile.lock
6. Configures Gemspec to download the Jars when the Gem installs.

In this scenario, dependency information is pulled in from a pom.xml. This should include dependencies, remote repositories, and anything else that will help resolve transitive dependencies for the Jarfile.lock.

User changes the local install dir

User needs to install Jars into a configured path, not to the default Maven ~/.m2/repository. Basically we would allow the end user of a Gem to specify were the Jars should be installed. This causes a lot of problems for the 'auto downloading of Jars' for a Gem. If a user changes the install path, all existing Gems would no longer have there required Jars. We could get around this by re downloading all the required Jars when the user locks the Jarfile. This falls into my "everything should be configurable" idea, where there are hierarchy of configurations: Defaults < Gem Configurations < Local Configurations. A User could set the local repo and it would be enforced on all Jars. This makes me think that a DependencyManager of some kind might be needed for runtime to handle merging configurations.

MG - I am not sure how important this is. If we reuse the existing Maven Repo path, then we will need the ability to change it. If there is a standardized path relative to RubyGems, this may be moot.

Gems that require Gems that require Jars (Gem -> Gem -> Jar)

User needs a Gem that requires a Gem that has Jar dependencies

1. User creates a Gemspec
2. User adds a dependencies for a Gem that requires another Gem that requires a Jar (Gem -> Gem -> Jar)

In this scenario, the issue is the Gem package may not know their is a Jar dependency from the Gem -> Gem -> Jar. What needs to happen is the Gem that has the Jar dependencies notifies the runtime that the Jar dependencies need to be placed in the classpath.

User needs a Gem that requires a Gem that has Jar dependencies

1. User creates a Gemspec
2. User adds a dependencies for a Gem that requires another Gem that requires a Jar (Gem -> Gem -> Jar)
3. User creates a Bundler Gemfile and uses gemspec
4. User generates a Gemfile.lock

In this scenario it should function the same as the previous. The addition of Bundler does not help determining how to load the classpath.

User needs multiple Gem that require Gems that have conflicting Jar dependencies.

1. User creates a Gemspec
2. User adds a dependencies for a Gem that requires another Gem that requires a Jar org.slf4j:slf4j-api:jar:1.6.6
3. User adds a dependencies for a Gem that requires another Gem that requires a Jar org.slf4j:slf4j-api:jar:0.9.1

In this scenario, there a conflict from the Gem -> Gem -> Jar. One Gem depends on an earlier version and might not work with the newer version of the Jar. The other gem uses a newer version of the Jar, which has features that does not exist in the older version.