[
https://issues.apache.org/jira/browse/SOLR-15614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408423#comment-17408423
]
Chris M. Hostetter commented on SOLR-15614:
-------------------------------------------
I should point out: we know that this is happening with dependencies in the
{{libExt}} configuration of the {{server}} module ... it's possible there are
other configurations equally affected?
I tried to see if i could parse out the output of {{./gradlew dependencies}} to
genera a list of what was missing - but realized this problem evidently effects
it as well (which makes sense since i'm guessing it's the same gradle plugin
under the covers)...
{code:java}
# note that patch from SOLR-15610 is applied when i run this...
hossman@slate:~/lucene/solr [j11] [*main] $ grep log4j-layout-template-json
solr/server/build.gradle && ./gradlew dependencies | grep
log4j-layout-template-json | wc -l
libExt 'org.apache.logging.log4j:log4j-layout-template-json'
0
{code}
...but evidently a few things _are_ listed in {{./gradlew dependencies}} which
do *NOT* show up in {{versions.lock}} (assuming i didn't make a silly scripting
mistake) ...
{code:java}
hossman@slate:~/lucene/solr [j11] [*main] $ ./gradlew dependencies >
/tmp/deps.txt
hossman@slate:~/lucene/solr [j11] [*main] $ diff <(perl -nle 'print $1 if
m<^([^: ]+:[^: ]+)>' versions.lock | sort -u) <(perl -nle 'print $1 if m<([^:
]+:[^: ]+)>' /tmp/deps.txt | sort -u | grep -E -v '(solr|buildSrc):')
86a87
> commons-lang:commons-lang
143a145
> net.java.dev.javacc:javacc
230a233,235
> org.apache.rat:apache-rat
> org.apache.rat:apache-rat-core
> org.apache.rat:apache-rat-tasks
258a264
> org.eclipse.jdt:ecj
{code}
...it seems like some of those _may_ be problematic from a reproducible build
standpoint?
> 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
