Author Topic: B1: Gradle project hierarchy - Project without config  (Read 638 times)

Marcel

  • Senior Community Member
  • Posts: 205
  • Hero Points: 25
B1: Gradle project hierarchy - Project without config
« on: August 07, 2018, 01:11:37 pm »
In my hierarchy I have a few projects that do not have their own build.gradle configuration, but rather inherit settings from the root configuration. This is used mainly for small libraries.  And you guessed it, when I try to specifically "build" one of those projects, SE complains that there isn't a build.gradle for it.  Note that the project IS listed in the root settings.gradle file.

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1050
  • Hero Points: 92
Re: B1: Gradle project hierarchy - Project without config
« Reply #1 on: August 07, 2018, 01:32:05 pm »
I'll look into that.  I suspect that we're mistakenly specifying the "-b %rwbuild.gradle" option in the Exec tag of the vpj file for the projects that don't have their own build.gradle.  If you need to work around it for the moment, you could remove that flag from the Exec tags of your .vpj files. 

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1050
  • Hero Points: 92
Re: B1: Gradle project hierarchy - Project without config
« Reply #2 on: August 08, 2018, 03:15:40 pm »
Fixed for the next beta drop.

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1050
  • Hero Points: 92
Re: B1: Gradle project hierarchy - Project without config
« Reply #3 on: August 08, 2018, 05:23:21 pm »
I forgot to mention.  Once you install the next beta, you'll have to regenerate the SlickEdit project files for the projects that don't have a build.gradle file.  You can do this manually by setting the project active, and then running Build -> Gradle Options, and clicking through the wizard.  The other options is to remove all the *.vp* files, and re-import the project with Project -> Open Other Workspace -> Gradle Project File.

Marcel

  • Senior Community Member
  • Posts: 205
  • Hero Points: 25
Re: B1: Gradle project hierarchy - Project without config
« Reply #4 on: August 08, 2018, 07:41:39 pm »
Thanks Patrick.
Will your fix also create the vpj's for subprojects listed in settings.gradle as

include 'dir:projecta'
include 'dir:projectb'

Right now they aren't, and the projects don't show up in the tree.

While I am at it, any suggestions how to pass program arguments to the run task (normal and while debugging)?

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1050
  • Hero Points: 92
Re: B1: Gradle project hierarchy - Project without config
« Reply #5 on: August 08, 2018, 07:58:13 pm »
For beta 2, if you import the root project that has the settings.gradle, you'll get a project for each sub-project, in addition to the root project.  Beta 1 tries to do it, but I've found some bugs since, so it can fail.

I overlooked the argument passing for Gradle.  For debugging, there's a Debug -> "Start with arguments..." menu entry, which is grayed out for gradle.  Build -> Gradle Options will be updated to allow you to set the arguments for a plain execute as well.  I should have that ready for the next beta drop.


patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1050
  • Hero Points: 92
Re: B1: Gradle project hierarchy - Project without config
« Reply #6 on: August 09, 2018, 03:11:50 pm »
Looking into it, I've found there will be some limitations with passing arguments into the execute task for Gradle.  The short version is it will work without changes for new gradle projects created from SlickEdit.  Existing projects imported as Gradle projects will need build.gradle changes to be able to accept run/debug arguments on the fly.

Why the limitation? For the JavaExec task, there isn't a standard way of passing command line arguments to the program being run via Gradle's command line interface.  The program arguments have to be set as the "args" property of the task in the build.gradle file.  The common workaround I've seen for this is to create the JavaExec task in a way that the arguments are read and parsed from an external source. A simple example untroubled by the complexity of real argument parsing would be:
Code: [Select]
task execute(type: JavaExec) {
    classpath = sourceSets.main.runtimeClasspath
    main = "com.test.MainKt"
    args = System.getenv("RUN_ARGS")?.tokenize(' ') ?: []
}

So for the short term, you will need to modify the build.gradle files we didn't generate to change the arguments for a run.  That either means changing "args" manually whenever you need different arguments, or change it to use the (yet undecided) mechanism SlickEdit will use to pass in arguments so you can use the menu entries to pass in program arguments. 


Marcel

  • Senior Community Member
  • Posts: 205
  • Hero Points: 25
Re: B1: Gradle project hierarchy - Project without config
« Reply #7 on: August 10, 2018, 03:00:50 am »
Gradle 4.9 has been released and it supports JavaExec arguments on the command line

gradle run --args 'foo --bar'             (from the relase notes)

This opens the door for a clean implementation in SE and saves me from messing with build.gradle

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1050
  • Hero Points: 92
Re: B1: Gradle project hierarchy - Project without config
« Reply #8 on: August 10, 2018, 01:26:47 pm »
Nice.  I will use that if I detect >=4.9 Gradle then, and the other method for previous versions.  Thanks for pointing that out.

patrick

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1050
  • Hero Points: 92
Re: B1: Gradle project hierarchy - Project without config
« Reply #9 on: August 10, 2018, 08:03:46 pm »
This is in for the next beta.  For Gradle versions < 4.9, it only works for build.gradle files SlickEdit has generated for new projects.  For Gradle versions >= 4.9, it uses the "--args" parameter, and works for new and imported projects. The arguments can be specified in the Gradle Options dialog.  Running the debugger will pick up those options as well, or you can use "Debug -> Start with arguments..." to use different arguments for that debugger session.