Jochen, first, this debate might be getting a bit at the moot side: meantime, I have decided just to slightly improve my scripts to simply add groovy/lib/*.jar to the classpath for the deployment.
It will make installation of new Groovy versions to the servers a bit more difficult than it used to be with -all, but the difference's not that big, and after all, we won't install too many Groovys in there — 3.0.4 definitely, one or two newer ones possibly if they happen to fix some bug important to us. 4.x hardly, too soon for that; and I guess when we do the next refactorisation, there'll be 5 or 6 out :) > On 19 May 2020, at 7:15, Jochen Theodorou <blackd...@gmx.org> wrote: > On 19.05.20 03:53, OCsite wrote: >> Well, thanks, I'll check the thing, though at the first look it rather >> seems to be a tool for a Gradle project owner who wants to move his >> projects into Xcode. Me, I'm precisely the opposite case — I've got >> Xcode projects which I /possibly might/ want to move into Gradle. > > I think you need to explain your deployment situation a bit more. Just > some rough numbers... to how many computers do you deploy The number of servers changes and I am not sure of it (I do just the development, and I work directly with the test servers, but I do not do administration of the deployment sites at all, there are much better people for that :)), but far as I know, at the moment it's five-odd, presuming to go ten-plus in a very near future. > and how many applications? At the moment three of them actively developed plus ten-odd more-or-less legacy ones, just maintained (some of them waiting to massive refactoring and resurrection soon as there's time for that, others waiting to be silently forgotten in near future :)) > All Mac? Most of the servers are, at the moment, CentOS; a couple of them still Macs. As mentioned above, I do not maintain the servers myself, my admin skills are not that great — but I'm told the client has encountered some hard-to-solve problems with newer macOS servers (whilst old ones beginning not to be viable alternative due to security holes which Apple does not fix anymore in the legacy software) which is, I am told, along with easy and reliable virtualisation, the main reason of the move to CentOS. From my point of view there's essentially no difference, just different deployment/extension paths, which our launch script solves automagically based on a couple of environment variables. Anyway, the thing is, we rarely add new functionalities which would need to change the list of JARs, and thus we don't really need an automated dependency management. During the last, ahem... four or five years, far as I can recall without checking the project history files, we added just the aforementioned Fop and Apache POI, and for new apps only switched WOnder 6 to WOnder 7; nothing else. In general, we rather stick with old versions of everything embracing the devil we know (with work-arounds well-tested), instead of continuously upgrading and getting thus fixes of known problems (which we don't really need, for we already have worked around them) for a price of new unknown bugs (which could bit us in our tender parts). Hence, incidentally, also the Java 8, and Groovy 2.4- until very recently. Thus, our set of libraries is pretty at the static side: - WebObjects JARs which never change and never will - FrontBase JAR which did not change for years and hardly will in a foreseeable future - WOnder JARs which change every five-odd years when we decide to embrace a new release (and even that for new apps only) - a couple of external JARs for extra functionalities like Fop or POI. Again, we never upgrade to newer release unless we have to or unless we refactor the whole app - Groovy JAR (now will become all JARs from /lib) as needed by the Groovy version for the particular application. Again, for the reasons aforementioned, until we refactor our older apps, we definitely want to stick with the very Groovy version we tested the app heavily against (2.4.17 for most, 2.3.8 for a couple of older ones). Nevertheless we just now are refactoring one of our apps very heavily, and for it, I'd like to go Groovy 3 (presuming 4 won't be stable enough for some time to come). >> If at all. I still can't see any advantage it would bring to me. It >> would automatically maintain dependencies, which is something I have >> never really needed (at least, not until groovy-all disappeared). > > there have been afaik 2 main reasons to remove groovy-all... > (1) Java module system (JMS). > ... At the same time the dependency on the module name is part of the Java > code now. So if you make one library that depends on groovy-all and one > that depends on groovy-core you are screwed... So I can't anymore freely decide whether to classpath lib/*.jar or embedded/-all.jar to run one and the same app build? Brave new world indeed :( Lucky us we stick with Java 8. Looks like lots of fun awaits us in future when we are forced to go 9 :( > (2) People were asking for a smaller groovy jar for years. I absolutely understand that need for people who embed all the JARs into their applications, and deploy the whole monster. We — perhaps as one rara avis — do otherwise: we strive to put as much of the functionality shared amongst our apps as reasonably possible to the Extensions folder, only referencing those shared JARs in the classpath. Seems much more reasonable to us. > As I understood it, you care not so much about these points. I assume > you do not plan to switch to JMS in the next years at all The more I hear of the thing, the more I intend to dodge it as long as reasonably possible :) >> Besides, I wonder how reliably it could in principle work. Most of the >> JAR-hell problems we have encountered happened when there were more >> versions of the same library and some of them did work OK, some of them >> did not: for example, having added Fop support, we had to >> remove xmlgraphics-commons-2.3.jar which we used before without any >> problem, and had to switch back to xmlgraphics-commons-1.5.jar, which >> works OK with the Fop thing, whilst 2.3 does not[1]. I /do/ wonder >> whether Gradle or any other auto-dependency manager /could ever/automate >> properly and without problems /this/? Is there such kind of information >> anywhere for the manager to do such decisions reliably? > > I am not 100% sure what you mean with "this". „This“ problem of decision which version of the JAR to use so that it works properly, e.g., whether to classpath xmlgraphics-commons-2.3.jar or xmlgraphics-commons-1.5.jar. It's actually a bit at the difficult side: the information of the version used for compilation does not suffice, you need also information of inter-version backward compatibility and breaking changes. This is what the aforementioned OpenStep frameworks did provide, but JARs — far as I know — do not; thus, — again only far as I know (and I can be easily wrong!) — such decisions can't be automated reliably with JARs and must be left to the user, who would force versions manually. (That's essentially the gist of the cesspool what's usually called JAR-hell, far as I can say.) In that case it's infinitely easier not to use a semi-automated-tool-which-needs-hints-anyway-otherwise-doesnot-work-well, and simply put the JARs needed to the classpath (more or less) manually. (Perhaps the JMS thing strives to solve this very problem, I don't know. Even if so, knowing Java, I don't believe they would to that right — almost nothing they ever did :( ) > Right now you manage dependencies manually I assume. Precisely. Conceptually, I create manually the full contents of the classpath (employing a couple of simple scripts which help e.g., to find JARs in WO/WOnder frameworks or to auto-add proper JAR /now will be JARs/ for the Groovy the app has been built with etc., but that makes no difference in principle). And, very rarely it brought any problems (about the only cases I can recall were those when we had to try different versions of a JAR to find the one other JARs work with, like the aforementioned xmlgraphics 2.3 vs 1.5; and as I wrote, I would be really surprised if this could be automated reliably — could it?) Thanks and all the best, OC
