[
https://issues.apache.org/jira/browse/SOLR-13915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16976190#comment-16976190
]
Dawid Weiss commented on SOLR-13915:
------------------------------------
Ok, I understand how the build works in Solr now, I think. It is a great pity
that source files are intermixed with output files and shuffled around the
source tree. This requires many .gitignore rules (and they're very ugly) and
makes the separation between actual "sources" and "outputs" kind of hazy.
I updated the server/ build file so that `gradlew -p solr/server assemble`
collects jetty dependencies, logging, etc. but I'm not really convinced
assembly in-place is such a great idea. As an example: in-place assembly makes
it hard to synchronize resources rather than copy them (synchronization deletes
any resources not in the source collection; for example it'd remove dependency
JARs if a dependency is removed from build file).
The webapp and other artifacts still need to be put together but the server
build file provides an example how things can be done.
> Figure out the equivalent of "ant dist server" in the Gradle build
> ------------------------------------------------------------------
>
> Key: SOLR-13915
> URL: https://issues.apache.org/jira/browse/SOLR-13915
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Build
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> Who knows? Perhaps this already happens in the Gradle build and I just don't
> know the magic.
> Whether we actually require an equivalent of both targets is an open
> question. The goal is to be able to execute some target, then execute
> "bin/solr start".
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
