malliaridis commented on code in PR #2706:
URL: https://github.com/apache/solr/pull/2706#discussion_r1775253658


##########
help/dependencies.txt:
##########
@@ -29,60 +29,126 @@ testImplementation - makes a dependency only available for 
test  classes.
 Adding a library dependency
 ---------------------------
 
-Let's say we wish to add a dependency on library "foo.bar:baz" in
+Let's say we wish to add a new dependency on library "foo.bar:baz" in
 version 1.2 to :solr:core. Let's assume this library is only
-used internally by the project. The :solr:core project is configured
-by solr/core/build.gradle and we would add (or modify) the dependency
-block as follows:
+used internally by the project. For new dependencies, we would add
+the dependency and its version to gradle/libs.versions.toml first:
+
+[versions]
+...
+foo-bar-baz = "1.2"
+...
+
+[libraries]
+...
+foo-bar-baz = { module = "foo.bar:baz", version.ref = "foo-bar-baz" }
+
+Note that the used names separated by dashes are later referenced with dots
+instead of dashes, but more on that later.
+
+The chosen name for the module should more or less reflect the module's
+group name and module id in a way that it groups related dependencies under
+the same "prefix" (see below). There is no specific convention here and
+group prefixes for domain names like "com" and "io" are avoided, as they
+do not add any value and increase the size of the reference / alias name.

Review Comment:
   >  You can have a version catalog with multiple versions of the same 
artifact (with identical coordinates) - how would it choose the right one?
   
   That's interesting, I didn't know that. 🤔 I guess it would follow the 
version resolution strategy like usual in that case, but I think even if that 
is the case, this is not what we want probably.
   
   I guess going with the aliases is the best option we have so far.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org

Reply via email to