Refine Gradle "quick build"

[AdamBJ]

We've now got a rough quick build working (by quick build I mean a replacement for ant -Dmyenv=local -f build.umple.xml codegen umpleParser rtcpp umpleSelf compile packageJars). We now need to refine the build and fix a few critical issues.

1. First, we're still getting intermittent build failures due to the way Umple is generating Java from the Umple source. As documented in Intermittent Umple compilation error breaking Gradle quick build #17, this is probably because the Gradle build invokes the Umple jar programmatically rather than from the command line. Intermittent Umple compilation error breaking Gradle quick build #17 needs to be closed before this issue is.

2. Second, the build in general needs a cleanup. There's some duplicate code that could be refactored, and the build could use some more comprehensive comments to help new people get up to speed.

• Remove the custom build file naming in settings.gradle. We want each build file to be named build.gradle.

• Rewrite the portion of the build that deals with ivy dependencies to be more "Gradle-like". See this tutorial: Rewrite the ivy file using: https://docs.gradle.org/current/userguide/artifact_dependencies_tutorial.html

• Refactor the UmpleToTL build files to reduce duplicate code. Right now they're almost identical.

3. Thirdly, if it's possible to decouple the cruise.umple project from the UmpleToTL projects, those projects should be compiled independently rather than as a unit.

[AdamBJ]

Reposting responses to initial feedback from Kevin here:

"customMasterPath"?

I've got some plugin changes that I haven't pushed yet. That flag allows the user to override the src/{source set name}/umple convention. It's false by default and if someone chooses not to use it the plugin operates in the same way as always.

I'll provide more details when I push, but the way the plugin was before, the user had no choice but to use the src/{source set name}/umple convention. They couldn't even use the ../../ workaround the way we had it setup.

There looks like a lot of common code that just changes by name, is that something we could use a variable for?

Almost certainly. I was going for a PoC with this build.

this could be done in each lower build script instead

I don't think it can, what do you mean?

I'd rather this was done via normal gradle dependencies

That was the only way I could figure out how to get it working. Not sure how to do it the "normal" way

File name is wrong?

Goes back to the customMasterPath flag. If that flag is set the user specifies a custom path relative to the project root.

Why not use the standard build.gradle? Link

Just more convenient to edit/view multiple build files at once. Having seven build.gradles open at once makes it hard to keep track of what project you're working on.

[Nava2]

I've got some plugin changes that I haven't pushed yet. That flag allows the user to override the src/{source set name}/umple convention. It's false by default and if someone chooses not to use it the plugin operates in the same way as always.

I'll provide more details when I push, but the way the plugin was before, the user had no choice but to use the src/{source set name}/umple convention. They couldn't even use the ../../ workaround the way we had it setup.

Would this be the use of the srcDir field?

There looks like a lot of common code that just changes by name, is that something we could use a variable for?

Almost certainly. I was going for a PoC with this build.

Please mention this somewhere, I can get behind that idea; I just don't want it ever being considered final.

this could be done in each lower build script instead

I don't think it can, what do you mean?

Attach the dependencies in the build scripts themselves, not this one.

I'd rather this was done via normal gradle dependencies

That was the only way I could figure out how to get it working. Not sure how to do it the "normal" way

Rewrite the ivy file using: https://docs.gradle.org/current/userguide/artifact_dependencies_tutorial.html

Why not use the standard build.gradle? Link

Just more convenient to edit/view multiple build files at once. Having seven build.gradles open at once makes it hard to keep track of what project you're working on.

You're making it strange for others due to your use case. For others, they will not often (if ever) have multiple build scripts open. Switch back to the build.gradle style, please. It also reduces maintenance.

[AdamBJ]

Would this be the use of the srcDir field?

No. srcDir is used in the root project's build.gradle file because the root project doesn't ever call compileUmple (it doesn't even apply the Umple gradle plugin). Since this doesn't happen, the automatic configuration of srcDir doesn't happen. It needs to be configured manually.

My original intent for the root project was for it to basically just contain the packageUmpleCompilerJar task. But the coupling necessitated adding some other stuff (like generateCoupledSource), that, hopefully, is ultimately removed.

Please mention this somewhere, I can get behind that idea; I just don't want it ever being considered final.

Ok 👍

Attach the dependencies in the build scripts themselves, not this one.

The subprojects aren't aware of the generateCoupledSource task. Besides. wouldn't it be better to have a central location where generateCoupledSource is controlled? If it's declared in the root project and then configured in the subproject's there's no easy way to see what the dependencies are.

You're making it strange for others due to your use case. For others, they will not often (if ever) have multiple build scripts open. Switch back to the build.gradle style, please. It also reduces maintenance.

How about I add this as a TODO before this ticket is closed? While the build is still rough and we're making changes it's a handy feature.

Rewrite the ivy file using: https://docs.gradle.org/current/userguide/artifact_dependencies_tutorial.html

I'm going to add this as another TODO for this issue. I don't have time to do it right now, still going to try to add some plugin tests before I stop development tonight/early tomorrow.

I'll be around after the semester to help polish up this build and the plugin. There's still work to be done, but I think what we've got here and in the plugin is a very nice foundation.

[Nava2]

No. srcDir is used in the root project's build.gradle file because the root project doesn't ever call compileUmple (it doesn't even apply the Umple gradle plugin). Since this doesn't happen, the automatic configuration of srcDir doesn't happen. It needs to be configured manually.

My original intent for the root project was for it to basically just contain the packageUmpleCompilerJar task. But the coupling necessitated adding some other stuff (like generateCoupledSource), that, hopefully, is ultimately removed.

Okay, I trust your judgement.

Attach the dependencies in the build scripts themselves, not this one.

The subprojects aren't aware of the generateCoupledSource task. Besides. wouldn't it be better to have a central location where generateCoupledSource is controlled? If it's declared in the root project and then configured in the subproject's there's no easy way to see what the dependencies are.

You're making it strange for others due to your use case. For others, they will not often (if ever) have multiple build scripts open. Switch back to the build.gradle style, please. It also reduces maintenance.

How about I add this as a TODO before this ticket is closed? While the build is still rough and we're making changes it's a handy feature.

Can you open an issue on the Umple project after the build is brought in? Seems like a simple low-hanging-fruit for someone else.

I'm going to add this as another TODO for this issue. I don't have time to do it right now, still going to try to add some plugin tests before I stop development tonight/early tomorrow.

Works for me.

I'll be around after the semester to help polish up this build and the plugin. There's still work to be done, but I think what we've got here and in the plugin is a very nice foundation.

I'd be happy if that's the case. 👍