Replies: 3 comments 1 reply
-
Hi @leonard84, sorry for the late reply and thank you for the suggestions. Unfortunately, I'm not very experienced with Gradle, so can't really grasp the impact of these changes. @iRebbok has written the first version of the Gradle plugin and @edward3h has modernized it to the latest Gradle best practices (by then :-)). Maybe one of you could have a look at the proposed changes? As for your first question, I think the target directory for the precompiled classes is set here and can be configured by the user by setting the |
Beta Was this translation helpful? Give feedback.
-
Hi @leonard84 , For the directory properties it would be good to maintain backward compatibility. Maybe that is possible with wrapper methods. If not it will be a very small fix to make on an affected build file. |
Beta Was this translation helpful? Give feedback.
-
@casid I've seen a few issues relating to the Gradle plugin. Could you add a label "gradle" to them? |
Beta Was this translation helpful? Give feedback.
-
I've noticed that the plugin puts the precompiled classes in
<project>/jte-classes
instead of<project>/build/jte-classes
, as is customary for any generated output.Is there a specific reason for that, or can this be fixed?
While looking at the plugin code I've noticed some other issues:
JteTaskBase
is accessing the extension to read and store configuration. This does not comply with idiomatic plugin design in Gradle. ATask
should have its own properties, which are then wired up usingprop.convention(extension.prop)
for the default registered task via the plugin. This makes it possible to declare another task with a different configuration.JteExtension
usesProperty<Path>
instead ofDirectoryProperty
to for properties meant as directoriesFixing the latter can't easily be done in a backward-compatible way.
Would you accept pull requests that address these issues?
Beta Was this translation helpful? Give feedback.
All reactions