I agree, using https://stackoverflow.com/a/34327202 seems the best to me where we just use a customised Ivy repo.
Thanks for sharing that info about freemaker! On Sat, 23 Feb 2019 at 17:20, Woonsan Ko <woon...@apache.org> wrote: > > On Sat, Feb 23, 2019 at 12:05 PM Woonsan Ko <woon...@apache.org> wrote: > > > > On Sat, Feb 23, 2019 at 11:49 AM Philippe Mouawad > > <philippe.moua...@gmail.com> wrote: > > > > > > On Sat, Feb 23, 2019 at 5:24 PM Graham Russell <gra...@ham1.co.uk> wrote: > > > > > > > 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. > > > > > > > I agree, did I meant something else for you (in which answer ?) ? > > > It is just that Darcula is just not available in Maven Central. > > > I just wanted to highlight this specificity to have it mind when > > > migrating. > > > > Should be possible with a either flatDir (after download) or custom > > repository setting: > > - https://docs.gradle.org/current/userguide/repository_types.html > > And, after searching on the internet, I found two approaches to > download files in Groovy DSL: (a) use Ant! [1] ;-), (b) another AL'ed > download helper module [2]. > > BTW, also take a look at FreeMarker v3 (not released yet, still in > dev) branch's README about IDE setup instructions (probably many > already knew, but might be useful...): > - https://github.com/apache/freemarker/tree/3#ide-setup > (FreeMarker has a very complex setup in its Ant build in v2 the > official one, including JavaCC, separate unit tests with different > incompatible JVM or dependencies, ...), but FM3 has migrated from Ant > to Gradle, which works fine even if we are not done yet regarding > Apache Release artifacts generations.) > > Regards, > > Woonsan > > [1] > https://stackoverflow.com/questions/23023069/gradle-download-and-unzip-file-from-url/34327202 > [2] https://github.com/michel-kraemer/gradle-download-task > > > > > Woonsan > > > > > > > > > > > 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. > > > > > > > Agreed > > > > > > > > > > > > > > > Graham > > > > > > > > On Sat, 23 Feb 2019 at 14:59, Philippe Mouawad > > > > <philippe.moua...@gmail.com> 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 <gra...@ham1.co.uk> > > > > 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, < > > > > sitnikov.vladi...@gmail.com > > > > > > > > > > > > > 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. > > > > > > > > > > > > > -- > > > Cordialement. > > > Philippe Mouawad.
