Sebb: I will try again on a new VM and write them up, perhaps on Monday. I doubt it would have done it automatically, but it probably would have been quicker to solve. i.e. add: compile 'org.openjfx:javafx-controls:11' to dependencies and Gradle + IDE automatically then work. Rather than: finding the required jar, copying it to the lib folder and manually adding it to the IntelliJ project.
Philippe: I do not think it would be able to handle the dependency management without also doing the compilation (but I could be wrong). For Darcula, there are options https://stackoverflow.com/a/34327202 or https://stackoverflow.com/questions/17123606/how-to-download-external-files-in-gradle However, the more we dig the more we might have to change the status quo, it seems the git discussion is similar, i.e. now that we might want to use a different tool we should probably use it in the way it was intended to solve our problems rather than simply use the same ways of working. Thus, unfortunately, making these even more difficult than just the initial technical challenge, but, in my mind they will be well worth it in the long term. Graham On Sat, 23 Feb 2019 at 14:59, Philippe Mouawad <[email protected]> wrote: > > Thanks Graham for those very interesting insights. > > Is gradle able within its dependency management to handle case where > dependency is not a Maven nor Ivy one ? > > - > > https://docs.gradle.org/current/userguide/introduction_dependency_management.html > > I guess it would be possible to do it with custom coding (download artifact > and put it in local maven repository, but if it's built-in it would be > better. > > We have Darcula which is in this case. > > Regarding your proposal, do you think it would be feasible as a first step > to delegate dependencies management to Gradle ? > I think it would possibly improve already developer experience. > > Thanks > > > On Sat, Feb 23, 2019 at 11:50 AM Graham Russell <[email protected]> wrote: > > > +1 to move to Gradle. > > > > I think the biggest benefit of moving to Gradle is that it will lead to > > more contributions. > > > > People will no longer have to fight to get the code to import into an IDE > > (i.e. IntelliJ), compile and successfully run tests. > > I've just got a new laptop and it took me too long to get JMeter just to > > import and compile in IntelliJ, there were at least 5 different, > > non-standard steps to get it to work. One of them was manually including > > JavaFx as it's no longer part of OpenJDK and not download as part of ant > > download_jars. > > > > The other benefit is that it should improve the speed at which we can > > build, test and therefore make changes. > > > > I think, regardless if we move to Gradle, that a few people with a good > > knowledge of ant and our current build.xml should make it easier to > > understand and optimise it: > > 1. comment anything which might not be obvious to someone new to ant and > > 2. remove (or simplify) anything which is no longer required > > > > We could switch JMeter to Gradle right now by using > > https://docs.gradle.org/current/userguide/ant.html > > e.g. using a build.gradle file with > > > > ant.importBuild("build.xml") > > ant.lifecycleLogLevel = AntBuilder.AntMessagePriority.INFO > > > > Then start to move the actions into the Gradle file, although it seems > > things are too interconnected for this to be an easy job. > > > > A separate release script like Kafka is a very good idea. It doesn't bloat > > the build file and encourages automation and even simplification of the > > important release process. > > > > Thanks > > > > Graham > > > > On Sat, 23 Feb 2019, 03:25 Vladimir Sitnikov, <[email protected] > > > > > wrote: > > > > > Apache Kafka might be relevant for the inspiration. > > > They somehow release Apache-compatible artifacts, and they use Git, > > Gradle. > > > > > > https://github.com/apache/kafka > > > https://github.com/apache/kafka/blob/trunk/release.py > > > > > > Vladimir > > > > > > > > -- > Cordialement. > Philippe Mouawad.
