dweiss commented on pull request #1972: URL: https://github.com/apache/lucene-solr/pull/1972#issuecomment-706949342
Well, yes. I know it's tempting to use gradle's "ready-to-use" plugins but the situation is different when you have a stand-alone project and a multi-module aggregate. Let me explain. gradle plugins add tons of stuff (configurations, dependencies, tasks, conventions) and hide what's going on behind the scenes. This has pros and cons. While you can use the automatically-added 'run' task, the subproject is also populated with stuff that will increase the overall build time (like the stand-alone distributions on assemble) and may conflict with other parts of the multi-module build. For this reason I typically prefer to be explicit about packaging and distribution aspects, even if some things need to be done manually. My preference would be to just keep using java-library and add corresponding entries to the JAR's manifest; the "run" task is still achievable with plain java-library - Lucene's Luke configuration has an example of how this can be done. Please do as you please though - I don't even know what this particular contrib is :) As for your question why not all JARs are copied - this is a larger question that applies to the current Solr packaging. I tried to emulate the way ant worked (in packaging.gradle) - this means copying the module's "unique" set of JARs to avoid duplication. This isn't easy and makes configuration management fairly hairy. I think stand-alone tools like prometheus-exporter or luke should have full executable distribution in the binary release - even if this means duplicating some JARs (including Lucene JARs). This makes it easier to reason about what they need, makes the configuration simpler... at the cost of increased distribution size. The alternative is to hand-edit the build and include what's needed or hand-edit the scripts to point at the right JARs. I'm really not sure which way is right (I believe the full set of artifacts required to run a stand-alone tool is better but it's my personal opinion). ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
