[
https://issues.apache.org/jira/browse/SOLR-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17410444#comment-17410444
]
Dawid Weiss commented on SOLR-15614:
------------------------------------
Hi Chris. Sorry for the delay.
bq. it does seem plausible that having plugins not locked to specific versions
could cause problems with reproducible down the road.
Gradle plugins need to be configured with a particular version and they declare
specific versioned dependencies too (the exception are built-in plugins but we
lock gradle to a particular version, so it's not an issue). The dependencies
from libExt are not listed in the versions.lock file but (I strongly believe)
they are ultimately picked up from the configuration palantir creates...
Otherwise gradle would fail with an exception saying no version was declared
for a dependency...
I don't know why your patch behaves the way it does - it's fairly hairy stuff
and the palantir's plugin only makes things more complex to reason about (but
it does have value). I did add this issue to the pile of things I should take a
look at but I can only do this in my spare time and there's not much of it
recently. Please leave it open though - I will eventually take a look.
> versions.lock is not including all jars in all configurations - ex:
> server.libExt
> ---------------------------------------------------------------------------------
>
> Key: SOLR-15614
> URL: https://issues.apache.org/jira/browse/SOLR-15614
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Priority: Major
> Labels: gradle
>
> Found while working on SOLR-15610: There are (at least one) gradle
> "configurations" in our build system that depend on jars which are overlooked
> by the {{versions.lock}} logic provided by gradle's palantir plugin
> validation logic.
> We should either simplify the configurations to work better with palantir, or
> find some way to force palantir to consider all configurations...
> {quote}I'm not sure. Looks like this configuration is not included in what
> palantir's plugin considers for resolution?
> [https://github.com/palantir/gradle-consistent-versions#versionslock-compact-representation-of-your-prod-classpath]
> "The lockfile sources production dependencies from the compileClasspath and
> runtimeClasspath configurations, and test dependencies from the
> compile/runtime classpaths of any source set that ends in test (e.g. test,
> integrationTest, eteTest)."
> But then it says that the constraints are applied to all configurations
> (that's why it works, I guess):
> "By default, this plugin will apply the constraints from versions.props to
> all configurations."
> ...
> Part of the problem is definitely that libExt is not part of the project's
> Java's classpath. This was done on purpose - libExt collects JARs that
> shouldn't be visible on classpath by default but are part of the server. I
> think this could be cleaned up and be moved to runtimeOnly configuration...
> but I'm not sure what consequences this will have since this is really a bit
> convoluted part of the build (trying to simulate what ant did).
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
