Am 24. Februar 2019 15:55:23 MEZ schrieb sebb <seb...@gmail.com>:
>On Sat, 23 Feb 2019 at 16:24, 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.
>
>If the JavaFx jar is not being downloaded, then it seems to me that is
>a bug in the current Ant build.
>Fixing that would also involved updating eclipse.classpath.
>In which case it should be treated the same as all the other
>dependencies.
JavaFX is included in Oracle's Java 8 and that has been used for compilation of
jmeter in the past. The ant file checks for the existence of JavaFX and
compiled the dependent component only if JavaFX is detected.
As JavaFX was removed from later oracle JDKs, we discussed removal of the
dependent component, but decided to keep it for the moment.
We haven't done any work to include openjfx yet.
Felix
>
>> 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
>> <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.
