I woke up early this morning and thought I could put my time to use writing a simple Gradle project that demonstrates how effective it can be at getting a project up and running; https://github.com/andyjduncan/gradle-example
Cloning a repository and bootstrapping the whole build process with nothing more than a JDK still seems magical to me at times. especially when doing something like exploring a new CI tool or something. Sure, there's a steep learning curve initially, but it pays for itself many times over. Hopefully this is of use to someone, even if that's just me next time I forget how to start a basic project. Andy On Tue, May 19, 2020 at 8:02 AM Mauro Molinari <mauro...@tiscali.it> wrote: > Il 18/05/20 18:47, OCsite ha scritto: > > To write and maintain my own launch script takes about one thousandth time > and effort as compared with learning a whole new ecosystem which I do not > need at all (well, perhaps now for the first time and for the one and one > sole thing, i.e., creating my own groovy-all, which *should* be part of > the distro). > > IMHO Learning Gradle to build a simple Groovy project does not imply > learning "a whole ecosystem". > > By the way: by using Gradle I think I've never used groovy-all even when > on 2.4.x. Never needed to bring it all with my application. ;-) > If you embed all libraries and each your app is a multigigabyte monster, > then of course. If I embedded complete groovy/lib to my application, I > would not need groovy-all in my Extension folder either; but that would be > one terribly wrong engineering, as detailed above. > > "multigigabyte monster" is a hyperbole ;-) > > Some tens of megabytes for complex webapps with ~120 dependencies (either > direct or transitive) is reality. I don't think this is a huge problem > nowadays, it of course depends on what you're targeting. > > In any case I can hardly follow you. You say you don't want to embed all > your dependencies into a fat JAR or into a lib directory for each of your > applications, because you have many dependencies and you don't want to > duplicate them among your applications. But at the same time you're > complaining because you'll now need I guess 2 or 3 small Groovy JARs rather > than one fat JAR. It sounds like a contradiction to me. I can't understand > what is stopping you from treating Groovy just like any other dependency of > your project, like the mentioned fop, or xmlgraphics-commons, or any > logging library you may use, or a JDBC driver, or whatsoever... > > If the problem is "how do I know which Groovy JARs I need", perhaps you > may again use Gradle to build the mentioned ZIP file, then look into the > lib directory of that JAR and you'll discover all the JARs (including > Groovy ones) that your application actually depends on, either directly or > transitively. Then you can take what you need to adjust your deploy and > share JARs among all your applications if you need to follow this route. > > Mauro >
