BTW about @Grab, bear in mind that you can tell @Grab where to put/take its
dependencies from:
groovy -Dgrape.root=./lib my_script.groovy
So every project can have its dependencies in the project's structure.
Regards
Mario
El jue., 20 dic. 2018 a las 10:44, Paul Moore ()
escribió:
> I can understand that logic - there are quirks I've hit with the fat
> jar approach, but because I made the fat jar myself, I'm OK with just
> assuming it's a weirdness that I can either live with or investigate.
> But if it happened with a supplied jar, I'd feel that I should report
> the problem (even if I could work around it) in case it hit others,
> too. So that's an extra burden on the developers, as you say.
>
> Having an uber jar in the zip distribution would have solved my use
> case. Or even just a recipe in the documentation explaining how to
> build an uber jar for yourself. If the Gradle script I posted here
> earlier is of any help, feel free to use it.
>
> Paul
>
> On Thu, 20 Dec 2018 at 00:44, Paul King wrote:
> >
> > We don't want to publish a fat jar to maven because it will cause
> problems that we will continually be asked about but perhaps having an uber
> jar within the zip distribution might be something we could look at. I
> suspect over time though that even that could be problematic.
> >
> > On Thu, Dec 20, 2018 at 8:46 AM MG wrote:
> >>
> >> Hi,
> >>
> >> out of curiosity (and because having a fat jar again might be
> >> conventient at some point in the future in my work environment (also no
> >> internet access)):
> >>
> >> This solution proposed by Keith does not work
> >> https://github.com/gradle/gradle-groovy-all
> >> ?
> >>
> >> Cheers,
> >> mg
> >>
> >>
> >>
> >> Am 19.12.2018 um 23:33 schrieb Paul Moore:
> >> > On Wed, 19 Dec 2018 at 21:23, James Kleeh
> wrote:
> >> >> Paul,
> >> >>
> >> >> The best solution is to use Maven or Gradle to create an all-in-one
> (fat) jar that you can ship and run with java -jar
> >> >>
> >> >> Gradle has a shadow plugin and Maven has a shade plugin to do just
> that.
> >> > Thanks. I'd come to the conclusion that Gradle was likely the solution
> >> > I should be looking at, and I've spent the evening trying to set up a
> >> > basic Gradle script that does what I want. After a lot of
> >> > experimentation, I came up with the following, which seems to do what
> >> > I want:
> >> >
> >> > -- start build.gradle --
> >> >
> >> > version = "0.1"
> >> >
> >> > configurations {
> >> > deploy
> >> > }
> >> >
> >> > dependencies {
> >> > deploy 'org.codehaus.groovy:groovy-all:2.5.4'
> >> > }
> >> >
> >> > repositories {
> >> > jcenter()
> >> > }
> >> >
> >> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
> >> > dependencies") {
> >> > from configurations.deploy.collect { it.absolutePath }
> >> > into "dest/lib"
> >> > }
> >> >
> >> > task copy(type: Copy, group: "Custom", description: "Copies sources to
> >> > the dest directory") {
> >> > from "src"
> >> > include "*.groovy"
> >> > into "dest"
> >> > }
> >> >
> >> > task deploy(type:Zip, group: "Custom", description: "Build a
> deployment zip") {
> >> > dependsOn copyDeps
> >> > dependsOn copy
> >> > from "dest"
> >> > setArchiveName "${project.name}-${project.version}.zip"
> >> > }
> >> >
> >> > -- end build.gradle --
> >> >
> >> > It doesn't create a fat jar yet, but I can look into setting that up.
> >> > The various existing plugins seem to be dependent upon the
> >> > infrastructure set up by the java plugin, which I don't really
> >> > understand (or need, as far as I can tell) so they may not be of much
> >> > help. But I'm not sure what I need to do yet to write my own.
> >> > Something simple like
> >> >
> >> > task customFatJar(type: Jar) {
> >> > dependsOn copyDeps
> >> > baseName = 'all-in-one-jar'
> >> > from "dest/lib"
> >> > }
> >> >
> >> > gives me an "all-in-one-jar.jar" that contains the dependency jars
> >> > directly included, rather than being unpacked. So there's more I need
> >> > to do here...
> >> >
> >> > Paul
> >> >
> >>
>
